[wx-discuss] aspects of a safe future

[Vadim Zeitlin]

On Fri, 14 Sep 2007 16:52:18 +0200 "myLC at gmx.net" <myLC at gmx.net> wrote:

m> First of all, thank you for your post. So far, all I've ever
m> received from <wx-discuss> was a little Spam, instead of the
m> vivacious discussion about wx V3.0 I had hoped for...

 Have you looked in the archives? There were a lot of discussions of wxTNG
(which used to be used interchangeably with wx3 but should really be used
now as wx3 will be "just" the next version and not radically different from
wx2) in the past and there doesn't seem to be much else to say about it
except that it would be great if someone had time (I estimate it'd need at
least 2-3 months) to write at least a skeleton of it.

m> Second in completeness: wxWidgets (with a better layout
m> management), which also comes with a good documentation.
m> The problem of wx, as stated, comes with its roots. Hence,
m> also no exceptions, namespaces and even no signal/slot
m> mechanism (callbacks aren't that fancy, signals that work
m> over threads/processes are by far more practical).

 I don't know about Qt but Boost signals hardly work [well] over threads.
And no signals at all work over processes to the best of my knowledge. Of
course, we hardly need them to -- it's (luckily!) not really common to
process clicks on a button in another process.

m> For example Windows itself is unable to provide a decent
m> Unicode support. A 16-bit wchar_t simply doesn't do the job.

 If you really need Unicode support beyond what Windows provides, you need
to use ICU.

m> You cannot fit all the languages and their symbols in there.
m> As a result you cannot really use Unicode (such as UTF8)
m> with wxWidgets,

 This is a complete non sequitur. What does UTF-8 have to do with 16 bit
wchar_t? This is a completely orthogonal issue.

m> Consider the following example - this is how it could be:
m> 
m> try {
m> 	...
m> 	ftpstream( "ftp://ftp.29A.net/.gonaria" ) >> buffer;
m> 	...
m> } catch ...
m> 
m> 
m> The ftpstream could be derived from multiple classes.

 Better yet, ftpstream could have come from a completely different library.
FTP really doesn't have anything to do with GUI and whatever else, I hope
we don't repeat the mistake of trying to include everything and the kitchen
sink in wxTNG.

m> The BOOST guys run a different (one-man?) show. Rather
m> "conservative" - in a negative sense. I believe that even
m> the idea of including GUI functionality seems repelling to
m> their chieftains...

 I don't know much about Boost development but I think it's completely
unfair. I'm sure Boost folks would be very glad if someone submitted a
well-written, functional, documented GUI framework for inclusion to Boost.
Unfortunately it would take quite some effort to write it. So far nobody
had the time+motivation(+capacity) to do it.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org