Hi I just committed a set of changes to trunk to fix some problematic bugs with using custom Events with Threads. This mainly concerns Ruby 1.9, where ruby threads are real OS threads. In wxWidgets, GUI code should only be done in the main thread, and updates from other threads are meant to be signalled by posting events using add_pending_event. However at the moment add_pending_event is not GC-safe for use with user-written Event classes. The changes fix this, and also make user-written event classes work more naturally - instance variables of a ruby-subclass Event object are now preserved (rather than having to stuff them in client_data). Inheriting from CommandEvent and Event both work properly (well, still one prob with CmdEv to fix...). This introduces a minor API incompatibility with 2.0, but I''d like to commit to the stable branch unless anyone objects. Code written for 2.0 will still work with 2.0.1, but not necessarily the other way around. But I feel it''s justified by the serious bug fix it resolves. Overall, I''d like to release a version 2.0.1 incorporating this and other smaller fixes we''ve accumulated. Anything else we ought to look at before then? thanks alex
Hi, On Thu, May 14, 2009 at 4:40 PM, Alex Fenton <alex at pressure.to> wrote:> > I just committed a set of changes to trunk to fix some problematic bugs with > using custom Events with Threads. This mainly concerns Ruby 1.9, where ruby > threads are real OS threads. In wxWidgets, GUI code should only be done in > the main thread, and updates from other threads are meant to be signalled by > posting events using add_pending_event. However at the moment > add_pending_event is not GC-safe for use with user-written Event classes. > > The changes fix this, and also make user-written event classes work more > naturally - instance variables of a ruby-subclass Event object are now > preserved (rather than having to stuff them in client_data). Inheriting from > CommandEvent and Event both work properly (well, still one prob with CmdEv > to fix...). > > This introduces a minor API incompatibility with 2.0, but I''d like to commit > to the stable branch unless anyone objects. Code written for 2.0 will still > work with 2.0.1, but not necessarily the other way around. But I feel it''s > justified by the serious bug fix it resolves.That''s fine for me even if I would prefer a 2.1.0 release to make the incompatibility issue more clear to the users. This does not necessarily require another branch but maybe the wxruby_2_0_stable branch should have been named wxruby_2_stable> Overall, I''d like to release a version 2.0.1 incorporating this and other > smaller fixes we''ve accumulated. Anything else we ought to look at before > then?If there is a 2.1.0 release instead of a 2.0.1, we could introduce improvements to Wx::Font and Wx::GLCanvas to support keyword arguments in their initializer. For Wx::GLCanvas, this is more a bug than an improvement as Wx::GLCanvas is a subclass of Wx::Window which supports keyword arguments. Cheers. Chauk-Mean.
Chauk-Mean Proum wrote:> If there is a 2.1.0 release instead of a 2.0.1, we could introduce > improvements to Wx::Font and Wx::GLCanvas to support keyword arguments > in their initializer. > For Wx::GLCanvas, this is more a bug than an improvement as > Wx::GLCanvas is a subclass of Wx::Window which supports keyword > arguments. >I agree with you about GLCanvas and happy for its keyword_args to go in the next stable release. From the documentation we provide one would expect GLCanvas.new(kword_args) to work, and similarly EventHandler.add_pending_event is doc''d but just broken at the moment in 2.0. Overall still slightly prefer a 2.0.1 as these are very minor changes that are nearer bugfixes. cheers alex