[boost] Re: boost Windowing Toolkit

From: Bill Klein (bill_at_[hidden])
Date: 1999-12-12 18:59:26

Hello Dave,

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

And I think it is very much worth working on. To get
around the issue of platform-native vs. platform-
independent controls, one solution might be as follows:
For each control that is supported by the toolkit,
implement it based on the platform-independent drawing
functions that we already have. Now everything works
on all platforms.

Any platform can have a different implementation though
which is based on the platform's native controls. Even
platforms which don't have native controls might want
to have a different implementation that is consistent
with the look of that platform...

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

This is how I've always thought of things. Despite what
Microsoft may tell you, a scroll bar is not a window.
A radio button is even less of a window. :) The fact
that they are windows internally is just a detail for
that platform...

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

Number 2 is just events right? The scrollbar is being
scrolled and a function gets called repeatedly to tell
you this. A button is clicked and a user-defined function
gets fired to let you handle it... I say *just* events
but of course it's a big issue. You mention something
about event queuing in your original post. Is that
something workable for what we're talking about here or
is it something completely different?

-Bill Klein <bill_at_[hidden]>