Re: wxWidgets Event handling and threading model
Vadim Zeitlin
DK> 1. Why does wxWidgets choose the even table kind of approach for event
DK> handling?
The simplest answer to this question is "because". Whatever the relative
merits of different approaches, event tables are what wx historically used
so you have to live with it. Or, of course, use wxEvtHandler::Connect()
which is quite close to what the other systems (e.g. GTK+ or Qt) use.
DK> In Toolkits like FLTK widgets can send indicate that they are
DK> not interested in an event and thus they do not have event table kind of
DK> approach for handling events which is why their library is small.
I seriously doubt that the size of wx library has anything to do with the
method used for the event handling. Please explain how are these 2 points
related if you disagree.
DK> 2. When you write a wxWidgets application, then does wxWidgets create a
DK> separate thread for event handling and painting?
No.
DK> 3. When you create an instance of a class derived from wxGLCanvas, does
DK> wxWidgets create a separate thread for rendering in this window?
No.
DK> 5. Does creating a wxServerSocket instance also creates a separate
DK> thread?
No. See the pattern? wx never creates any threads automatically for you.
DK> This is what I see in the Thread window of VS.Net IDE when the
DK> new for wxServerSocket returns.
This is an internal Win32 thread and you shouldn't care about it.
DK> 6. Why does wxWidgets implement its own implementation of string when
DK> we already have one as std::string?
Set wxUSE_STL=1 and recompile.
DK> hope my questions are well framed and clear,
Yes but you may want to ask separate questions in separate posts in the
future as it allows to discuss them more conveniently.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
klaas.holwerda
> 1. Why does wxWidgets choose the even table kind of approach for event
> are not interested in an event and thus they do not have event table
> kind of approach for handling events which is why their library is
> small. So if that is the case then why didn't wxWidgets designers use
> that approach. Also in toolkits like Java Swing widgets need to add
> event handlers which makes it easy to send the event only the
> registered listeners. This even avoids the creation of event tables.
> The third approach is of toolkits where they adopt callback mechanism
> for event handling. So why wxWidgets choose Event tables instead of
> these approaches ?
Event tables does also have nice features, it implements some sort of
virtual function mechanism, where you can make derived classes skip
events, which means they will be handled in base classes. I find that
even more flexible then using virtual functions. Next to that event
tables are easer to implement for scripting languages like python lua
etc. But if you don't need all that there is Connect() as said.
But subscribing to specific events or non, and distribution of events
can also be reached with the wxEvtHandler derived classes. In fact i
have a distribution event class in wxArt2D, to which classes can
subscribe (for all or specific events), and all events send to the
distributer, will be distributed to all the subscribed classes by
calling subScribedClass::ProcessEvent( event ). The 1 send to N
receivers is often handy. And per receiving class you still use events
tables to process the events in there.
I think the event system in wxWindows is maybe even better then some
other approaches ;-)
They only bad things is that not every object can receive events, and
using smart pointers and a small event handler class, i almost had to
duplicate the wxWidgets events to make it work. Therefore i think there
should have bin:
virtual wxObject::ProcessEvent( event ) { return false; }
or at least a:
virtual wxBaseEvtHandler::ProcessEvent( event ) { return false; }
That makes it possible to handle events the way you like it, without
being forced to the way wxEvtHandler wants it.
regards,
Klaas
--
Unclassified
Vadim Zeitlin
DK> >> I seriously doubt that the size of wx library has anything to do with the
DK> >> method used for the event handling. Please explain how are these 2 points
DK> >> related if you disagree.
DK>
DK> Well I wouldn't say that it is my statement. But this is what is claimed
DK> by FLTK documentation. I wouldn't say that whatever it says is perfect
DK> but I was curious.
DK> See the link below.
DK> http://www.fltk.org/doc-1.0/events.html#propagation
Quoting
FLTK follows very simple and unchangeable rules for sending events.
The major innovation is that widgets can indicate (by returning 0
from the handle() method) that they are not interested in an event,
and FLTK can then send that event elsewhere. This eliminates the
need for "interests" (event masks or tables), and this is probably
the main reason FLTK is much smaller than other toolkits.
Makes no sense to me to be honest. First, wx, of course, allows to "skip"
the event (wxEvent::Skip). Second, I'm sure all the other systems allow it
as well, in one way or another. Third, the size of event tables should be
completely negligible but to be sure we'd need to at least know about which
size we're speaking about here. Number of lines of code? Executable size?
Run-time memory consumption? I really have no idea.
DK> >> Set wxUSE_STL=1 and recompile.
DK>
DK> Does that make wxString and string interchangeable ? Could you please
DK> explain what effect does it achieve? Or point me to appropriate link.
wxUSE_STL=1 makes wxString be a simple façade to std::string,
wxArrayString -- to std::vector and so on. If you just need to make them
interchangeable it should be enough to set wxUSE_STD_STRING=1. See comments
in wx/setup.h for more information.
Divick Kishore
I am really confused about the event and threading model adopted by
wxWidgets. :-(
I have several questions to ask. Please help me get those answer.
1. Why does wxWidgets choose the even table kind of approach for event
handling? In Toolkits like FLTK widgets can send indicate that they are
not interested in an event and thus they do not have event table kind of
approach for handling events which is why their library is small. So if
that is the case then why didn't wxWidgets designers use that approach.
Also in toolkits like Java Swing widgets need to add event handlers
which makes it easy to send the event only the registered listeners.
This even avoids the creation of event tables. The third approach is of
toolkits where they adopt callback mechanism for event handling. So why
wxWidgets choose Event tables instead of these approaches ?
2. When you write a wxWidgets application, then does wxWidgets create a
separate thread for event handling and painting? Since there is no
recommendation in wxWidgets manuals to avoid doing long calculations
(say a read from a remote DataBase) in the event loop which bothers me
and leads to the original question.
(This question is little windows specific as I have observed the
following behavior only on windows build)
3. When you create an instance of a class derived from wxGLCanvas, does
wxWidgets create a separate thread for rendering in this window?
I ask this question because when I create a wxGLCanvas, a new Win32
thread is create as soon as the new for wxGLCanvas completes.
If yes then what is the order of event calls , if not then isn't it
that my drawing is happening in a thread which can be unresponsive when
i am dealing with UI or say wxWidgets itself internally is doing some
processing.
Wouldn't that mean that the drawing with OpenGL will not be as fast?
4. Has anyone bechmarked the performance of wxWidgets wxGLCanvas w.r.t.
other toolkits like FLTK, Win32 etc along with toolkits which not
necessarily are GUI toolkits like SDL, GLFW etc ?
If someone has the results of the performance benchmarks then it
would be really helpful for people whether to choose wxGLCanvas for some
high performance rendering or not.
5. Does creating a wxServerSocket instance also creates a separate
thread? This is what I see in the Thread window of VS.Net IDE when the
new for wxServerSocket returns. There is a link on litwindows
http://www.litwindow.com/Knowhow/wxSocket/wxsocket.html which talks of
some threading issue with wxSockets. This is confusing me a lot. Could
someone point me to some link or clarify which talks to threading model
adopted when using wxSockets and pros - cons of it?
6. Why does wxWidgets implement its own implementation of string when
we already have one as std::string? This is really painful as quite a
few times when you are using wxString with std::string you have to
convert back and forth between these two which is really cumbersome. I
really wish if such a nice API like wxWidgets had support for
std::string for directly rather then having its own wxString implementation.
hope my questions are well framed and clear,
Thanks in advance,
Divick Kishore
that answers a lot of my questions. Next time I will
make sure to ask question separately for separate topic to make it
convenient.
>> I seriously doubt that the size of wx library has anything to do with the
>> method used for the event handling. Please explain how are these 2 points
>> related if you disagree.
Well I wouldn't say that it is my statement. But this is what is claimed
by FLTK documentation. I wouldn't say that whatever it says is perfect
but I was curious.
See the link below.
http://www.fltk.org/doc-1.0/events.html#propagation
>> Set wxUSE_STL=1 and recompile.
Does that make wxString and string interchangeable ? Could you please
explain what effect does it achieve? Or point me to appropriate link.
Thanks a lot,
Divick
Christoph Haller
This is just for the record ...
My wx-application (OS HP-UX, gtk, compiled with g++) has a batch
operation mode
driven by g_io_add_watch from glib via an input callback.
After doing some print jobs using wxPrinter::Print the application was
stuck
in an indefinite loop of one of the IO Channels functions.
Then I was stuck because I could not find out why. Incidentally, I have
seen
there were two libraries linked, libgthread.a and libpthread.sl, which
may conflict because of some identical function names. I do not know,
if this is an HP-UX special case, the linker and the dynamic linker are
notorious for producing strange bugs, or if it was just my stupidity to
not
consider this possible conflict.
Anyway, after running wx's configure --disable-threads ... and
re-building,
the application's batch mode is running perfectly.
If anybody is facing a similar problem, maybe this helps.
Regards, Christoph