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

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Gwenio (urulokiurae_at_[hidden])
Date: 2010-10-16 13:28:44

On Sat, Oct 16, 2010 at 6:52 AM, Yakov Galka <ybungalobill_at_[hidden]> wrote:

> We want to implement event handling. If so it doesn't matter what events we
> pass, system events or custom events. A general solution will handle them
> both.

If adding custom translations is possible, then they can pass non-standard
messages if they want to; however doing more that allowing for translating
unknown messages would make the translation step far more complex (or at
least a greater overhead) if it can be done at all.

> There is nothing bad with virtual class.
>
> You can use this approach to create event handlers at compile time:
>
>    class MyEventHandler
>    {
>    public:
>        typedef tuple<
>            all_mouse_events, // this is a group of different mouse events.
> we can (?) use SFINAE to call only those that are overridden. or perhaps
> default to a do nothing handler if there is no override for e.g.
> mouse_down_event, which is simpler to implement.
>            // mouse_move_event, // or specify them one by one
>            system_native_event // native events, untranslated
>        > handled_events;
>
>        void on_event(const mouse_move_event& e) { ... }
>        void on_event(const system_native_event& e) { ... }
>    };
>
>    class MyEventHandler2 { /* .. */ };
>
> And then you can compose all these:
>
>    typedef compose_handlers<tuple<MyEventHandler, MyEventHandler2>>
> MySuperHandlers;
>
> Or something like that. compose_handlers derives from all the handlers
> passed and from event_handler. event_handler is a virtual class with
> dispatch_event function. compose_handlers implements dispatch_event:
>
>    template<class EventList...> class compose_handler : public
> event_handler, public EventList...
>    {
>    public:
>        virtual void dispatch_event( ??? )
>        {
>            for each event type/group in linearized EventList:
>                if type matches, cast to it and
>                    on_event(casted_event_reference);
>        }
>    };
>
> Some variations are possible, mainly inheritance vs typedefed lists, static
> vs non-static on_event.
>
> Note: Without compile time reflection or ugly preprocessor macros we can't
> avoid specifying handled events twice in *any* approach. We have to specify
> them once for the handler function and once for what events we actually
> handle. However using grouping like above we can simplify this a bit.
>
> One question is how to dynamically dispatch the event to the right handler
> function type. Possible ways:
>    * Use dynamic_cast. Pros: grouping of event types is possible.
> mouse_move can inherit mouse_event so on_event(mouse_event) can handle
> mouse_move events too. User doesn't need to maintain event ids. Cons: Slow.
> events are virtual classes.
>    * Use typeid: Pros: User doesn't need to maintain event ids. Faster (?)
> than dynamic_cast. Can be done without virtual classes: the     one who
> dispatched the event knows the exact type. Cons: No grouping of events. I
> don't know what implementations do when dynamic linking is used but I guess
> it still may be slow on some implementations.
>    * Use address of global object as Id: Will this even work with dynamic
> linking?
>    * Use statically generated event ids. Pros: as fast as possible. Cons:
> The burden of ensuring uniqueness falls on the user.
>
> I was thinking more along the lines of the event handler that the backend
deals with would all ready define the standard events, and have a function
to call for unknown events that is platform specific. The handler for
unknown events would then process custom messages, and do whatever is going
to be done with them. Having just one method in the event handler adds to
the processing time, as to format the message into the correct type would
require the message to have already been identified and it would need to be
identified again.

>
> Why do you think that there must be a single answer for this question? I
> think that depends on the control. Some controls may not be C++ objects at
> all, e.g. native button may send command events. We may want to handle
> events from grid cells which are defined implicitly, etc...
>
>

Because this relates to the structure of the class that will store the
information for working with the native objects for all controls. So is the
likelihood that someone will want to pair the object containing control
specific data with a separate event handler object great enough to be worth
however much memory a pointer takes?

To be clear this has nothing to do with separating how data is stored for a
control, like a tree view, and how the definition of how the control
behaves. That can be done regardless of which way this goes.

> There are more questions to answer. Also someone here said that he is up to
> implementing a prototype of his ideas, it would be nice to know what his
> progress is and what his ideas are.

Of course there is more to decide, but they are more specific like should
there be creation/destruction events and where the origin for the coordinate
system should be.