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-06 07:13:18

On Sun, Sep 5, 2010 at 12:55, Pierre Morcello
<pmorcell-cppfrance_at_[hidden]>wrote:

> This is offlist.
> [...] The STL (written mostly by Stepanov) influenced it even more.
>
Yes. It's just so natural part of the standard nowadays that it's easy to
forget. :)

On Mon, Sep 6, 2010 at 02:15, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:

> On Sat, Sep 4, 2010 at 8:40 AM, Yakov Galka <ybungalobill_at_[hidden]>
> wrote:
> > Can you give me a real world example where you need the "capturing" phase
> > for any reason other than a hack for some other design problem? I just
> can't
> > think of any.
> > Thank you.
> >
> >>
> http://www.adobe.com/devnet/actionscript/articles/event_handling_as3_03.html
> >>
>
> - Global Shortcuts (like in Visual Studio)
>
This one is wrong! Let me describe in detail how I see the process of
handling keyboard shortcut, commands (button clicks), etc..:
1) The event is sent to the focused window (e.g. a control in my XYZ
document viewer).
2) Every event handler marks explicitly if it handles the event or not.
3) If the event is handled, no more processing is done (e.g. the control is
a 'find' textbox, I pressed Ctrl+Left Arrow to move the cursor one word
left).
4) Otherwise the event is passed to the parent (e.g. the control is a
'case-sensitive' checkbox).
5) The parent processes the shortcut key for 'Previous chapter'.

If the user intends to execute 'Previous chapter' command but 3 happens, she
must transfer the focus to the parent manually. That's the desired behavior!
The point is that the implementer of the parent can't know if someone in the
future will add a grand-grandchild that wants this event. If you implement
the shortcuts with parent processing first, then you make it *impossible*
for the user to use child's shortcuts.

Of course, the problem is in 1. That is in a given system (e.g. Windows)
there is no general way to check if the control processed the message or
not. That's why you need hacks, and that's why I want a portable GUI library
to do as much as possible towards implementing this behavior.

> - Macro recording, both the start/stop shortcuts, and the recording of
> inputs
> - Automation
>
I guess these are done on a higher level than just capturing the input. I
can't analyze these without a broader look on the implementation. I don't
have experience with implemented these in any project.

> - hacks
> - unknowns
>

> For a framework, hacks and unknowns are valid reasons.

Agree. But hacks should remain hacks. I mean you shouldn't make your design
less elegant because you want to make hacks easier to implement. Even if the
'unknowns' aren't hacks (as you've already mentioned + see below), the
library should make the common case implicit.

> [...]
>
> I know that any framework that did child first ended up needing a
> parent-first hack, and anything that was parent-first needed
> child-first sometimes.  Unfortunately I can't remember the particular
> reasons, but it seemed to always happen.
>
Unfortunately I can't remember either :). But I can think of two more cases
when you need parent-first:
- "Subclassing" without really subclassing.
- Implementing some "key" indicator in the parent (e.g. handle Caps Lock).

Best regards,
Yakov Galka