Hi all,
i’ve a question about ruby threads and gui update events:
My app consist of several folders that needs to be updated depends on
what
the user do.
Actually all the gui updates occurs in response to the user actions into
the
main wxruby process.
It’s just fine if the gui update takes short time but, sometimes, the
gui
update is a long running task and the user get stuck waiting for the
process
to complete.
It would be nice to have gui update running on a separate thread.
The first thing i thought was:
ok i use the wxThread to update my long running gui task but
unfortunately
it’s not included in wxruby distribution.
On the other side, using ruby thread in combination with Thread.pass is
good
for external process not involving gui updates
So, what is the right way to go to update gui interface on a separate
thread
using wxruby?
Any suggestion would greately appreciated.
bio.
I’m new myself but perhaps you can use EvtHandler#add_pending_event from
a standard thread to invoke an event handler in the gui thread. You
could pass information with a custom event or set up a shared mutable
object beforehand.
http://wxruby.rubyforge.org/doc/evthandler.html#EvtHandler_addpendingevent
On Sun, Oct 31, 2010 at 8:57 AM, Galen L. [email protected]
wrote:
I’m new myself but perhaps you can use EvtHandler#add_pending_event from
a standard thread to invoke an event handler in the gui thread.
Thank you Galen,
I’ll give it a try and let you know if it work.
bio.
Anyone know how to solve this?:
On Thu, Oct 28, 2010 at 4:47 PM, Fabio P.
[email protected]wrote:
It’s just fine if the gui update takes short time but, sometimes, the gui
On the other side, using ruby thread in combination with Thread.pass is
good for external process not involving gui updates
So, what is the right way to go to update gui interface on a separate
thread using wxruby?
Any suggestion would greately appreciated.
bio.
Is it the case to consider the inclusion of WxRuby Threads into the
wxruby
package?
Thank you.
bio.
Hi
Actually all the gui updates occurs in response to the user
actions into the main wxruby process.
It's just fine if the gui update takes short time but, sometimes,
the gui update is a long running task and the user get stuck
waiting for the process to complete.
Is it strictly GUI code that takes ages to run?
What you could do if there is a lot of computation involved in updating
the GUI is have the process which works out what needs to be changed
running in a separate thread, then posting messages to the main thread
so that the actual visual update takes place incrementally whilst the
GUI remains responsive.
Another option is just to run the updating code in an evt_idle loop -
again, it will only happen when there is spare time to update the GUI.
It would be nice to have gui update running on a separate thread.
The first thing i thought was:
ok i use the wxThread to update my long running gui task but
unfortunately it's not included in wxruby distribution.
I don’t think it will do anything that Ruby (1.9) native OS threads
can’t do?
alex
On Mon, Nov 1, 2010 at 2:59 PM, Fabio P.
[email protected]wrote:
On Sun, Oct 31, 2010 at 8:57 AM, Galen L. [email protected] wrote:
I’m new myself but perhaps you can use EvtHandler#add_pending_event from
a standard thread to invoke an event handler in the gui thread.
Unfortunately it didn’t works:
EvtHandler#add_pending_event execute the code asynchronously (usually
during
the next event loop iteration) but not in a separate thread.
So my problem is still there: have gui update running on a separate
thread.
In one of the archived posts Alex (Fenton) say this:
If using 1.8, you need to manually nudge Ruby’s thread scheduler to give
time to the RInotify thread. If using 1.9, this won’t be needed, but you
must not call GUI update code in the non-wx thread. GUI updates must be
signalled by posting a Wx::Event to the GUI loop.
As i know processing an event could be done as follow:
- EvtHandler#process_event
- EvtHandler#add_pending_event
Anyone know how to signal a gui event to be processed in a separate
thread?
Thank you all,
bio.