Event handling in wxTNG

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Event handling in wxTNG

Robin McNeill
I have written up an article on OMGUI's wiki page describing the events system I
would like for OMGUI to have, and seeing as OMGUI is essentially my attempt at
wxTNG, it is appropriate that I also post it here. If you don't know what OMGUI
is, thats okay, just consider the article a suggestion for an events system for
wxTNG.

http://wiki.omgui.org/Event_System

I will eventually be making more posts relating to my ideas for wxTNG in the
future as they solidify into more concrete ideas.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Event handling in wxTNG

Vadim Zeitlin-3
On Sun, 15 Jan 2006 22:03:36 +0000 (UTC) Robin McNeill <[hidden email]> wrote:

RM> I have written up an article on OMGUI's wiki page describing the events
RM> system I would like for OMGUI to have, and seeing as OMGUI is
RM> essentially my attempt at wxTNG, it is appropriate that I also post it
RM> here.
RM>
RM> http://wiki.omgui.org/Event_System

 It's an interesting start but it would be even more interesting to know
how to implement all this efficiently. Using boost::signal is tempting but
I think that maybe not realistic. OTOH boost::function should be used as
building block of any alternative solution.

 Anyhow, I don't have much to add to it except that if event parameter is
const (which is logical but would compromise compatibility with the current
wx even further -- but then, as I said, I don't see how wxTNG could be
compatible with wx2 anyhow, unfortunately), then the return value and not
mutating const methods should be used for vetoing &c. Surely it's more
natural to have a "bool OnCanChangePage(const wxPageChangeEvent&)" than
"void OnCanChangePage(const wxPageChangeEvent& event) { modify event }".

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Event handling in wxTNG

Stefan Csomor
In reply to this post by Robin McNeill
Hi Robin

> I have written up an article on OMGUI's wiki page describing
> the events system I would like for OMGUI to have, and seeing
> as OMGUI is essentially my attempt at wxTNG, it is
> appropriate that I also post it here. If you don't know what
> OMGUI is, thats okay, just consider the article a suggestion
> for an events system for wxTNG.
>
> http://wiki.omgui.org/Event_System
>
> I will eventually be making more posts relating to my ideas
> for wxTNG in the future as they solidify into more concrete ideas.

thanks for posting your thoughts, it definitely helps to share thoughts
on wx future, I agree that a signal/slots mechanism should be used, but
when I brought that idea up last time here, we had different views on
its efficiency, so we will have to build one in order to decide.

Best,

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Event handling in wxTNG

Jorgen Bodde (email lists)
In reply to this post by Robin McNeill
Interesting reading!

I also want to add (not related to the event system) that wxTNG really
needs a better base for extending and adding components. What I miss in
wxWidgets nowadays is skeleton code. When I want to create a new
component, I would expect an empty container for every base component for
easy overriding. I know this is a lot of work, but it significantly
improves the standard in how people should code in the framework.

For a long time I have thought about writing a generator that could do
that. I am still thinking about it though. A simple wizard that will take
a XML file with some accompanying code from the wxWidgets base, you fill
in the name and events / methods you need to override, and your component
is generated in C++ code according to the standard of the wxWidgets code.
That is something that is really needed in a lot of situations, to make it
more accessible to write components for it.

Good work Robin, I always follow new development related to wxTNG with a
close eye, because I think it is needed to move forward with wxWidgets.

- Jorgen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Event handling in wxTNG

Robin McNeill
In reply to this post by Vadim Zeitlin-3
Vadim Zeitlin <vadim@...> writes:

>  It's an interesting start but it would be even more interesting to know
> how to implement all this efficiently. Using boost::signal is tempting but
> I think that maybe not realistic. OTOH boost::function should be used as
> building block of any alternative solution.
>
After my consderations yesterday, I believe all efficiency choices are really
tradeoffs between size complexity and time complexity. For non global slots,
storing one signal object for each signal within widget instaces is the most
efficient in terms of time complexity but the worst in space complexity. The
other extreme is storing slots polymorphically within only 9 maps (3 for
different slot types times 3 for preprocessing, normal, and postprocessing).
This loses almost all type safety but incures heavy time complexity overhead for
all of the map lookups as well as the dynamic casts required to restore some
type safety to the system. Somewhere in the middle of these two options lies the
best solution, exactly what that is is not yet known.

