[wx-discuss] aspects of a safe future continued...

[myLC at gmx.net]

Hello again, I'm gonna quote from two different persons here
- somewhat dirty, I know...


Bryan Petty:
> Most of that 3.0 discussion has mostly been kept on the
> wiki, where it's a little more organized, and doesn't
> disappear with time.

and Vadim Zeitlin wrote:
> 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 ...


Gonna take a look at the wiki and wxTNG then (I searched the
archives for wx3/3.0 and the like, obviously missed wxTNG
completely)...


Again, Bryan:
> You are right though, there just hasn't been a lot of
> discussion in general about it. But it usually turns
> out that the people that want to see 3.0 go a certain
> direction are the same people that aren't doing any
> of the work involved, so it's usually pretty pointless
> anyway. You'll find this is the case with most of the
> details about 3.0 on the wiki too.

Yes, the classical "Circulus vitiosus". The people which
want to see radical changes don't take part, because they
believe that current development is going nowhere (-good);
and those doing the work hang on to what they do (did)...
Xo{


and Vadim:
> ... 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.

What I hoped for was a vivacious discussion about where the
train should be going. If there really were some sort of
accord on a completely new release (obviously not the case),
then before going into "skeletons" or even coding, there
should be a lengthy quarrel about what it should look like
from a programmer(user)'s perspective first. Again, not
happening, so no point in drilling any further there...


Bryan:
> Templates are used when built with --enable-stl.
> Namespaces would be used if any of us found that they
> actually payed off, but none of us can see any advantage
> to them that would be a big enough reason to justify the
> change. What else are we missing here?

Namespaces are great for grouping (sub-groups, etc.). This
way you can have terse names that make sense within their
scope. Without namespaces you always have to prefix them and
end up with things like: wxSIZE_AUTO_WIDTH,
wxSIZE_AUTO_HEIGHT, wxSIZE_USE_EXISTING or
SYMBOL_WXRICHTEXTSTYLEORGANISERDIALOG_STYLE.
Not deadly, but less practical (definitely more typing
involved;-).

... and of course you can set item-data and the like by
using pointers: wxListItem::SetData(void* data) and cast
your way through it. No problem. Nevertheless C++ comes with
the instrumentality to avoid that.

You are also missing exceptions and a nice signal/slot
mechanism (which is pretty useless if not built into the GUI
classes - still works, but you have to do it all yourself).


And again Bryan:
> ... Without this manpower, most of us like this trade-off
> where rather than wxWidgets building a signal/slot
> library, we like to share this responsibility with the
> Boost project. Boost has a fairly nice signal library for
> example. wxWidgets + Boost is a really powerful
> combination.

What I wrote wasn't meant as an insult. I apologize if any
of it should have come along like that. Of course wx doesn't
have the resources of Trolltech. So wxWidgets is currently
the best free toolkit there is. :-)
BOOST + wxWidgets would be a great improvement. The
signal/slot mechanism only makes sense if supported by the
GUI (i.e. the GUI classes emit signals by default).
Otherwise it's rather pointless doing it all yourself...
There was a short discussion about BOOST and toolkits such
as wxWidgets on the BOOST list, but a "moderator" decided to
kill that thread (keeping important threads like "why there
are so few women in BOOST" running at the same time;-).
The very same "moderator" also chose to "shorten" my posts
by cutting out pieces... X-|
(and they weren't even remotely as long as this one)


Vadim:
> 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.

The signal/slot mechanism (if not chosen otherwise)
translates into a simple function call when in the same
thread. So it's fast and type-safe (unlike callbacks). Also
you can connect multiple signals to one slot and one signal
to many slots, etc...
When spanning threads the signal/slot mechanism works by
posting messages to an event loop (usually the GUI event
loop). This is rather slow and not designed to pass large
amounts of data, but it is VERY USEFUL when dealing with the
all-to-common worker thread phenomenon. It is simply a lot
more practical than dealing with messages directly.
Since passing messages over process barriers is nothing new
you can also make the signal/slot mechanism work
transparently over processes and even clusters if you want
to. It can be very powerful and simple (transparent) to use
(not only for GUI purposes).


And Vadim:
> If you really need Unicode support beyond what Windows
> provides, you need to use ICU.
> ...
> This is a complete non sequitur. What does UTF-8 have
> to do with 16 bit wchar_t? This is a completely
> orthogonal issue.

Well, Qt uses a 16-bit type (QChar), but unlike Windows
characters with code values above 0xFFFF are stored in two
consecutive QChars. This way you can use Unicode
transparently even under Windows without a big fuzz
(locales, etc.). By using the Windows functions (like
MessageBox) you give that up. That's why I like the
(certainly more radical) Qt/juce approach better...
(Questionable if UTF-8 would be a big performance trade off
in that matter, but I would somewhat prefer it over Qt's 16-
bit chars, or at least have them both - the possibility when
calling toolkit functions, without a conversion taking
place, that is).


More Vadim:
> ...
> > ftpstream( "ftp://ftp.29A.net/.gonaria" ) >> buffer;
> ...
> 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.

I disagree. Currently you are right. CURRENTLY your approach
would be an improvement. However, I think the most practical
solution (for the users/programmers) would be this:

The ftpstream class (or better, an ancestor) would have some
flags where the programmer/user could take a decision about
the default behavior. The default behavior you would usually
want in a GUI project is to prompt the user if there is a
problem and let her/him decide if ee's gonna fix it and
retry or abort.
Let's take a look at a class like wxFile. As a programmer I
don't want to check the return values constantly and then
prompt the user if I consider it "curable". You have to do
that over and over on all sort of things and when dealing
with multiple languages you have to translate the entire
crap as well...
The behavior that I would want in such a case is for the
toolkit taking care of it, either with an exception if it's
something fatal, or telling me that the user cancelled - or
that everything went fine.
When trying to open a file lots of thing can go wrong (file
not found, permission denied, filesystem full, etc.).
Wouldn't it be nice if you could set a few flags according
to your gusto and the toolkit would take care of it (in many
languages as well)? "Permission denied, dear user - you may
change the access rights of the file blablabla and press
RETRY or CANCEL). My code is full of that stuff (and not
only mine). You basically have to wrap everything yourself.
Reinventing the wheel over and over - what's the point?
That's why I believe that a GUI should NOT be separated from
"the other crap"...


Vadim:
> 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.

See above. ;x[
Personally I sense that you couldn't be more wrong with that
one although I don't know the reason for it...


> Unfortunately it would take quite some effort to
> write it. So far nobody had the time+motivation
> (+capacity) to do it.

Yes, but I believe that the "Circulus vitiosus" (again,
above) might have something to do with that...


Sheeees, I think I wrote a book here. Feel free to thrash me!
;-)


Regards,
                                        LC (myLC at gmx.net)



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