|
Boost : |
From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-12-12 12:49:51
> 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.
A Windows programmer friend of mine once kept asking me, when he saw the
results of a cross-platform GUI I worked on (but did not design) why we
hadn't just used regular Windows dialogs, which "just work". Since then I've
been wondering if it is even a good idea to model the entire underlying
window structure of a GUI in cross-platform code and data. Probably the
answer is no.
It's possible that the best structure is one where "controls" and "windows"
(areas of the GUI written by the user) are fairly separate concepts, where a
control may have an associated window.
How much wrapping is required for a standard component like a scrollbar?
Probably enough to do the following:
1. place it as a leaf in some user-defined window hierarchy
2. get it to collaborate in a coherent way with other (user-written) GUI
components.
#2 includes many aspects, like size and placement constraints and
positioning feedback.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk