I have not worked on wxRuby2 for awhile and decided to download the latest CVS HEAD and saw that it still had a problem with wxWindow::GetTextExtent (in my case showing up when editing Grid cells). So I copied the method signature from the wxDC::GetTextExtent which seems to be working, changed 2 variable names and made the typemap the same as used for wxDC. Well in my program editing grid cells does not crash anymore. This patch also has the global function wxGetKeyState added, which needed a few typemaps as well. The list has been pretty quiet is anyone else working on anything? Sean _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Here is a cleaner patch with the proper directory name, has been awhile since I made a patch. :) Sean On 7/18/06, Sean Long <sean.m.long at gmail.com> wrote:> I have not worked on wxRuby2 for awhile and decided to download the > latest CVS HEAD and saw that it still had a problem with > wxWindow::GetTextExtent (in my case showing up when editing Grid > cells). So I copied the method signature from the wxDC::GetTextExtent > which seems to be working, changed 2 variable names and made the > typemap the same as used for wxDC. Well in my program editing grid > cells does not crash anymore. > > This patch also has the global function wxGetKeyState added, which > needed a few typemaps as well. > > > The list has been pretty quiet is anyone else working on anything? > > > Sean > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: diff.patch Type: application/octet-stream Size: 3078 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060719/34e3469f/attachment.obj
Thanks. I''m in the middle of a construction project. I''ll try to take a look at this sometime later this week. Kevin On Wed, 2006-07-19 at 09:16 -0700, Sean Long wrote:> Here is a cleaner patch with the proper directory name, has been > awhile since I made a patch. :) > > Sean > > On 7/18/06, Sean Long <sean.m.long at gmail.com> wrote: > > I have not worked on wxRuby2 for awhile and decided to download the > > latest CVS HEAD and saw that it still had a problem with > > wxWindow::GetTextExtent (in my case showing up when editing Grid > > cells). So I copied the method signature from the wxDC::GetTextExtent > > which seems to be working, changed 2 variable names and made the > > typemap the same as used for wxDC. Well in my program editing grid > > cells does not crash anymore. > > > > This patch also has the global function wxGetKeyState added, which > > needed a few typemaps as well. > > > > > > The list has been pretty quiet is anyone else working on anything? > > > > > > Sean > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Sean Long wrote:> Well in my program editing grid cells does not crash anymore.Thanks for the patch, works for me too on the system_settings sample.> The list has been pretty quiet is anyone else working on anything?Haven''t done a lot for last month or two, new job, world cup and unusually nice british weather. I''ve been working on a set of syntax extensions to Wx to reduce some of the C++-ish verbosity. http://rubyforge.org/cgi-bin/viewvc.cgi/weft-qda/lib/wx_extensions/all.rb?revision=1.2&root=weft-qda Using all the extensions I get about a 30%+ reduction in LOC, plus (I hope) more readable code. I''ll bundle and release when I''ve fixed a few bugs in layout.rb (which provides easier API to use Sizers). Whenever wxruby gets mentioned on c.l.r. there always seems to be lots of interest - I''m keen to put in some time to push out an alpha release soon. I''ve updated the wiki to include info on installing wxruby2, and perhaps I could help by updating the bugs/feature request list so we know what''s blocking us getting a release out. I''d suggest archiving any bugs relating to 0.6.0, and reducing the priority of anything except show-stoppers. Let me know if this would be helpful. cheers alex
> I''ve been working on a set of syntax > extensions to Wx to reduce some of the C++-ish verbosity. > Using all the extensions I get about a 30%+ reduction in LOC, plus (I > hope) more readable code. I''ll bundle and release when I''ve fixed a few > bugs in layout.rb (which provides easier API to use Sizers).I am interested in the extensions when you have them ready.> Whenever wxruby gets mentioned on c.l.r. there always seems to be lots > of interestI can not think of what c.l.r is can you fill me in?> I''ve updated the wiki to include info on installing wxruby2, and perhaps > I could help by updating the bugs/feature request list so we know what''s > blocking us getting a release out. I''d suggest archiving any bugs > relating to 0.6.0, and reducing the priority of anything except > show-stoppers. Let me know if this would be helpful.I think having a list of goals for a release would really help focus the few developers we have. Maybe if we have a release it will catch the eye of a developer or two who can then help move the project along. I think we should not spend any time on the old wxRuby 0.6 unless it is a critical bug, from my perspective the wxRuby2 code has exceeded the old code base in usability. Sean
Sean Long wrote:> I am interested in the extensions when you have them ready.Thanks. The link gives an idea of the different behaviours that are implemented so far.>> Whenever wxruby gets mentioned on c.l.r. there always seems to be lots >> of interest >> > > I can not think of what c.l.r is can you fill me in? >comp.lang.ruby newsgroup> I think having a list of goals for a release would really help focus > the few developers we have. Maybe if we have a release it will catch > the eye of a developer or two who can then help move the project > along. >Definitely. I know we''re short of person-time, so even just getting people (esp on Windows using a binary) to report bugs against a release version would really help I think.> I think we should not spend any time on the old wxRuby 0.6 unless it > is a critical bug, from my perspective the wxRuby2 code has exceeded > the old code base in usability. >Ditto. Kevin - perhaps you could add me as a member of wxruby on rubyforge, just with access to tracker items and documents only. I''ll start by checking the bugs and feature requests and marking any that relate to 0.6.0 as ''old''. cheers alex
I just (finally) committed these patches into the wxruby2 cvs tree. Woo-hoo! Ideally, when submitting patches: 1. Please bundle related patches in a single email, and split unrelated patches into separate emails. I split this one into two parts. This will be especially important when we move to a changeset-based vcs tool like svn (or bzr). 2. For code style, I prefer "int* x" over "int * x" (both of those are better than "int *x"). Not a huge deal. Thanks, Kevin On Wed, 2006-07-19 at 09:16 -0700, Sean Long wrote:> Here is a cleaner patch with the proper directory name, has been > awhile since I made a patch. :) > > Sean > > On 7/18/06, Sean Long <sean.m.long at gmail.com> wrote: > > I have not worked on wxRuby2 for awhile and decided to download the > > latest CVS HEAD and saw that it still had a problem with > > wxWindow::GetTextExtent (in my case showing up when editing Grid > > cells). So I copied the method signature from the wxDC::GetTextExtent > > which seems to be working, changed 2 variable names and made the > > typemap the same as used for wxDC. Well in my program editing grid > > cells does not crash anymore. > > > > This patch also has the global function wxGetKeyState added, which > > needed a few typemaps as well. > > > > > > The list has been pretty quiet is anyone else working on anything? > > > > > > Sean > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Kevin Smith wrote:> 2. For code style, I prefer "int* x" over "int * x" (both of those are > better than "int *x"). Not a huge deal. > >Hmm, not to get into a style war, but I find int* x to be somewhat ambiguous: int* x,y; The type of y isn''t int*, which is what int* ''implies''. I''d pick int * x over int* x any day. Though, for clarity, int *x is my choice. Roy
On Sun, 2006-08-13 at 10:59 -0400, Roy Sutton wrote:> Kevin Smith wrote: > > 2. For code style, I prefer "int* x" over "int * x" (both of those are > > better than "int *x"). Not a huge deal. > > > > > Hmm, not to get into a style war, but I find int* x to be somewhat > ambiguous: > > int* x,y; > > The type of y isn''t int*, which is what int* ''implies''. I''d pick int * > x over int* x any day. Though, for clarity, int *x is my choice.I see your point, but I strongly feel that you should NEVER declare more than one variable on a line. I consider it to be a bug in the language design. I think of it as "x is an int*", so having the * next to x is just confusing. Perhaps we should go with "int * x" then, as a compromise. Kevin