Ok so I made a lot of changes and the controls sample works pretty good now. What I changed or added: - Got all my modifications meshed into wxRuby2. - Added constructors to wxIcon.h - Changed Xrc.i to XmlResource.i and changed wxXrc to wxXmlResource within the file. I also had to change Xrc to XmlResource in rakewx.rb. - For backwards compatability with wxRuby 0.6 I added the subclass methods to XmlResource. - Changed line 5 of wx.i from wxruby2 to wx, could not get wxruby2 to work. I also changed line 13 in fixmodule.rb to mWx and line 11 in fixmainmodule.rb to mWx from mWxruby2. Also changed mWx in functions.i and XmlResource.i - Added the xrc example program (again) - Added typemap to finally get wxItemKind working correctly, gets rid of my fixedswigcode.rb hack. - Added the wxMenuItem class. - Added a type check for wxDateTime so CalendarCtrl now works properly with ruby class DateTime. - Changed $DEBUG in extconf.rb to $DEBUG_BUILD, for some reason it was clashing with mkmf on Windows. - Added wxBeginBusyCursor and wxEndBusyCursor to functions.i - Added wxToolTip class. - Many missing methods for existing classes. - Slight tweaks to the sample programs. I also made this patch so Kevin can use this patch command: patch -p1 <diff.list in the directory above wxruby2 As I said before I am going to be out of town starting Wed. so I will not have time to respond or fix anything related to this patch until next week, I may have time tonight to atleast check this list but that is about it. Sean Long _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Found a small problem with my patch:
In wxMenuItem.h the following two methods are specific to Windows and
should not be included:
// compatibility only, don''t use in new code
wxMenuItem(wxMenu *parentMenu,
int id,
const wxString& text,
const wxString& help,
bool isCheckable,
wxMenu *subMenu = (wxMenu *)NULL);
and
int GetRealId();
Once these are removed the above patch and additions compiles fine on
OS X 10.4 and Windows XP Pro. Sorry I don''t have time to submit a new
patch to replace the above.
I won''t be checking this list again until Saturday at the earliest,
happy hacking.
Sean
On 7/26/05, Sean Long <sean.m.long@gmail.com>
wrote:> Ok so I made a lot of changes and the controls sample works pretty good
now.
>
> What I changed or added:
>
> - Got all my modifications meshed into wxRuby2.
> - Added constructors to wxIcon.h
> - Changed Xrc.i to XmlResource.i and changed wxXrc to wxXmlResource
> within the file.
> I also had to change Xrc to XmlResource in rakewx.rb.
> - For backwards compatability with wxRuby 0.6 I added the subclass methods
to
> XmlResource.
> - Changed line 5 of wx.i from wxruby2 to wx, could not get wxruby2 to
> work. I also
> changed line 13 in fixmodule.rb to mWx and line 11 in
> fixmainmodule.rb to mWx from mWxruby2.
> Also changed mWx in functions.i and XmlResource.i
> - Added the xrc example program (again)
> - Added typemap to finally get wxItemKind working correctly, gets rid
> of my fixedswigcode.rb hack.
> - Added the wxMenuItem class.
> - Added a type check for wxDateTime so CalendarCtrl now works properly
> with ruby class DateTime.
> - Changed $DEBUG in extconf.rb to $DEBUG_BUILD, for some reason it was
> clashing with mkmf on Windows.
> - Added wxBeginBusyCursor and wxEndBusyCursor to functions.i
> - Added wxToolTip class.
> - Many missing methods for existing classes.
> - Slight tweaks to the sample programs.
>
> I also made this patch so Kevin can use this patch command:
> patch -p1 <diff.list
> in the directory above wxruby2
>
> As I said before I am going to be out of town starting Wed. so I will
> not have time to respond or fix anything related to this patch until
> next week,
> I may have time tonight to atleast check this list but that is about it.
>
> Sean Long
>
>
>
Sean Long wrote:> Ok so I made a lot of changes and the controls sample works pretty good now.I am quickly learning why Linus and other project maintainers ask folks to send small, self-contained patches, rather than large, monolithic ones like this. For anyone submitting patches, please try to create individual patches for each unit of work. That way, I can more easily review each one, and if I have questions about one of them, I can still apply the rest easily. Also, I can process a couple at a time when I have a spare moment, instead of doing a marathon session of getting it all to work at once.> What I changed or added: > > - Got all my modifications meshed into wxRuby2.Good to hear.> - Added constructors to wxIcon.hI had to comment out one of them in the .h file. For some reason all the %ignore lines in the .i file are being ignored by SWIG.> - Changed Xrc.i to XmlResource.i and changed wxXrc to wxXmlResource > within the file.I think that''s probably a good change, but I would like to have seen it as two separate patches (one to create XmlResource.i, and a second to move the existing xrcid function into it and get rid of Xrc.i. However, do we need custom code for xrcid any more? Won''t it automatically be exposed by SWIG as XmlResource.get_xrcid and isn''t that good enough? I haven''t merged this one in yet.> I also had to change Xrc to XmlResource in rakewx.rb.If XmlResource is in swig/classes/ (which is where it belongs) then Xrc should have been removed entirely from rakewx.rb.> - For backwards compatability with wxRuby 0.6 I added the subclass methods to > XmlResource.Ok.> - Changed line 5 of wx.i from wxruby2 to wx, could not get wxruby2 to > work. I also > changed line 13 in fixmodule.rb to mWx and line 11 in > fixmainmodule.rb to mWx from mWxruby2. > Also changed mWx in functions.i and XmlResource.iLet''s figure this one out. I really want the module to be wxruby2, not wx, so I didn''t apply your changes. Perhaps you just needed to do ''rake clean_src'' to clear out all the old files that still referred to wx?> - Added the xrc example program (again)Ok. I guess I dropped it on the floor somewhere. Sorry.> - Added typemap to finally get wxItemKind working correctly, gets rid > of my fixedswigcode.rb hack.Cool. One of these days I need to really understand all the different kinds of typemaps. They are VERY powerful, but also very cryptic.> - Added the wxMenuItem class.Ok. I had to %ignore a few items.> - Added a type check for wxDateTime so CalendarCtrl now works properly > with ruby class DateTime.Hm. At one point I had decided not to support wxDateTime at all, because I felt that folks should be using Ruby''s DateTime class instead. Is there a compelling reason to keep wxDateTime?> - Changed $DEBUG in extconf.rb to $DEBUG_BUILD, for some reason it was > clashing with mkmf on Windows.Ok, but I didn''t see this in the patch you sent.> - Added wxBeginBusyCursor and wxEndBusyCursor to functions.iOk, but the ruby way is to pass a block to BusyCursor.busy: BusyCursor.busy do ...stuff here end So the cursor is automatically cleaned up. I changed the controls sample to do it this way. Unfortunately, I can''t test that sample on my Linux box because we don''t yet support the Notebook class on Linux.> - Added wxToolTip class.Ok. I had to ignore one method.> - Many missing methods for existing classes.I had to %ignore a few.> - Slight tweaks to the sample programs.The only sample I saw changed was controls.rb. I changed the busy cursor part (see above). The other two changes looked confusing. You commented out one parameter, and you commented out a call to event.enable. Please explain why you made those changes.> > I also made this patch so Kevin can use this patch command: > patch -p1 <diff.list > in the directory above wxruby2Thanks. Kevin
(Copying the list, since I''m guessing you intended your reply to be public) Sean Long wrote:>>My other question stands: Do we still need to create the xrcid global >>function as a special case? > > Depends on how closely we want to follow wxWidgets c++ implementation.Ah. I just now noticed that in addition to the XmlResource::GetXRCID method, there is also a convenience macro named XRCID. Yes, we should support both. The XRCID macro can just go in Functions.i, so Xrc.i can still disappear.>>So can we kill off DateTime.i? > > My local copy and the copy I just got from CVS do not have DateTime.i > just the wxDateTime.h files.You are so right! No need to kill something that already doesn''t exist. We''ll leave wxDateTime out of wxruby2.> How about just a DateTime.i with a SWIG comment at the top saying not > to add this class? That would be the simple solution, not sure if SWIG > will process it correctly.I''ll try something along those lines. Thanks, Kevin
> > - Changed line 5 of wx.i from wxruby2 to wx, could not get wxruby2 to > > work. I also > > changed line 13 in fixmodule.rb to mWx and line 11 in > > fixmainmodule.rb to mWx from mWxruby2. > > Also changed mWx in functions.i and XmlResource.i> Let''s figure this one out. I really want the module to be wxruby2, not > wx, so I didn''t apply your changes. Perhaps you just needed to do ''rake > clean_src'' to clear out all the old files that still referred to wx?Ok I found the problem and it has nothing to do with what I changed ;). The problem is the Makefile generated by extconf.rb for Windows. The problem is from create_makefile("wx") which makes the following in the Makefile: $(DEFFILE): $(RUBY) -e "puts ''EXPORTS'', ''Init_$(TARGET)''" > $@ where TARGET is wx specified in create_makefile("wx") If I change create_makefile to create_makefile("wxruby2") it compiles smoothly, but then the generated library is wxruby2.so not wx.so. Any ideas on how to fix this correctly? Sean
I figured out a simple fix, just wanted to get some feedback on it
before moving on to something else.
put the following:
#fix for Makefile on Windows
contents = File.read("Makefile")
contents =
contents.gsub(''Init_$(TARGET)'',''Init_wxruby2'')
File.open("Makefile","w+") do |f|
f.write contents
end
after previous code in
if $WXDIR != nil
end
which is in extconf.rb
Sean
On 8/1/05, Sean Long <sean.m.long@gmail.com>
wrote:> > > - Changed line 5 of wx.i from wxruby2 to wx, could not get
wxruby2 to
> > > work. I also
> > > changed line 13 in fixmodule.rb to mWx and line 11 in
> > > fixmainmodule.rb to mWx from mWxruby2.
> > > Also changed mWx in functions.i and XmlResource.i
>
> > Let''s figure this one out. I really want the module to be
wxruby2, not
> > wx, so I didn''t apply your changes. Perhaps you just needed
to do ''rake
> > clean_src'' to clear out all the old files that still referred
to wx?
>
> Ok I found the problem and it has nothing to do with what I changed
> ;). The problem is the Makefile generated by extconf.rb for Windows.
> The problem is from create_makefile("wx") which makes the
following in
> the Makefile:
>
> $(DEFFILE):
> $(RUBY) -e "puts ''EXPORTS'',
''Init_$(TARGET)''" > $@
>
> where TARGET is wx specified in create_makefile("wx")
>
> If I change create_makefile to create_makefile("wxruby2") it
compiles
> smoothly, but then the generated library is wxruby2.so not wx.so.
>
> Any ideas on how to fix this correctly?
>
> Sean
>
Sean Long wrote:> I figured out a simple fix, just wanted to get some feedback on it > before moving on to something else. > > put the following: > #fix for Makefile on Windows > contents = File.read("Makefile") > contents = contents.gsub(''Init_$(TARGET)'',''Init_wxruby2'') > File.open("Makefile","w+") do |f| > f.write contents > end > > after previous code in > if $WXDIR != nil > > end > > which is in extconf.rbI can live with that (can you send it as a patch?)...but what would it take to persuade you to stop using extconf.rb? Kevin
Disregard the last fix, it compiled but did not actually work. I think
I figured out a better solution.
create_makefile("wxruby2")
if $WXDIR != nil
File.open("Makefile","ab+") {|f|
f.print "
wx.res : wx.rc
\trc -I#$WXINC wx.rc
"
#used to install wx.rb wrapper
f.print "
wrapper_install:
\t@$(INSTALL_PROG) ../lib/wx.rb $(RUBYLIBDIR)
"
}
#fix for Makefile to install wx.rb wrapper
contents = File.read("Makefile")
contents = contents.gsub(''install:
$(RUBYARCHDIR)'',''install:
wrapper_install $(RUBYARCHDIR)'')
File.open("Makefile","w+") do |f|
f.write contents
end
end
works great on Windows and should be 100% cross platform.
Sean
(resending to group, where I ment to send the first time) Not much ;) Do you compile and install with rake? If that is the way to go I will need to move some of my changes to the Windows specific rake file. On 8/1/05, Sean Long <sean.m.long@gmail.com> wrote:> Not much ;) > > Do you compile and install with rake? If that is the way to go I will > need to move some of my changes to the Windows specific rake file. > > Sean > > On 8/1/05, Kevin Smith <wxruby@qualitycode.com> wrote: > > Sean Long wrote: > > > I figured out a simple fix, just wanted to get some feedback on it > > > before moving on to something else. > > > > > > put the following: > > > #fix for Makefile on Windows > > > contents = File.read("Makefile") > > > contents = contents.gsub(''Init_$(TARGET)'',''Init_wxruby2'') > > > File.open("Makefile","w+") do |f| > > > f.write contents > > > end > > > > > > after previous code in > > > if $WXDIR != nil > > > > > > end > > > > > > which is in extconf.rb > > > > I can live with that (can you send it as a patch?)...but what would it > > take to persuade you to stop using extconf.rb? > > > > Kevin > > >
Well I got wxruby2 compiling on Windows using rake instead of extconf.rb, so the previous few messages are no longer needed. I still need to update my local copy with changes in HEAD then I will make a patch. Sean On 8/1/05, Sean Long <sean.m.long@gmail.com> wrote:> (resending to group, where I ment to send the first time) > > Not much ;) > > Do you compile and install with rake? If that is the way to go I will > need to move some of my changes to the Windows specific rake file. > > On 8/1/05, Sean Long <sean.m.long@gmail.com> wrote: > > Not much ;) > > > > Do you compile and install with rake? If that is the way to go I will > > need to move some of my changes to the Windows specific rake file. > > > > Sean > > > > On 8/1/05, Kevin Smith <wxruby@qualitycode.com> wrote: > > > Sean Long wrote: > > > > I figured out a simple fix, just wanted to get some feedback on it > > > > before moving on to something else. > > > > > > > > put the following: > > > > #fix for Makefile on Windows > > > > contents = File.read("Makefile") > > > > contents = contents.gsub(''Init_$(TARGET)'',''Init_wxruby2'') > > > > File.open("Makefile","w+") do |f| > > > > f.write contents > > > > end > > > > > > > > after previous code in > > > > if $WXDIR != nil > > > > > > > > end > > > > > > > > which is in extconf.rb > > > > > > I can live with that (can you send it as a patch?)...but what would it > > > take to persuade you to stop using extconf.rb? > > > > > > Kevin > > > > > >
Sean Long wrote:> Well I got wxruby2 compiling on Windows using rake instead of > extconf.rb, so the previous few messages are no longer needed. I still > need to update my local copy with changes in HEAD then I will make a > patch.Sweet.>>Do you compile and install with rake? If that is the way to go I will >>need to move some of my changes to the Windows specific rake file.I don''t think our rakefile has an ''install'' target yet. It''s on my TODO list, but I wouldn''t reject a nice patch that adds it ;-) I don''t think I can delete extconf.rb until we have rake install working. I''m not sure how much would be different installing on the different platforms. Perhaps we should start by having all the code independently in each platform rakefile, and once it''s working on all platforms, try to merge out whatever common parts we can find. Kevin