Re: [boost] Thoughts for a GUI (Primitives) Library

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2010-09-04 04:44:51

>
> All first-class GUI libraries have had commercial backing, multiple full
> time develop and testing staff, going for several years. It's an insane
> amount of work, however you slice it.
>

If we like to see a standardized C++ GUI some day (and I personally do) then
someone have to do that design and implementation. As I understand, the
committee can't afford it. In my opinion boost is the right place because
it's the only library that influenced the standard, as far as I know.

*Creation:*
> The first event handled by the context; it is sent so any setup can be
> preformed.
>
> *Destruction:*
> Sent just before a context is destroyed (destruction finishes once the
> message is processed); used so the event handler can clean up related
> resources.
>

Can you give an example for when you need these events? Why can't you do
initialization where you create the context and destruction where you
destroy it? Probably 'resources' will be stored in some object that will be
responsible for the context so binding their lifetimes sounds logical. I
don't want double construction/destruction as in MFC/WTL.

*Resizing/Moving:*
> [...] (Question: should this be one event
> or two seprate events?)
>

It should be one event. Resizing and moving can be tied when you implement
docking, for example. For simplicity you may separate them if there is no
handler for unified version.

*Event Loop:*
> [...] I personally lean toward having a function that is called to process
> messages, but would like to hear what advantages and disadvantages people
> can come up with for each method.
>

That's right because event passing should be more complicated than just
calling the right callback function. Consider keyboard input. Keyboard is a
shared resource, therefore keyboard events must be forwarded from the
focused window up the chain of its parents until some handler marks
explicitly that it handled the event. I'm not familiar with any framework/OS
which handles keyboard input this way (if you know, tell me please), but it
seems that this approach will eliminate the necessity of message filtering
to implement accelerators, for example.

Y. Galka