[boost] Re: boost Windowing Toolkit

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-13 06:03:13

From: Dave Abrahams [mailto:abrahams_at_[hidden]]
> 
> > There's another reason why some portable windowing class
> > libraries have not caught on.
> >
> > Does your toolkit provide support for standard controls
> > (buttons, menus, etc)? From what you're saying (correct
> > me if I'm wrong), it sounds like you provide lower level
> > drawing functions only and expect control classes to be
> > written on top of these. My issue with libraries that
> > take this path is that they lose the native platform's
> > look and feel. If they try to get it to behave the same
> > as the controls native to the platform, it usually ends
> > up even worse...
> 
> You're right that this is a huge issue. I meant to include it 
> in my list. My toolkit does not provide support for standard controls,
> but  neither does it forbid them. In fact, when it was designed, being
> able to accomplish a stanadard look-and-feel was a serious consideration.
> 
> I have not done anything about that consideration yet, though, partly
> because I didn't want to make the wrong decision, and partly 
> because it was absolutely unneeded for the project I was addressing.
> This is one of the things I would like very much to work with other
> people on.

I believe that any toolkit which does not (a) offer a 100% platform-standard
look and feel, and (b) support all of the fancy contols available on the
platform, is going to fail (in some sense). The big problem is that the
whole *concept* is non-portable.

It's a bit like filename handling. People try to write platform-independent
code, but the underlying concepts differ too much across platforms. What is
a drive on Unix? What is a version number on anything other than VMS? What
is a resource fork except on a Mac? Acorn RISC OS has file types which are
separate file metadata, independent from the filename. Again on RISC OS,
"extensions" tend to be modelled by directories (test.c is a file called
test in directory c - the OS name for this is c.test!!!)

Similarly, Windows has coolbars, OCX controls, ... You can't *write*
portable code which uses them, as they don't exist on other platforms. But
if your toolkit doesn't support them, Windows programmers won't want to use
it.

You need to be clear on who your target audience is:

- people for whom portability is a must, at all costs? They are probably
already using one of the existing toolkits (Tk, Zinc, Qt, ...)
- people working on Unix who want to get a free port to Windows? Again,
existing toolkits - many of the "portable" toolkits like Tk started as Unix
versions which were ported to work on Windows.
- users of other OSes (MAC OS, Be, ...) - a very small group.
- ...

Sorry to sound so negative. I would LOVE a good, complete, GUI toolkit in
C++. But I'm a Windows programmer, and the rest of the world can go hang in
my quest for 100% platform look and feel and access to the latest whizzy
controls :-)

On a more positive note, a VERY useful thing to develop would be a generic
event-handling library/toolkit/method. Most GUI code still revolves round a
big switch statement (I believe this is true in X, as well as in Windows?)
Virtual functions by themselves don't hack it - in Windows, there are
literally hundreds of possible messages, even ignoring user-defined ones.
You can't dispatch every one to a dummy virtual in a base Window class. But
the only "solutions" I have seen involve either gross macro-hackery, or
overly generic function interfaces (every Windows callback takes 3
parameters, the message, and 2 parameters - these should be decoded into
meaningful type-safe values before getting to user code).

I'd love to see a clean wrapper round all of this, encapsulated in a generic
"Window" class. I would quite happily write my own control wrappers around
something of that nature.

But I do think there is a need for a really good C++ approach (using
namespaces, templates, exceptions, whatever - the "modern" stuff) to GUI
environments.

Paul.