From: <mac...@gm...> - 2012-09-25 23:16:30
|
Including wxhaskell-users. Anyone interested in async UI update functionality? Cheers, Maciek ---------- Forwarded message ---------- From: <mac...@gm...> Date: Fri, Aug 24, 2012 at 10:41 PM Subject: UI updates from non-UI threads: an addition to wx? To: wxhaskell-devel <wxh...@li...> Getting wxHaskell to handle UI updates from non-UI threads was a frustrating experience; it's embarassing how long it took me to realise that the solution presented in this StackOverflow answer: http://stackoverflow.com/a/3182588/424978 is probably the only viable one. I've packaged it into a tiny module that provides Gtk2hs-style `postGUIAsync` function: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs. Is there any interest in incorporating this into wxHaskell proper? It might save other users some head scratching. Regards, Maciek |
From: Henning T. <le...@he...> - 2012-09-26 07:21:32
|
On Wed, 26 Sep 2012, mac...@gm... wrote: > Including wxhaskell-users. Anyone interested in async UI update functionality? Am I right that the solution on StackOverflow uses a busy-wait using the Wx Timer? I think this is a bad idea and I found a better solution at: http://snipplr.com/view/17538/ However, it seems to be essential what eventId you use. The value in the above example (wxID_HIGHEST+1) was already used in my system and this lead to strange behavior. I think wxhaskell should provide support for finding free event ids. |
From: Henning T. <le...@he...> - 2012-09-26 07:30:56
|
On Wed, 26 Sep 2012, Henning Thielemann wrote: > However, it seems to be essential what eventId you use. The value in the > above example (wxID_HIGHEST+1) was already used in my system and this lead > to strange behavior. I think wxhaskell should provide support for finding > free event ids. If you want to see this technique in action: http://code.haskell.org/alsa/gui/src/controller.hs http://code.haskell.org/alsa/gui/src/Common.hs I have implemented both the busy wait (reactOnEventTimer) and the event-driven method (reactOnEvent). |
From: <mac...@gm...> - 2012-09-26 20:43:14
|
Thanks for this, and for responding to the SO question. I'll see if I can rewrite the run async abstraction using your solution. Cheers, Maciek On Wed, Sep 26, 2012 at 8:30 AM, Henning Thielemann <le...@he...> wrote: > > On Wed, 26 Sep 2012, Henning Thielemann wrote: > >> However, it seems to be essential what eventId you use. The value in the >> above example (wxID_HIGHEST+1) was already used in my system and this lead >> to strange behavior. I think wxhaskell should provide support for finding >> free event ids. > > > > If you want to see this technique in action: > http://code.haskell.org/alsa/gui/src/controller.hs > http://code.haskell.org/alsa/gui/src/Common.hs > > I have implemented both the busy wait (reactOnEventTimer) and the > event-driven method (reactOnEvent). |
From: <mac...@gm...> - 2012-09-30 12:21:06
|
I have now updated the module to use event-based notifications instead of polling: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs. The original question still stands: is it worth exposing this sort of abstraction as a part of wxHaskell? Regards, Maciek On Wed, Sep 26, 2012 at 9:43 PM, <mac...@gm...> wrote: > Thanks for this, and for responding to the SO question. I'll see if I > can rewrite the run async abstraction using your solution. > > Cheers, > Maciek > > On Wed, Sep 26, 2012 at 8:30 AM, Henning Thielemann > <le...@he...> wrote: >> >> On Wed, 26 Sep 2012, Henning Thielemann wrote: >> >>> However, it seems to be essential what eventId you use. The value in the >>> above example (wxID_HIGHEST+1) was already used in my system and this lead >>> to strange behavior. I think wxhaskell should provide support for finding >>> free event ids. >> >> >> >> If you want to see this technique in action: >> http://code.haskell.org/alsa/gui/src/controller.hs >> http://code.haskell.org/alsa/gui/src/Common.hs >> >> I have implemented both the busy wait (reactOnEventTimer) and the >> event-driven method (reactOnEvent). |
From: Henning T. <le...@he...> - 2013-01-12 12:09:06
|
On Sun, 30 Sep 2012, mac...@gm... wrote: > I have now updated the module to use event-based notifications instead > of polling: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs. > The original question still stands: is it worth exposing this sort of > abstraction as a part of wxHaskell? Since no other one seems to answer ... I would like to see this functionality in a package, either a separate package or integrated in wx. In any case I think that the wx/wxcore package bundle must contain a function for providing us with free(!) event ids. This cannot be done reliably in a third party package. |