Good news and bad news. First he good news. wxruby-swig now compiles on Linux, Mac, and Windows using wxWidgets 2.5. I just patched a bug with the paint method today, but it''s getting very close to the first release of wxruby. With a little more cleanup, I think we''re getting ready to do a first release of it, which will hopefully replaced wxruby. Of course, the debug spew needs to be removed, and Zach''s new documentation will be a great addition, so we should probably come up with a list of things that should be done to make it "releaseable". Now the bad news: SWIG has made progress, and I haven''t been folowing along. While initially you needed the most recent SWIG to build wxruby-swig, it appears now you need to use 1.3.22 or it just won''t work. I hope to leave this alone for now, and fix it after we get a release out. Thats all from here, Nick
Nick wrote:> > Good news and bad news. > > First he good news. wxruby-swig now compiles on Linux, Mac, and Windows > using wxWidgets 2.5. I just patched a bug with the paint method today, > but it''s getting very close to the first release of wxruby. With a > little more cleanup, I think we''re getting ready to do a first release > of it, which will hopefully replaced wxruby. Of course, the debug spew > needs to be removed, and Zach''s new documentation will be a great > addition, so we should probably come up with a list of things that > should be done to make it "releaseable". > > Now the bad news: SWIG has made progress, and I haven''t been folowing > along. While initially you needed the most recent SWIG to build > wxruby-swig, it appears now you need to use 1.3.22 or it just won''t > work. I hope to leave this alone for now, and fix it after we get a > release out. >Great news!! So is the swig-version going to be first released with 2.5 support? The documentation I''m working on parses the 2.4 xml file. Will the original parser create a xml file in the same format for 2.5 ? Thanks, Zach
That''s excellent, Nick! Thanks! I think a while back there was some talk of having methods like "set_label" be changed to a more Ruby-attribute-like "label=" syntax. Is this still being considered? I''m very much in favor of it, but I''m wondering how the switch will be handled. Would both sets of methods be kept, or would the get_xxx and set_xxx methods be dropped? In the case of the latter, I''m wondering if it would be good to consider this a basic part of the switchover to wxruby-swig. Thanks again for your work and Zach''s work on this. This is great stuff! Marshall On Feb 3, 2005, at 9:18 PM, Nick wrote:> > Good news and bad news. > > First he good news. wxruby-swig now compiles on Linux, Mac, and > Windows using wxWidgets 2.5. I just patched a bug with the paint > method today, but it''s getting very close to the first release of > wxruby. With a little more cleanup, I think we''re getting ready to do > a first release of it, which will hopefully replaced wxruby. Of > course, the debug spew needs to be removed, and Zach''s new > documentation will be a great addition, so we should probably come up > with a list of things that should be done to make it "releaseable". > > Now the bad news: SWIG has made progress, and I haven''t been folowing > along. While initially you needed the most recent SWIG to build > wxruby-swig, it appears now you need to use 1.3.22 or it just won''t > work. I hope to leave this alone for now, and fix it after we get a > release out. > > Thats all from here, > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
> First he good news. wxruby-swig now compiles on Linux, Mac, and Windows > using wxWidgets 2.5. I just patched a bug with the paint method today,I compiled for 2.5 on linux and there''s a problem. wxEntry''s prototype has changed since 2.4 the first arg is int& instead of int, so trying to run an app complains because of the unknown symbol. ruby: relocation error: /usr/lib/ruby/1.8/wx.so: undefined symbol: _Z7wxEntryiPPc the latter should end in RiPPC (Reference to int instead of int) I changed it in src/App.c (quick hack, no clean #ifdefing on wxgtk version) and now apps start, but no fonts are displayed. I''ll try to invesatigate why later. (wxruby:21972): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() Jani
jani wrote:> > First he good news. wxruby-swig now compiles on Linux, Mac, and Windows > >> using wxWidgets 2.5. I just patched a bug with the paint method today, > > > I compiled for 2.5 on linux and there''s a problem. wxEntry''s prototype > has changed since 2.4 the first arg is int& instead of int, so trying to > run an app complains because of the unknown symbol. > ruby: relocation error: /usr/lib/ruby/1.8/wx.so: undefined symbol: > _Z7wxEntryiPPc > > the latter should end in RiPPC (Reference to int instead of int) > I changed it in src/App.c (quick hack, no clean #ifdefing on wxgtk > version) and now apps start, but no fonts are displayed. I''ll try to > invesatigate why later. > > (wxruby:21972): Pango-WARNING **: Invalid UTF-8 string passed to > pango_layout_set_text()I do remember Nick saying not to compile wxWindows with Unicode enabled, to use ASCII, on an off-list discussion we had. I hope I remember this correctly, if it doesn''t sound right, ignore me, until Nick has a chance to respond. Thanks, Zach
> the latter should end in RiPPC (Reference to int instead of int)> I changed it in src/App.c (quick hack, no clean #ifdefing on wxgtk > version) and now apps start, but no fonts are displayed. I''ll try to > invesatigate why later. I actually spent a good part of the weekend trying to track down two missing references. I got the first one (what you refer to) fixed, but on my OS X 10.3 machine I get an exception on load because I have a reference to WebKit that doesn''t exist. Did you see anything similar? Nick jani wrote:> > First he good news. wxruby-swig now compiles on Linux, Mac, and Windows > >> using wxWidgets 2.5. I just patched a bug with the paint method today, > > > I compiled for 2.5 on linux and there''s a problem. wxEntry''s prototype > has changed since 2.4 the first arg is int& instead of int, so trying to > run an app complains because of the unknown symbol. > ruby: relocation error: /usr/lib/ruby/1.8/wx.so: undefined symbol: > _Z7wxEntryiPPc > > the latter should end in RiPPC (Reference to int instead of int) > I changed it in src/App.c (quick hack, no clean #ifdefing on wxgtk > version) and now apps start, but no fonts are displayed. I''ll try to > invesatigate why later. > > (wxruby:21972): Pango-WARNING **: Invalid UTF-8 string passed to > pango_layout_set_text() > > > Jani > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
> I actually spent a good part of the weekend trying to track down two > missing references. I got the first one (what you refer to) fixed, but > on my OS X 10.3 machine I get an exception on load because I have a > reference to WebKit that doesn''t exist. Did you see anything similar?No. I am using ubuntu with wxgtk2.5 compiled with unicode support and gtk2 The only thing after the programs could run was the pango warning I pasted and no text whatsoever in the controls :) What are the impediments of using an unicode enabled wx? Need to transform all wxChar uses to char? thanks Jani
> No. I am using ubuntu with wxgtk2.5 compiled with unicode support and gtk2 > The only thing after the programs could run was the pango warning Ipasted > and no text whatsoever in the controls :)> What are the impediments of using an unicode enabled wx? Need totransform > all wxChar uses> to char?Ruby appears to use const char * for all of it''s string work (which completely caught me off guard, because it is a Japanese scripting language). It may be that I''m just not using a UNICODE build of Ruby, but I don''t think most of the binary releases are. Right now I''m just casting the output strings to wxChar * (I know - bad! bad!), but I''d ask not to use wxWidgets in UNICODE for building wxRuby until this is resolved. Nick
devel@nicreations.com wrote:> Ruby appears to use const char * for all of it''s string work (which > completely caught me off guard, because it is a Japanese scripting > language).When I looked into unicode support with wxRuby a couple years ago, I had a similar reaction. I also chose to postpone dealing with it. Hopefully a straightforward solution will present itself at some point. Kevin