From noreply at rubyforge.org Fri May 1 15:46:36 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 1 May 2009 15:46:36 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-25749 ] DateTimePicker#get_range badly swiged - General DateTime support Message-ID: <20090501194637.27A17197857C@rubyforge.org> Bugs item #25749, was opened at 01/05/2009 21:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25749&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: DateTimePicker#get_range badly swiged - General DateTime support Initial Comment: DateTimePicker#get_range badly swig'ed - General DateTime support I recently had to use a DatePickerCtrl in my project, everything seemed to be okay, but it was not. There were some problems: 1. Invalid objects. In WxWidgets a wxDateTime may be invalid (containing no valid date). This is used throughout the API. For DatePickerCtrl it is used to set the date to "none" (only possible with the style DP_ALLOWNONE) and by the way, to get back this value. In Ruby Time objects may not be invalid, they are always valid. So we miss a feature here. I changed the typemap for the wxDateTime type. It now accepts a nil value and converts it to an invalid wxDateTime object. The opposite is also done, an invalid wxDateTime will be converted to nil. 2. Date ranges. Currently the typemap can convert from a Ruby Time-like object to wxDateTime but not the opposite, so when we have a date outside the range 1970-2038 (on the majority of platforms), we get an exception. I changed the typemap to construct a Ruby DateTime object when it is out of range. 3. DatePickerCtrl#get_range Looking at the DatePickerCtrl methods faced another problem: the #get_range method. It should be able to get the min and max date accepted by the control (if previously set by #set_range). But the method signature was bad, even swig'ed it still was: Boolean get_range(dt1, dt2) dt1 and dt2 were supposed to be out values (in C++ they are pointers) but swig handles them as input references. So i re-implemented the get_range method to return an two cells array containing the range (note that I didn't used Ruby Ranges because one or both range ends may be nil). That's it. Please review the patch, I've included patches for swig files, doc files and I also updated the calender sample to show usage of DatePickerCtrl (I've done a 'blind' transcript of the C++ sample) Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25749&group_id=35 From noreply at rubyforge.org Sat May 2 10:54:43 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 2 May 2009 10:54:43 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Patches-25757 ] Add stock wxWidgets function for managind ID's Message-ID: <20090502145443.E94CE1598074@rubyforge.org> Patches item #25757, was opened at 02/05/2009 16:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25757&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: Add stock wxWidgets function for managind ID's Initial Comment: Function.i miss some stock wxWidgets function for managing ID's, they are: long wxNewId(); void wxRegisterId(long id); long wxGetCurrentId(); The patch simply add these functions so they are available on wxRuby. Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25757&group_id=35 From noreply at rubyforge.org Sat May 2 11:38:53 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 2 May 2009 11:38:53 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-25758 ] ListCtrl#get_selections returns an empty Array (on Windows) Message-ID: <20090502153853.DFF3718581E9@rubyforge.org> Bugs item #25758, was opened at 02/05/2009 17:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25758&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: ListCtrl#get_selections returns an empty Array (on Windows) Initial Comment: Hi, The new helper method #get_selections for ListCtrl doesn't work correctly at least on my machine: Ruby 1.8.6, Windows XP 32bits. I supply a patch to resolve the issue. The flag passed to get_next_item was LIST_NEXT_BELOW, I replaced it with the more general one (according to the docs) LIST_NEXT_ALL. Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25758&group_id=35 From noreply at rubyforge.org Sat May 2 18:09:30 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 2 May 2009 18:09:30 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Patches-25761 ] Add support for AuiToolBar and associated classes Message-ID: <20090502220931.0B6031858109@rubyforge.org> Patches item #25761, was opened at 03/05/2009 00:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25761&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: Add support for AuiToolBar and associated classes Initial Comment: Hi, I'm still going further on wxAui support within wxRuby. So here is a patch to add support for the AuiToolBar class and its dependencies: - AuiToolBarArt - AuiDefaultToolBarArt - AuiToolBarEvent - AuiToolBarItem Currently wxWidgets has no docs on these classes while they are supported. So there are also no docs for wxRuby. This should be added later (maybe after the on-going freshup work done in wxAui). The C headers already contain the new API that has been commited in wxWidgets trunk, but commented (until wxWidgets releases the next version and wxRuby be based on it). Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25761&group_id=35 From mario at ruby-im.net Sat May 2 21:31:01 2009 From: mario at ruby-im.net (Mario Steele) Date: Sat, 2 May 2009 20:31:01 -0500 Subject: [wxruby-development] [ wxruby-Patches-25761 ] Add support for AuiToolBar and associated classes In-Reply-To: <20090502220931.0B6031858109@rubyforge.org> References: <20090502220931.0B6031858109@rubyforge.org> Message-ID: Man, we've been getting quite a few patches from Pascal, adding new support for various classes. Has anyone looked over this guys work, to see how he is at making these patches? On 5/2/09, noreply at rubyforge.org wrote: > Patches item #25761, was opened at 03/05/2009 00:09 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=220&aid=25761&group_id=35 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Pascal Hurni (phi) > Assigned to: Nobody (None) > Summary: Add support for AuiToolBar and associated classes > > Initial Comment: > Hi, > > I'm still going further on wxAui support within wxRuby. > > So here is a patch to add support for the AuiToolBar class and its > dependencies: > - AuiToolBarArt > - AuiDefaultToolBarArt > - AuiToolBarEvent > - AuiToolBarItem > > Currently wxWidgets has no docs on these classes while they are supported. > So there are also no docs for wxRuby. This should be added later (maybe > after the on-going freshup work done in wxAui). > > The C headers already contain the new API that has been commited in > wxWidgets trunk, but commented (until wxWidgets releases the next version > and wxRuby be based on it). > > Regards, > > Pascal > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=220&aid=25761&group_id=35 > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ From alex at pressure.to Mon May 4 14:49:05 2009 From: alex at pressure.to (Alex Fenton) Date: Mon, 04 May 2009 19:49:05 +0100 Subject: [wxruby-development] [ wxruby-Patches-25761 ] Add support for AuiToolBar and associated classes In-Reply-To: References: <20090502220931.0B6031858109@rubyforge.org> Message-ID: <49FF38A1.10706@pressure.to> Mario Steele wrote: > we've been getting quite a few patches from Pascal, adding new > support for various classes. Has anyone looked over this guys work, > to see how he is at making these patches? Pascal has submitted numerous good bug reports and patches in the past. I plan to integrate these once I've had a chance to review them a From noreply at rubyforge.org Mon May 4 16:36:50 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 4 May 2009 16:36:50 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-25775 ] auimanager load_pane_info fails Message-ID: <20090504203650.AFDB81598075@rubyforge.org> Bugs item #25775, was opened at 2009-05-04 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25775&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: auimanager load_pane_info fails Initial Comment: methods expects wxString but gets a String changing: void LoadPaneInfo(wxString pane_part, wxAuiPaneInfo &pane); To: void LoadPaneInfo(const wxString& pane_part, wxAuiPaneInfo &pane); in wxAuiManager.h fixed it ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25775&group_id=35 From noreply at rubyforge.org Tue May 5 03:21:11 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 May 2009 03:21:11 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Patches-25781 ] Add the AuiFloatingFrame class Message-ID: <20090505072111.F364E1678111@rubyforge.org> Patches item #25781, was opened at 05/05/2009 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25781&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: Add the AuiFloatingFrame class Initial Comment: Hi, Here is a patch to add support for the AuiFloatingFrame class. This class isn't usefull in itself, but we may need it for identity purpose. I have a situation where I must climb up the window parent relationship and I may end up in a AuiFloatingFrame as top level window. def find_top_level top_level = self top_level = top_level.get_parent until top_level.is_top_level top_level end Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=25781&group_id=35 From pascal_hurni at fastmail.fm Tue May 5 04:59:37 2009 From: pascal_hurni at fastmail.fm (Pascal Hurni) Date: Tue, 05 May 2009 10:59:37 +0200 Subject: [wxruby-development] More thought on bug #24865 Message-ID: <49FFFFF9.8040604@fastmail.fm> Hi folks, I filed a bug some days ago, #24865 The is_modal method was no more virtual, so my code broke. My specific use of #is_modal is in system handling semi-modal dialog boxes. So I need to trap IsModal from the legacy code. Then I came along the new SWIG macro: SWIG_WXTOPLEVELWINDOW_NO_USELESS_VIRTUALS It is responsible of the new behaviour, for those who don't know, it removes the 'virtualness' of a bunch of methods. In these there's the one I use: is_modal. I understand the need to lower the library size and also the speed concern. But which methods should we 'unvirtualize' ? Regards, Pascal From alex at pressure.to Tue May 5 05:19:16 2009 From: alex at pressure.to (Alex Fenton) Date: Tue, 05 May 2009 10:19:16 +0100 Subject: [wxruby-development] More thought on bug #24865 In-Reply-To: <49FFFFF9.8040604@fastmail.fm> References: <49FFFFF9.8040604@fastmail.fm> Message-ID: <4A000494.4020303@pressure.to> Pascal Hurni wrote: > I filed a bug some days ago, #24865 > The is_modal method was no more virtual, so my code broke. > My specific use of #is_modal is in system handling semi-modal dialog > boxes. So I need to trap IsModal from the legacy code. > > Then I came along the new SWIG macro: > SWIG_WXTOPLEVELWINDOW_NO_USELESS_VIRTUALS > It is responsible of the new behaviour, for those who don't know, it > removes the 'virtualness' of a bunch of methods. In these there's the > one I use: is_modal. > > I understand the need to lower the library size and also the speed > concern. But which methods should we 'unvirtualize' ? It's not only size and speed, but that directors will cause fatal errors and crashes in some cases if the method is virtual, because it hides the correct implementation. Eg you end up with an endless loop and StackError. The difficult bit of deciding which to 'virtualize' is that 'virtual' is used in two slightly different ways. Firstly there are methods in base (possibly abstract) classes (like wxWindow, wxTopLevelWindow) which are always overridden in concrete C++ subclasses. Here it's probably a mistake to have director methods in ruby, at least in the subclasses, because they can never be usefully redefined in those classes. The NO_USELESS_VIRTUALS macros are meant to catch these. Secondly there are methods which it is expected that user-written C++ (and hence Ruby) subclasses will define themselves. These definitely need 'director'. Sorry I haven't yet taken a detailed look at that specific bug. alex From noreply at rubyforge.org Tue May 5 08:59:39 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 May 2009 08:59:39 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-25783 ] bad method_missing implementation for the RubyStyleAccessors module Message-ID: <20090505125939.A3B3918581DE@rubyforge.org> Bugs item #25783, was opened at 05/05/2009 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25783&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: bad method_missing implementation for the RubyStyleAccessors module Initial Comment: Since wxRuby extends all classes with RubyStyleAccessors, the method_missing method of all these classes is replaced. The wrong side is that if any Wx class gets also extended by client code (my app) then the RubyStyleAccessors will catch first and it currently does not propagate the method_missing. The attached patch simply replace the code the re-raise the exception in method_missing by a call to 'super' which takes care of the inheritance chain. Regards, Pascal ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25783&group_id=35 From pascal_hurni at fastmail.fm Tue May 5 09:06:29 2009 From: pascal_hurni at fastmail.fm (Pascal Hurni) Date: Tue, 05 May 2009 15:06:29 +0200 Subject: [wxruby-development] More thought on bug #24865 In-Reply-To: <4A000494.4020303@pressure.to> References: <49FFFFF9.8040604@fastmail.fm> <4A000494.4020303@pressure.to> Message-ID: <4A0039D5.6080904@fastmail.fm> Alex Fenton a ?crit : > > It's not only size and speed, but that directors will cause fatal errors > and crashes in some cases if the method is virtual, because it hides the > correct implementation. Eg you end up with an endless loop and StackError. I wasn't aware of these kind of problems. > > Secondly there are methods which it is expected that user-written C++ > (and hence Ruby) subclasses will define themselves. These definitely > need 'director'. That makes sense, yes. > > Sorry I haven't yet taken a detailed look at that specific bug. > Don't look at the bug, I was simply saying that the behaviour changed from 1.9.8 to 2.0.0, and thus I filed a bug (in my sense). Note that I can live with these methods being 'unvirtualized', but I think we should document these changes (maybe a note on every method 'unvirtualized' ?) My point was to know what happend and how the 'bad' methods list was setup. Thanx for these clarifications. Regards, Pascal From alex at pressure.to Thu May 14 10:40:37 2009 From: alex at pressure.to (Alex Fenton) Date: Thu, 14 May 2009 15:40:37 +0100 Subject: [wxruby-development] version 2.0.1, Event fixes Message-ID: <4A0C2D65.4030409@pressure.to> 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 From noreply at rubyforge.org Thu May 14 17:46:22 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 14 May 2009 17:46:22 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-25907 ] CheckListbox append doesn't return location of new item (Fix attached) Message-ID: <20090514214623.1177618580FE@rubyforge.org> Bugs item #25907, was opened at 2009-05-14 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25907&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Satterwhite (msatterwhite) Assigned to: Nobody (None) Summary: CheckListbox append doesn't return location of new item (Fix attached) Initial Comment: When append is called, a checklistbox is supposed to return the index of the newly inserted item. Currently, it returns a nil. The following code will correct the problem. I'm running wxruby 2.0.0.0 Fix: 14c14 < super(item) --- > n = super(item) 15a16 > return n ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=25907&group_id=35 From chauk.mean at gmail.com Fri May 15 03:51:15 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Fri, 15 May 2009 09:51:15 +0200 Subject: [wxruby-development] missing iconv.so in MingW In-Reply-To: <49F733D8.6040504@pressure.to> References: <49F733D8.6040504@pressure.to> Message-ID: Hi, On Tue, Apr 28, 2009 at 6:50 PM, Alex Fenton wrote: > Just been trying out the MingW wxruby setup. Nice installer! Thanks. I still have to write the recipe. I've been quite busy recently. > One small problem I found is that the iconv library is missing from the ruby > installation - I replaced it with my iconv.so from my other Ruby 1.9 > installation (also MingW) and it worked fine. I thought iconv was not useful as ruby 1.9 has encoding conversion features. For my information, what is the additional feature not found in the built-in conversion ? Anyway, I will include it in the next version of the installer in addition to the support of ruby-opengl. Is there anything else you would like to include in the installer ? Cheers. Chauk-Mean. From chauk.mean at gmail.com Fri May 15 04:12:35 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Fri, 15 May 2009 10:12:35 +0200 Subject: [wxruby-development] version 2.0.1, Event fixes In-Reply-To: <4A0C2D65.4030409@pressure.to> References: <4A0C2D65.4030409@pressure.to> Message-ID: Hi, On Thu, May 14, 2009 at 4:40 PM, Alex Fenton 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. From alex at pressure.to Fri May 15 06:09:07 2009 From: alex at pressure.to (Alex Fenton) Date: Fri, 15 May 2009 11:09:07 +0100 Subject: [wxruby-development] missing iconv.so in MingW In-Reply-To: References: <49F733D8.6040504@pressure.to> Message-ID: <4A0D3F43.1020505@pressure.to> Hi Chauk-Mean Chauk-Mean Proum wrote: > Thanks. I still have to write the recipe. > I've been quite busy recently. > Cool, me too, just had a bit of time to put into tidying some issues and bugs. Hopefully the ruby-installer people will have a more finalised version to offer soon. >> One small problem I found is that the iconv library is missing from the ruby >> installation - I replaced it with my iconv.so from my other Ruby 1.9 >> installation (also MingW) and it worked fine. >> > > I thought iconv was not useful as ruby 1.9 has encoding conversion features. > For my information, what is the additional feature not found in the > built-in conversion ? > Hmm, I don't know that it does do anything extra, although I don't know that it doesn't - not sure if String now supports all the possible encodings of iconv. It was just I have a program that was originally written for 1.8 which uses iconv, and iconv is still part of the standard library. > Anyway, I will include it in the next version of the installer in > addition to the support of ruby-opengl. > Is there anything else you would like to include in the installer ? Not particularly at this time, thanks. Maybe wxSugar and ruby-gettext would be part of my standard GUI dev platform, but they're easily installable as gems. alex From alex at pressure.to Fri May 15 06:15:50 2009 From: alex at pressure.to (Alex Fenton) Date: Fri, 15 May 2009 11:15:50 +0100 Subject: [wxruby-development] version 2.0.1, Event fixes In-Reply-To: References: <4A0C2D65.4030409@pressure.to> Message-ID: <4A0D40D6.6080201@pressure.to> 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 From noreply at rubyforge.org Fri May 15 16:04:23 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 15 May 2009 16:04:23 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Feature Requests-25923 ] evt_timer should accept a timer object and not only an ID Message-ID: <20090515200423.C6F87185824F@rubyforge.org> Feature Requests item #25923, was opened at 15/05/2009 22:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=25923&group_id=35 Category: API improvement Group: User request Status: Open Priority: 4 Submitted By: Chauk-Mean Proum (chauk-mean) Assigned to: Kevin Smith (qualitycode) Summary: evt_timer should accept a timer object and not only an ID Initial Comment: For usability and consistency with other evt_xxx methods, evt_timer should also accept a timer object. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=25923&group_id=35 From chauk.mean at gmail.com Tue May 19 04:06:25 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Tue, 19 May 2009 10:06:25 +0200 Subject: [wxruby-development] About GLCanvas initializer Message-ID: Hi, I have a proposal for several problems related with the GLCanvas initializer. 1/ the current 3 forms of constructors / initializers does not allow a simple support for keyword arguments : GLCanvas.new(Window parent, Integer id = -1, Point pos = DEFAULT_POSITION, Size size = DEFAULT_SIZE, Integer style=0, String name="GLCanvas", Integer attribList = 0, Palette palette = NullPalette) GLCanvas.new(Window parent, GLContext sharedContext, Integer id = -1, Point pos = DEFAULT_POSITION, Size size = DEFAULT_SIZE, Integer style=0, String name="GLCanvas", Integer attribList = 0, Palette palette = NullPalette) GLCanvas.new(Window parent, GLCanvas sharedCanvas, Integer id = -1, Point pos = DEFAULT_POSITION, Size size = DEFAULT_SIZE, Integer style=0, String name="GLCanvas", Integer attribList = 0, Palette palette = NullPalette) The additional sharedContext and sharedCanvas of the 2nd and 3rd form makes it difficult to use the facilities from keyword_ctrs.rb and keyword_defs.rb 2/ These 3 forms implicitly creates a GLContext (see the wxWidgets documentation). Currently, there is no way to create a GLCanvas without creating implicitly a GLContext at the wxRuby level. In wxWidgets, this is supported by the fourth form of constructor with the following C++ signature (see the location of attribList) : wxGLCanvas (wxWindow *parent, wxWindowID id=wxID_ANY, const int *attribList=NULL, const wxPoint &pos=wxDefaultPosition, const wxSize &size=wxDefaultSize, long style=0, const wxString &name="GLCanvas", const wxPalette &palette=wxNullPalette) As indicated in the documentation for wxWidgets 2.8.x, this fourth form is the preferred way. In wxWidgets 2.9.x, this is the correct way, the first 3 forms are deprecated and will be removed in the future. => My proposal : a) Add the 4th form at the wxRuby level : this will correct a missing feature b) Support keyword args only for this 4th form of constructor : this can be supported easily c) The first 3 forms are kept for compatibility but are made deprecated. Cheers. Chauk-Mean. From alex at pressure.to Tue May 19 06:55:57 2009 From: alex at pressure.to (Alex Fenton) Date: Tue, 19 May 2009 11:55:57 +0100 Subject: [wxruby-development] About GLCanvas initializer In-Reply-To: References: Message-ID: <4A12903D.6010404@pressure.to> Chauk-Mean Proum wrote: > I have a proposal for several problems related with the GLCanvas initializer. > > 1/ the current 3 forms of constructors / initializers does not allow a > simple support for keyword arguments : > .... > => My proposal : > a) Add the 4th form at the wxRuby level : this will correct a missing feature > b) Support keyword args only for this 4th form of constructor : this > can be supported easily > c) The first 3 forms are kept for compatibility but are made deprecated. Thanks for looking into this. I'm happy with what you propose, and don't see why it shouldn't go into stable if it's a missing but expected constructor variant. cheers alex From chauk.mean at gmail.com Tue May 26 14:00:26 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Tue, 26 May 2009 20:00:26 +0200 Subject: [wxruby-development] RMagick support for MinGW Message-ID: Hi, I've been able to build successfully ImageMagick and RMagick on MinGW. So, I will be able to include RMagick in the upcoming wxRuby-2.0.1 MinGW installer. I'll add shortly a sample of using RMagick with wxRuby. Cheers. Chauk-Mean. From chauk.mean at gmail.com Tue May 26 14:12:19 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Tue, 26 May 2009 20:12:19 +0200 Subject: [wxruby-development] Rubyforge ML archives are broken Message-ID: Hi, The svn-commit list archive has not been updated since March. Some messages in the dev and the users lists are not shown in the corresponding archive. Cheers. Chauk-Mean. From pascal_hurni at fastmail.fm Wed May 27 02:20:25 2009 From: pascal_hurni at fastmail.fm (Pascal Hurni) Date: Wed, 27 May 2009 08:20:25 +0200 Subject: [wxruby-development] RMagick support for MinGW In-Reply-To: References: Message-ID: <4A1CDBA9.6010008@fastmail.fm> Hi, Did you BTW managed or planned to also compile ruby-sqlite3 and mysql for MinGW ? (I personnaly compiled ruby-sqlite3 for ruby 1.9.1 mingw32) Cheers, Pascal Chauk-Mean Proum a ?crit : > Hi, > > I've been able to build successfully ImageMagick and RMagick on MinGW. > So, I will be able to include RMagick in the upcoming wxRuby-2.0.1 > MinGW installer. > I'll add shortly a sample of using RMagick with wxRuby. > > Cheers. > > Chauk-Mean. > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > > From chauk.mean at gmail.com Wed May 27 12:43:53 2009 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Wed, 27 May 2009 18:43:53 +0200 Subject: [wxruby-development] RMagick support for MinGW In-Reply-To: <4A1CDBA9.6010008@fastmail.fm> References: <4A1CDBA9.6010008@fastmail.fm> Message-ID: Hi Pascal, On Wed, May 27, 2009 at 8:20 AM, Pascal Hurni wrote: > Hi, > > Did you BTW managed or planned to also compile ruby-sqlite3 and mysql for > MinGW ? > I haven't tried to build these packages yet. Nevertheless, my motivation in building ruby-opengl and RMagick for MinGW was to provide packages that are closely related with wxRuby (i.e. enabling the display of OpenGL graphics and images transformed by RMagick). At the moment, I don't plan to add ruby-sqlite3 and mysql packages in the wxRuby MinGW installer as they are too general purpose. It may be relevant to add these packages if there are some wxRuby samples that make use of one of these DB for information storage. Cheers. Chauk-Mean. From noreply at rubyforge.org Fri May 29 08:36:46 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 May 2009 08:36:46 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-26062 ] TreeCtrl and ListCtrl corrupt their own DropTarget Message-ID: <20090529123646.81B451858123@rubyforge.org> Bugs item #26062, was opened at 2009-05-29 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=26062&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Muriel Salvan (muriel) Assigned to: Nobody (None) Summary: TreeCtrl and ListCtrl corrupt their own DropTarget Initial Comment: Greetings It seems that using DropTargets on Wx::ListCtrl and Wx::TreeCtrl components results in incorrect behaviour: although it works at the beginning, repeated drop on those components always end up in some kind of error, regardless of DropSource or DropTarget types used. The errors encountered are of 2 different kinds: 1. When entering/leaving the drop area, an exception occurs. Here, there are also 2 different scenarios: 1.1. If the DropSource comes from the same application, it results in a "Segmentation Fault". 1.2. If the DropSource comes from an external application, it results in a NoMethodError exception on methods on_enter or on_leave for objects Wx::IdleEvent or Wx::UpdateUIEvent. This happens even if the DropTarget defines correctly on_enter and on_leave. 2. While dragging over the drop area, the drop is always vetoed ('No way' mouse cursor displayed), even if the DropTarget always returns Wx::DRAG_COPY in on_drag_over method. The frequency of those errors can vary: * If the application contains only the faulty component (ListCtrl or TreeCtrl), droping works several times before getting an error. It is sometimes necessary to drag/drop 50 or 100 times to get it. * If the application contains many other components (like in the example below), the error comes very quickly after dragging over (crossing the component boundaries) and dropping a few times. I attach to this report a little test application that can be used to see the bug. It contains several components on a single frame. Each one of them has a DropTarget for files, always accepting any file. The first 2 components are TreeCtrl and ListCtrl. When a file (dragged from your explorer) is dropped on the components, it should just accept the drop silently. It does not work with TreeCtrl and ListCtrl. Here is the test procedure: 1. Run the application attached in this report 2. Drag a file from your explorer on the components to see the normal behaviour. 3. Drag a file on the TreeCtrl or ListCtrl, and see the error (either drop disabled or exception). If the error does not come first times, try again several times, dragging over the component's boundaries several times before dropping. The configuration used in my case is: * Windows XP Pro SP3 * Ruby 1.8.5 * wxruby 2.0.0 (installed using RubyGems) Please don't hesitate to tell me if you need any other explanations. Best regards, Muriel ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=26062&group_id=35 From ian at ianduggan.net Fri May 29 23:33:15 2009 From: ian at ianduggan.net (Ian Duggan) Date: Fri, 29 May 2009 20:33:15 -0700 Subject: [wxruby-development] ffi? Message-ID: <222747e50905292033n37e67fe8ie5dd46eff8974f90@mail.gmail.com> Hi all, I'm new to wxruby and to wxwindows and such, but I'm setting out to build a largish project using them I've been reviewing the site and examples and I noticed that one of the goals for the next release is reducing the swig bloat. I was wondering what consideration had gone into using something like FFI? There is at least one swig2ffi type thing that may be useful: http://www.ruby-forum.com/topic/184766 This would allow the library to skip over swig and even skip having the -dev libraries around at all when installing the gem, etc... maybe worth considering? Anyhow, the project looks nice. I look forward to working with it. Is there an active IRC channel that people hang out on? I can't seem to find one. --Ian