I also agree that any alternative should be based on boost.function, but I don't
see a whole lot against using boost.signal in wxWidgets. Your binary
compatability requirements are not as high as the ones I set for OMGUI, which at
one point made me seriously consider not using boost.signal. As of yet I remain
undecided. Furthermore, boost.signals would be the first step towards weening
wxWidgets off of all its home grown solutions, which I consider to have negative
impacts on the library. I dont intend to ruffle feathers with this statement, it
is simply my opinion.

>  Anyhow, I don't have much to add to it except that if event parameter is
> const (which is logical but would compromise compatibility with the current
> wx even further -- but then, as I said, I don't see how wxTNG could be
> compatible with wx2 anyhow, unfortunately), then the return value and not
> mutating const methods should be used for vetoing &c. Surely it's more
> natural to have a "bool OnCanChangePage(const wxPageChangeEvent&)" than
> "void OnCanChangePage(const wxPageChangeEvent& event) { modify event }".
>
I had considered this, but decided against it because vetoing only makes sense
for a certain subset of all possible events. You cannot veto a WindowCreated or
WindowDestroyed event, so forcing functons which handle these events to return a
useless value seems wrong to me. There are far more events which cannot be
vetoed compared to those that can.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Event handling in wxTNG

Vadim Zeitlin-3
On Mon, 16 Jan 2006 16:41:04 +0000 (UTC) Robin McNeill <[hidden email]> wrote:

RM> Furthermore, boost.signals would be the first step towards weening
RM> wxWidgets off of all its home grown solutions, which I consider to have negative
RM> impacts on the library. I dont intend to ruffle feathers with this statement, it
RM> is simply my opinion.

 It is also _the_ idea behind the whole wxTNG thing.

RM> >  Anyhow, I don't have much to add to it except that if event parameter is
RM> > const (which is logical but would compromise compatibility with the current
RM> > wx even further -- but then, as I said, I don't see how wxTNG could be
RM> > compatible with wx2 anyhow, unfortunately), then the return value and not
RM> > mutating const methods should be used for vetoing &c. Surely it's more
RM> > natural to have a "bool OnCanChangePage(const wxPageChangeEvent&)" than
RM> > "void OnCanChangePage(const wxPageChangeEvent& event) { modify event }".
RM> >
RM> I had considered this, but decided against it because vetoing only makes sense
RM> for a certain subset of all possible events. You cannot veto a WindowCreated or
RM> WindowDestroyed event, so forcing functons which handle these events to return a
RM> useless value seems wrong to me. There are far more events which cannot be
RM> vetoed compared to those that can.

 But a good design should account for rare cases. Any design accounts for
the generic one, the difficulties always come from the exceptions to the
general rule. And, again, I think it's much more natural to return a value
from a handler (which can/should, of course, be "void" for the majority of
them) than to call a method on it (whether const or non-const).

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Event handling in wxTNG

Robin McNeill
Vadim Zeitlin <vadim@...> writes:

>  But a good design should account for rare cases. Any design accounts for
> the generic one, the difficulties always come from the exceptions to the
> general rule. And, again, I think it's much more natural to return a value
> from a handler (which can/should, of course, be "void" for the majority of
> them) than to call a method on it (whether const or non-const).

I see what you mean, I hadn't considered that. Different signals can have
different function signatures, so the things that veto can be bool foo(...), and
the things that don't can be void. I like that idea actually, but it depends on
using a very typesafe implementation, aka boost.signals or something similar, as
compared to a polymorphic solution which requires all event handlers to have the
same signature, unless there are two different kinds of base classes to provide
the different signatures, which is yucky.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]