From alex at pressure.to Sat Nov 1 13:27:54 2008 From: alex at pressure.to (Alex Fenton) Date: Sat, 01 Nov 2008 17:27:54 +0000 Subject: [wxruby-development] wxRuby 1.9.9 release Message-ID: <490C919A.8050204@pressure.to> Hello I'm happy to announce that wxRuby version 1.9.9 is now available for download and gem installation: http://rubyforge.org/frs/?group_id=35&release_id=27842 gem install wxruby On Linux, the default binary gem is now dynamically linked to wxWidgets. This means you'll need to install wxWidgets from your package manager. See below for more info. == CHANGES == This recommended upgrade includes a substantial number of new GUI features, as well as fixing a number of bugs: * Added the RichText framework, providing word-processor like editing of styled/formatted text and inline images * Added a number of other useful GUI classes, such as VScrolledWindow, VListBox and HtmlListBox * Added the StandardPaths and NavigationKeyEvent classes * Fixed a number of bugs and warnings * Binary builds for Windows and OS X are based on the latest stable wxWidgets, 2.8.9, so benefitting from upstream fixes It had been planned that 1.9.8 was the last release before 2.0. 1.9.9 is a chance to give some new classes some testing time and get some fixes out there whilst finishing up the last few 2.0 blocker bugs (eg Clipboard probs on GTK, ScrolledWindow X errors). == LINUX BINARY GEMS == Previous binary builds for Linux were, like those for Windows and OS X, statically linked - meaning the wxRuby library included all the relevant wxWidgets code. With this release I've switched to offering a Linux gem that is dynamically linked - meaning it makes use of the wxWidgets library on your system - which should be easily installable from your package manager - eg apt-get install wxwidgets The reasoning here: * Because Linux systems vary a lot in what's installed by default, using the static build generally still required messing around installing new packages * Package managers make it trivially easy to install a recent version of wxWidgets on major distros * The shared builds are substantially smaller and may perform better I'm open to discussion on this based on experiences on different distros (I've only tested on Ubuntu). == ACKNOWLEDGEMENTS == Thanks to all those who contributed bug reports and feature requests to this release, as well as those who keep the project ticking over in other ways such as keeping the wiki up to date and taking part on the mailing list. cheers alex From noreply at rubyforge.org Wed Nov 5 07:01:48 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 5 Nov 2008 07:01:48 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22686 ] TextCtrl#set_selection doesn't work Message-ID: <20081105120148.D85A618585A7@rubyforge.org> Bugs item #22686, was opened at 2008-11-05 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22686&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kirill Likhodedov (edelweard) Assigned to: Nobody (None) Summary: TextCtrl#set_selection doesn't work Initial Comment: Wx::TextCtrl#set_selection doesn't do anything. Please see the example file attached. Ruby 1.8.6 WxRuby 1.9.9 Windows XP SP-2 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22686&group_id=35 From noreply at rubyforge.org Wed Nov 5 07:26:04 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 5 Nov 2008 07:26:04 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22687 ] Not doc page for TextAttrEx Message-ID: <20081105122616.87CE418585A2@rubyforge.org> Bugs item #22687, was opened at 2008-11-05 15:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22687&group_id=35 Category: Incorrect or missing docs Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kirill Likhodedov (edelweard) Assigned to: Alex Fenton (brokentoy) Summary: Not doc page for TextAttrEx Initial Comment: Links to TextAttrEx lead to http://wxruby.rubyforge.org/doc/textattrex.html which doesn't exist. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22687&group_id=35 From noreply at rubyforge.org Wed Nov 5 07:31:17 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 5 Nov 2008 07:31:17 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22688 ] RichTextAttr#apply has incorrect doc Message-ID: <20081105123118.0C09818581AD@rubyforge.org> Bugs item #22688, was opened at 2008-11-05 15:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22688&group_id=35 Category: Incorrect or missing docs Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kirill Likhodedov (edelweard) Assigned to: Alex Fenton (brokentoy) Summary: RichTextAttr#apply has incorrect doc Initial Comment: The doc for RickTextAttr#apply mistakenly has the signature for #combine. See: http://wxruby.rubyforge.org/doc/richtextattr.html#RichTextAttr_apply ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22688&group_id=35 From noreply at rubyforge.org Fri Nov 7 06:55:28 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Nov 2008 06:55:28 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22706 ] BitmapComboBox doesn't work on Linux GTK+ Message-ID: <20081107115528.E788818585C1@rubyforge.org> Bugs item #22706, was opened at 2008-11-07 06:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22706&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: BitmapComboBox doesn't work on Linux GTK+ Initial Comment: This is the source code. ------------------------------------- require 'wx' class MyApp < Wx::App def on_init MyFrame.new.show end end class MyFrame < Wx::Frame def initialize super(nil, -1, 'BitmapComboBox Sample') b = Wx::BitmapComboBox.new(self, -1, 'item 1', :choices => ['item 1', 'item 2']) end end MyApp.new.main_loop ------------------------------------- It worked correctly on Windows but froze on Linux. I use wxRuby 1.9.9, wxGTK 2.8.7, GTK+ 2.12.11, Ruby 1.8.6 and Gentoo Linux. I clicked BitmapComboBox on Linux and then it was frozen but sometimes these error messages was shown. app.rb:16:in `get_count': stack level too deep (SystemStackError) from app.rb:16:in `process_event' from app.rb:16:in `get_count' from app.rb:16:in `process_event' from app.rb:16:in `main_loop' from app.rb:16 OR app.rb:16:in `get_count': stack level too deep (SystemStackError) from app.rb:16:in `main_loop' from app.rb:16 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22706&group_id=35 From noreply at rubyforge.org Fri Nov 7 07:17:51 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Nov 2008 07:17:51 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22707 ] The mdi sample doesn't work on Linux/GTK and Windows 2000 Message-ID: <20081107121752.0B5851858183@rubyforge.org> Bugs item #22707, was opened at 2008-11-07 07:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22707&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: The mdi sample doesn't work on Linux/GTK and Windows 2000 Initial Comment: I ran the mdi sample included in the wxRuby 1.9.9. This is error messages. mdi.rb:73:in `show': stack level too deep (SystemStackError) from mdi.rb:73:in `on_init' from mdi.rb:77:in `main_loop' from mdi.rb:77 And this code also doesn't work. ----------------------------------- require 'wx' class MyApp < Wx::App def on_init MyFrame.new.show end end class MyFrame < Wx::MDIParentFrame def initialize super(nil, -1, 'MDI') end end MyApp.new.main_loop ----------------------------------- app.rb:5:in `show': stack level too deep (SystemStackError) from app.rb:5:in `on_init' from app.rb:15:in `main_loop' from app.rb:15 I use wxRuby 1.9.9, wxWidgets 2.8.7, GTK+ 2.12.11, Ruby 1.8.6, SWIG 1.3.34 and Gentoo Linux. I didn't install through the Rubygems. I compiled wxRuby myself. I ran same codes on Windows 2000 and same errors were occured. I installed wxRuby 1.9.9 through the Rubygems on Windows. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22707&group_id=35 From noreply at rubyforge.org Fri Nov 7 12:11:33 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Nov 2008 12:11:33 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22714 ] Ensure all loaded files are included in ruby-1.9 gem Message-ID: <20081107171134.0B40718585B6@rubyforge.org> Bugs item #22714, was opened at 2008-11-07 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22714&group_id=35 Category: Installer problems Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Ensure all loaded files are included in ruby-1.9 gem Initial Comment: Seems that because of the renaming with the suffix ruby19, gems does not find installed gems on ruby 1.9. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22714&group_id=35 From mnmfactory at gmail.com Sun Nov 9 14:33:39 2008 From: mnmfactory at gmail.com (Mark E.) Date: Sun, 9 Nov 2008 13:33:39 -0600 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? Message-ID: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> This may be a misguided message, but I was wondering if any thought has been given to making wxRuby work using the new native FFI (Foreign Function Interface) interface in the place of SWIG? Something like the FFI thing would be much easier for a non-C programmer like me to assist with. If you aren't familiar with it (quite new) here are some links. http://kenai.com/projects/ruby-ffi/pages/Home http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html http://wmeissner.blogspot.com/2008/11/more-on-ruby-ffi.html http://pluskid.lifegoo.com/?p=370 Now, I realize that FFI is really, really new and probably not yet ready to handle something as complex as the needs of wxRuby. However, I wanted to inquire as to the principle of it. I have worked on other scripting engines before (windows platform in other languages). I have experience with generating code to help map complex structures in a native language to a simplified one in a scripted language. I'm just curious as to what you guys think. Ideally, I would love to see a shared library that wxRuby and wxPython could both use to simplify complex structures that needed to be passed to the scripts. Then each project would use something like FFI to import those functions into Ruby or Python. Then the work could be shared. :) Anyway, I'm interested in your thoughts, ideas and problem points. -MarkE -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at ruby-im.net Sun Nov 9 15:29:58 2008 From: mario at ruby-im.net (Mario Steele) Date: Sun, 9 Nov 2008 14:29:58 -0600 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? In-Reply-To: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> References: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> Message-ID: There are many good points to using something like FFI. The major problem though, that I see from it at this point, is that it would require a full re-write of the wxRuby library. Something we're not planning to do right now with the 2.0 release. We're focusing on a 2.0 full release here very soon, that we can label stable, and freeze feature sets, and such. So that we can finally have a stable product out there for people to use in a comerical setting. We've already been looking at possibly switching from SWIG to something else, can't remember the name of the project off the top of my Head, but Alex would remember. Sometimes, new can be good, and bad at the same time, so we'll just have to test the waters, and see what we can figure out. The major problem that I can see with this, is that wxWidgets has their own data types for just about everything, from Integers, to Strings, to Complex data formats. While I see struct being available with FFI (Thank god, that makes wrapping stuff a lot easier), it still may be a problem when trying to convert a Ruby String, over to a wxString. But it will definately something to look at, when we get 2.0 out the door. On Sun, Nov 9, 2008 at 1:33 PM, Mark E. wrote: > This may be a misguided message, but I was wondering if any thought has > been given to making wxRuby work using the new native FFI (Foreign Function > Interface) interface in the place of SWIG? > > Something like the FFI thing would be much easier for a non-C programmer > like me to assist with. > > If you aren't familiar with it (quite new) here are some links. > http://kenai.com/projects/ruby-ffi/pages/Home > http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html > http://wmeissner.blogspot.com/2008/11/more-on-ruby-ffi.html > http://pluskid.lifegoo.com/?p=370 > > Now, I realize that FFI is really, really new and probably not yet ready to > handle something as complex as the needs of wxRuby. However, I wanted to > inquire as to the principle of it. > > I have worked on other scripting engines before (windows platform in other > languages). I have experience with generating code to help map complex > structures in a native language to a simplified one in a scripted language. > I'm just curious as to what you guys think. > > Ideally, I would love to see a shared library that wxRuby and wxPython > could both use to simplify complex structures that needed to be passed to > the scripts. Then each project would use something like FFI to import those > functions into Ruby or Python. Then the work could be shared. :) > > Anyway, I'm interested in your thoughts, ideas and problem points. > > -MarkE > > _______________________________________________ > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnmfactory at gmail.com Sun Nov 9 18:09:08 2008 From: mnmfactory at gmail.com (Mark E.) Date: Sun, 9 Nov 2008 17:09:08 -0600 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? In-Reply-To: References: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> Message-ID: <56c3290f0811091509v7fbe7b59mf715001d9aa0af65@mail.gmail.com> Mario, Thanks for the response. I fully agree that getting 2.0 stable is more important. I'm glad to hear that there are other considerations for wrapping libraries. I would love to be able to contribute at that level but I really don't like C. (Yes, I know, that's my problem.) So anything like FFI that can abstract it out more is a great help to me in my ability to contribute. :) Oh, Mario, I noticed you had a link in your sig to "http://www.trilake.net". I saw that it is in Council Bluffs, IA. Too funny! I grew up in Omaha, NE and my wife and I have moved to Birmingham, AL only in the last 3 years or so. Hope the weather is nice there. My family is still in Omaha and I'll be visiting them for Christmas. It was just nice to notice a Ruby developer in the true midwest. :) -Mark E. On Sun, Nov 9, 2008 at 2:29 PM, Mario Steele wrote: > There are many good points to using something like FFI. The major problem > though, that I see from it at this point, is that it would require a full > re-write of the wxRuby library. Something we're not planning to do right > now with the 2.0 release. We're focusing on a 2.0 full release here very > soon, that we can label stable, and freeze feature sets, and such. So that > we can finally have a stable product out there for people to use in a > comerical setting. > > We've already been looking at possibly switching from SWIG to something > else, can't remember the name of the project off the top of my Head, but > Alex would remember. Sometimes, new can be good, and bad at the same time, > so we'll just have to test the waters, and see what we can figure out. > > The major problem that I can see with this, is that wxWidgets has their own > data types for just about everything, from Integers, to Strings, to Complex > data formats. While I see struct being available with FFI (Thank god, that > makes wrapping stuff a lot easier), it still may be a problem when trying to > convert a Ruby String, over to a wxString. > > But it will definately something to look at, when we get 2.0 out the door. > > On Sun, Nov 9, 2008 at 1:33 PM, Mark E. wrote: > >> This may be a misguided message, but I was wondering if any thought has >> been given to making wxRuby work using the new native FFI (Foreign Function >> Interface) interface in the place of SWIG? >> >> Something like the FFI thing would be much easier for a non-C programmer >> like me to assist with. >> >> If you aren't familiar with it (quite new) here are some links. >> http://kenai.com/projects/ruby-ffi/pages/Home >> http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html >> http://wmeissner.blogspot.com/2008/11/more-on-ruby-ffi.html >> http://pluskid.lifegoo.com/?p=370 >> >> Now, I realize that FFI is really, really new and probably not yet ready >> to handle something as complex as the needs of wxRuby. However, I wanted to >> inquire as to the principle of it. >> >> I have worked on other scripting engines before (windows platform in other >> languages). I have experience with generating code to help map complex >> structures in a native language to a simplified one in a scripted language. >> I'm just curious as to what you guys think. >> >> Ideally, I would love to see a shared library that wxRuby and wxPython >> could both use to simplify complex structures that needed to be passed to >> the scripts. Then each project would use something like FFI to import those >> functions into Ruby or Python. Then the work could be shared. :) >> >> Anyway, I'm interested in your thoughts, ideas and problem points. >> >> -MarkE >> >> _______________________________________________ >> 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/ > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at ruby-im.net Sun Nov 9 18:59:01 2008 From: mario at ruby-im.net (Mario Steele) Date: Sun, 9 Nov 2008 17:59:01 -0600 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? In-Reply-To: <56c3290f0811091509v7fbe7b59mf715001d9aa0af65@mail.gmail.com> References: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> <56c3290f0811091509v7fbe7b59mf715001d9aa0af65@mail.gmail.com> Message-ID: On Sun, Nov 9, 2008 at 5:09 PM, Mark E. wrote: > Mario, > > Thanks for the response. I fully agree that getting 2.0 stable is more > important. I'm glad to hear that there are other considerations for wrapping > libraries. I would love to be able to contribute at that level but I really > don't like C. (Yes, I know, that's my problem.) Well, the problem with any library that's done in C/C++, is that you need to have some kind of working knowledge of C/C++ to interface with it. So in that area, it would be kinda hard. > So anything like FFI that can abstract it out more is a great help to me in > my ability to contribute. :) There are always other ways to contribute to the wxRuby development, aside from doing the pure C/C++ Bindings. We do have a layer of Ruby code, that is layed over the C/C++ Extension, to make it more Ruby like, such as the common attribute accessors, such as title, background_colour, text, value, etc, etc, etc. So, if your interested in helping out, and want to make the stuff more Ruby-esque, then by all means, experiment with the code, and check out the Current implementations, and see how it would be better to create more Ruby-esque API. But keep in mind, that you would also need to document them to. ;-) > Oh, Mario, I noticed you had a link in your sig to "http://www.trilake.net". > I saw that it is in Council Bluffs, IA. Too funny! I grew up in Omaha, NE > and my wife and I have moved to Birmingham, AL only in the last 3 years or > so. > > Hope the weather is nice there. My family is still in Omaha and I'll be > visiting them for Christmas. It was just nice to notice a Ruby developer in > the true midwest. :) Yep, I grew up in Omaha, NE myself, and live in CB with my Fiancee. It's starting to get a bitter on the cold side of things. And you'd be surprised how many True MidWest Ruby coders there are up here. We have the Omaha Dynamic language User Group (ODYNUG) up here, though there are ones from different backgrounds, such as perl, python, Erlang, Java, there's a few of us Ruby enthusiats here in the mid-west. -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at pressure.to Sun Nov 9 18:46:42 2008 From: alex at pressure.to (Alex Fenton) Date: Sun, 09 Nov 2008 23:46:42 +0000 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? In-Reply-To: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> References: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> Message-ID: <49177662.5080401@pressure.to> Hi Mark Mark E. wrote: > This may be a misguided message, but I was wondering if any thought > has been given to making wxRuby work using the new native FFI (Foreign > Function Interface) interface in the place of SWIG? > > Something like the FFI thing would be much easier for a non-C > programmer like me to assist with. Thanks for bringing this up. I followed the discussion about FFI on the ruby mailing list with interest, mainly for this reason. Our current SWIG & C++ base is a really high barrier to contributions. It's taken me two or three years to go from being an experienced Ruby programmer to having a good grasp of all the stuff that's going on. And there are still subtleties and bugs that surprise me. > Now, I realize that FFI is really, really new and probably not yet > ready to handle something as complex as the needs of wxRuby. However, > I wanted to inquire as to the principle of it. It's a good time to be discussing this. As Mario says, we wouldn't be looking to change the basis of wxRuby 2.0 - it's, at last, pretty much finished. But I hope there will be a wxRuby 3.0 - probably matched to wxWidgets 3.0 - and I want to look at whether SWIG still is the best choice for wrapping. At the moment I think the biggest shortcoming for FFI for this is that it's aimed at C libraries, whereas wxWidgets is very much a C++ toolset. >From what I can see, FFI is mainly designed to put simple C types like int, char[], long and so on in and out of functions. Whereas what wxRuby does is closely tie Ruby object instances to C++ typed pointers - instances of classes. This ends up implying quite a lot of other tricky things that SWIG, plus our hacking on top of it, deals with. This is stuff like object tracking and object ownership - avoiding destroying either Ruby or C++ objects before time, but not leaking memory - and have the C++ core being able to be overridden by methods in Ruby. What to me is an attractive possibility is if a much smaller core of wxRuby could be defined / run in custom C++ / SWIG / whatever code, and much more could be edited in Ruby, as with FFI. The sort of thing I'm thinking of is how the modern event mapping code (in lib/wx/classes/evthandler.rb) works. FFI might give us some ideas, or even be part of the mix. By the way, the other new tool that Mario was thinking of is rbplusplus / rbgccxml / rice. Rbgccxml uses gcc to parse the C++ headers to get the relevant class and method definitions. Rice provides a set of functions for safer conversions between C++ objects and ruby objects. And rbplusplus brings this all together to automatically generate glue code and compile it. This approach is similar to SWIG, which brings all those together, apart from the compiling bit. > I have worked on other scripting engines before (windows platform in > other languages). I have experience with generating code to help map > complex structures in a native language to a simplified one in a > scripted language. I'm just curious as to what you guys think. > > Ideally, I would love to see a shared library that wxRuby and wxPython > could both use to simplify complex structures that needed to be passed > to the scripts. Then each project would use something like FFI to > import those functions into Ruby or Python. Then the work could be > shared. :) The work that the wxWidgets team has been doing on 3.0 is partly aimed at this - they have created a "clean" set of C++ headers that define the public APIs as they should be used - and as they should be ported to Ruby/Python/Lua etc. The real headers are full of macros and base/implementation class complexities, but with the new clean headers it should be possible just to point a tool like SWIG or rbgccxml at them to generate code. cheers alex From mnmfactory at gmail.com Sun Nov 9 21:17:03 2008 From: mnmfactory at gmail.com (Mark E.) Date: Sun, 9 Nov 2008 20:17:03 -0600 Subject: [wxruby-development] Any investigation on using FFI instead of SWIG? In-Reply-To: <49177662.5080401@pressure.to> References: <56c3290f0811091133r7d87de7ftc0574f1215ddd6e1@mail.gmail.com> <49177662.5080401@pressure.to> Message-ID: <56c3290f0811091817q51e55d7ob9cf174b404f034f@mail.gmail.com> Alex, Thanks for the response. I'm very glad to learn about the wxWidgets header file interface changes for 3.0. That just makes more sense. On Sun, Nov 9, 2008 at 5:46 PM, Alex Fenton wrote: > [...] > By the way, the other new tool that Mario was thinking of is rbplusplus / > rbgccxml / rice. Rbgccxml uses gcc to parse the C++ headers to get the > relevant class and method definitions. Rice provides a set of functions for > safer conversions between C++ objects and ruby objects. And rbplusplus > brings this all together to automatically generate glue code and compile it. > This approach is similar to SWIG, which brings all those together, apart > from the compiling bit. > Very interesting. Thanks for sharing that. Thanks again for taking the time to explain this. I appreciate it. -MarkE -------------- next part -------------- An HTML attachment was scrubbed... URL: From chauk.mean at gmail.com Mon Nov 10 05:56:48 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 10 Nov 2008 11:56:48 +0100 Subject: [wxruby-development] Documentation about ToolBar#add_item and Sizer#add_item Message-ID: Hi Alex, It's better late than never ... I've prepared the textile documentation for these 2 methods and this will be posted tonight. This documentation corresponds to the current implementation. I'm just wondering two things : - Unlike my proposal (http://rubyforge.org/pipermail/wxruby-development/2008-March/001249.html), a spacer is not currently supported by Sizer#add_item. Is this intentional ? In my proposal, if the first parameter is an array with 2 elements then it is detected as a spacer and Sizer#add and Sizer#insert can be used accordingly by extracting the width and height from the array. - ToolBar#add_item I understand that you kept the position of the bitmap parameter for consistency with ToolBar#add_tool and Toolbar#insert_tool methods. But for me, keyword arguments are optional arguments that may be specified in any order. This is the case for all existing methods (e.g. all window constructor) that support keyword arguments except ToolBar#add_item. In ToolBar#add_item, the bitmap parameter is a keyword parameter but is not optional ... This is a bit strange and inconsistent with above. I documented this subtle detail but I think it's not a good thing. Cheers. Chauk-Mean. From chauk.mean at gmail.com Mon Nov 10 07:23:20 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 10 Nov 2008 13:23:20 +0100 Subject: [wxruby-development] About Textile documentation for wxRuby Message-ID: Hi again, Currently, the Textile documentation is not included in the source tarball. I also noticed that the html_docs rake task requires that wxWidgets be installed. In order to make documentation activity a bit easier : - what about adding the Textile documentation into the source tarball ? (this will avoid using subversion just for the documentation). - can the requirements on wxWidgets be removed for the html_docs rake task ? Cheers. Chauk-Mean. From alex at pressure.to Mon Nov 10 08:58:03 2008 From: alex at pressure.to (Alex Fenton) Date: Mon, 10 Nov 2008 13:58:03 +0000 Subject: [wxruby-development] About Textile documentation for wxRuby In-Reply-To: References: Message-ID: <49183DEB.30207@pressure.to> Hi Chauk Mean thanks for your other documentation contributions. Chauk-Mean P wrote: > Currently, the Textile documentation is not included in the source tarball. > I also noticed that the html_docs rake task requires that wxWidgets be > installed. > > In order to make documentation activity a bit easier : > I'm happy to look at anything that would help here... > - what about adding the Textile documentation into the source tarball > ? (this will avoid using subversion just for the documentation). > I tested this out and it looks like adding the Textile sources to the source tarball would increase its size by about 600kb. I'm not sure this is justifiable on its own as the base tarball is only 1MB. But like wxWidgets, I guess we could offer a wxruby-src-full tarball with more stuff in it like textile sources and possibly generated docs. > - can the requirements on wxWidgets be removed for the html_docs rake task ? > Yes, only the textile_docs task depends on the wxWidgets sources being installed. And we never normally need to run this task, except to generate docs when new classes are added. cheers alex From chauk.mean at gmail.com Mon Nov 10 10:23:54 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 10 Nov 2008 16:23:54 +0100 Subject: [wxruby-development] About Textile documentation for wxRuby In-Reply-To: <49183DEB.30207@pressure.to> References: <49183DEB.30207@pressure.to> Message-ID: Alex, 2008/11/10 Alex Fenton : > Chauk-Mean P wrote: >> - what about adding the Textile documentation into the source tarball >> ? (this will avoid using subversion just for the documentation). > > I tested this out and it looks like adding the Textile sources to the source > tarball would increase its size by about 600kb. I'm not sure this is > justifiable on its own as the base tarball is only 1MB. But like wxWidgets, > I guess we could offer a wxruby-src-full tarball with more stuff in it like > textile sources That's fine. > and possibly generated docs. I don't think that it is useful. Unlike the textile documentation, the generated docs already has its own tarball. >> - can the requirements on wxWidgets be removed for the html_docs rake task ? > > Yes, only the textile_docs task depends on the wxWidgets sources being > installed. And we never normally need to run this task, except to generate > docs when new classes are added. That's great. Cheers. Chauk-Mean. From chauk.mean at gmail.com Mon Nov 10 10:28:41 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 10 Nov 2008 16:28:41 +0100 Subject: [wxruby-development] Documentation about ToolBar#add_item and Sizer#add_item In-Reply-To: References: Message-ID: Alex, Will you accept code patches for the 2 things I mentioned in my previous post : - support of spacer in Sizer#add_item ? - make bitmap the first and mandatory parameter in ToolBar#add_item ? Cheers. Chauk-Mean. From chauk.mean at gmail.com Mon Nov 10 18:17:23 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 11 Nov 2008 00:17:23 +0100 Subject: [wxruby-development] Documentation about ToolBar#add_item and Sizer#add_item In-Reply-To: References: Message-ID: Hi, 2008/11/10 Chauk-Mean P : > > It's better late than never ... > I've prepared the textile documentation for these 2 methods and this > will be posted tonight. > This documentation corresponds to the current implementation. > So here is the documentation patch (only for the current implementation). Cheers. Chauk-Mean. -------------- next part -------------- A non-text attachment was scrubbed... Name: toolbar_sizer_doc.patch Type: text/x-patch Size: 6684 bytes Desc: not available URL: From chauk.mean at gmail.com Tue Nov 11 03:27:42 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 11 Nov 2008 09:27:42 +0100 Subject: [wxruby-development] Code and doc patch for ToolBar#add_item and Sizer#add_item Message-ID: Hi all, I'd really like to see this code and doc patch committed instead of only the doc patch I submitted previously (http://rubyforge.org/pipermail/wxruby-development/2008-November/001431.html). Following my initial post (http://rubyforge.org/pipermail/wxruby-development/2008-November/001426.html), this new patch features : - support of spacer in Sizer#add_item - make bitmap the first and mandatory parameter in ToolBar#add_item - corresponding documentation update Cheers. Chauk-Mean. -------------- next part -------------- A non-text attachment was scrubbed... Name: toolbar_sizer_code_and_doc.patch Type: text/x-patch Size: 8913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: toolbar_sizer_sample.rb Type: application/x-ruby Size: 1717 bytes Desc: not available URL: From alex at pressure.to Tue Nov 11 04:39:19 2008 From: alex at pressure.to (Alex Fenton) Date: Tue, 11 Nov 2008 09:39:19 +0000 Subject: [wxruby-development] Code and doc patch for ToolBar#add_item and Sizer#add_item In-Reply-To: References: Message-ID: <491952C7.1040805@pressure.to> Chauk-Mean P wrote: > I'd really like to see this code and doc patch committed instead of > only the doc patch I submitted previously > (http://rubyforge.org/pipermail/wxruby-development/2008-November/001431.html). > > Following my initial post > (http://rubyforge.org/pipermail/wxruby-development/2008-November/001426.html), > this new patch features : > - support of spacer in Sizer#add_item > - make bitmap the first and mandatory parameter in ToolBar#add_item > - corresponding documentation update Committed; thank you very much for these patches. I put the sample in samples/etc. As a remark, ArtProvider has a get_bitmap class method so you don't need to fetch an icon and manually convert. I tweaked the sample to reflect this. cheers alex From chauk.mean at gmail.com Tue Nov 11 05:06:57 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 11 Nov 2008 11:06:57 +0100 Subject: [wxruby-development] Code and doc patch for ToolBar#add_item and Sizer#add_item In-Reply-To: <491952C7.1040805@pressure.to> References: <491952C7.1040805@pressure.to> Message-ID: Hi Alex, 2008/11/11 Alex Fenton : > Chauk-Mean P wrote: >> >> I'd really like to see this code and doc patch committed instead of >> only the doc patch I submitted previously >> this new patch features : >> - support of spacer in Sizer#add_item >> - make bitmap the first and mandatory parameter in ToolBar#add_item >> - corresponding documentation update > > Committed; thank you very much for these patches. That's cool. Thanks. Cheers. Chauk-Mean. From chauk.mean at gmail.com Tue Nov 11 05:24:30 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 11 Nov 2008 11:24:30 +0100 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 Message-ID: Hi all, I wanted to have a look at wxRuby on a recent version of ruby 1.9 (ruby-1.9.1-preview1) on Ubuntu 8.10 x86. Here is the result : chauk-mean at MyUbuntu:~/wxruby2$ ruby19 -v ruby 1.9.1 (2008-10-28 revision 19983) [i686-linux] chauk-mean at MyUbuntu:~/wxruby2$ rake19 WXRUBY_VERSION=1.9.9 gem (in /home/chauk-mean/wxruby2) Enabling DYNAMIC build Enabling RELEASE build Enabling UNICODE build The following wxWidgets features are not available and will be skipped: PrinterDC src/AboutDialogInfo.cpp:1776:20: error: rubyio.h: No such file or directory src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetName(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1856: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetName(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1882: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:1886: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:1886: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1905: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1931: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1955: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:1959: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:1959: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1978: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2004: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2028: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2032: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2032: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2051: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2077: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2101: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2105: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2105: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2124: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetLicense(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2149: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2175: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2199: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2203: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2203: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2224: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2229: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2232: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2255: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2279: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetWebSite(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2304: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasWebSite(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2335: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetWebSiteURL(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2359: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2363: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2363: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetWebSiteDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2383: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2387: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2387: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2407: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2417: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddDeveloper(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2447: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2473: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2497: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2530: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2540: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddDocWriter(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2570: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2596: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2620: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2653: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2663: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddArtist(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2693: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2719: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2743: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2776: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2786: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddTranslator(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2816: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2842: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2866: warning: format not a string literal and no format arguments rake aborted! Command failed with status (1): [g++ -c -I/opt/lib/wx/include/gtk2-unicod...] (See full trace by running task with --trace) chauk-mean at MyUbuntu:~/wxruby2$ I have buillt successfully wxRuby with ruby-1.8.7p72 and ruby-1.9.0-4. So this seems to be a problem with this more recent version of ruby 1.9. I found that rubyio.h is located in a 'backward' folder inside the ruby 1.9 include. Cheers. Chauk-Mean. From noreply at rubyforge.org Tue Nov 11 05:28:29 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Nov 2008 05:28:29 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22745 ] Can't build with ruby 1.9.1 Message-ID: <20081111102830.14B9A185859C@rubyforge.org> Bugs item #22745, was opened at 2008-11-11 10:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22745&group_id=35 Category: Compile/build Group: None Status: Open Resolution: None Priority: 4 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Can't build with ruby 1.9.1 Initial Comment: >From http://rubyforge.org/pipermail/wxruby-development/2008-November/001434.html I wanted to have a look at wxRuby on a recent version of ruby 1.9 (ruby-1.9.1-preview1) on Ubuntu 8.10 x86. Here is the result : chauk-mean at MyUbuntu:~/wxruby2$ ruby19 -v ruby 1.9.1 (2008-10-28 revision 19983) [i686-linux] chauk-mean at MyUbuntu:~/wxruby2$ rake19 WXRUBY_VERSION=1.9.9 gem (in /home/chauk-mean/wxruby2) Enabling DYNAMIC build Enabling RELEASE build Enabling UNICODE build The following wxWidgets features are not available and will be skipped: PrinterDC src/AboutDialogInfo.cpp:1776:20: error: rubyio.h: No such file or directory src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetName(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1856: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetName(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1882: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:1886: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:1886: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1905: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1931: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetVersion(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1955: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:1959: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:1959: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:1978: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2004: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2028: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2032: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2032: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2051: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2077: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetCopyright(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2101: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2105: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2105: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2124: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetLicense(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2149: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2175: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetLicence(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2199: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2203: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2203: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2224: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2229: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2232: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2255: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetIcon(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2279: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetWebSite(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2304: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasWebSite(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2335: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetWebSiteURL(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2359: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2363: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2363: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetWebSiteDescription(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2383: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2387: error: 'rb_utf8_encoding' was not declared in this scope src/AboutDialogInfo.cpp:2387: error: 'rb_enc_str_new' was not declared in this scope src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2407: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2417: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddDeveloper(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2447: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2473: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDevelopers(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2497: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2530: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2540: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddDocWriter(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2570: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2596: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetDocWriters(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2620: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2653: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2663: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddArtist(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2693: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2719: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetArtists(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2743: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_SetTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2776: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp:2786: error: 'struct RArray' has no member named 'len' src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_AddTranslator(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2816: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_HasTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2842: warning: format not a string literal and no format arguments src/AboutDialogInfo.cpp: In function 'VALUE _wrap_wxAboutDialogInfo_GetTranslators(int, VALUE*, VALUE)': src/AboutDialogInfo.cpp:2866: warning: format not a string literal and no format arguments rake aborted! Command failed with status (1): [g++ -c -I/opt/lib/wx/include/gtk2-unicod...] (See full trace by running task with --trace) chauk-mean at MyUbuntu:~/wxruby2$ I have buillt successfully wxRuby with ruby-1.8.7p72 and ruby-1.9.0-4. So this seems to be a problem with this more recent version of ruby 1.9. I found that rubyio.h is located in a 'backward' folder inside the ruby 1.9 include. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22745&group_id=35 From alex at pressure.to Tue Nov 11 05:34:16 2008 From: alex at pressure.to (Alex Fenton) Date: Tue, 11 Nov 2008 10:34:16 +0000 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: References: Message-ID: <49195FA8.9090200@pressure.to> Hi Chauk-Mean P wrote: > I wanted to have a look at wxRuby on a recent version of ruby 1.9 > (ruby-1.9.1-preview1) on Ubuntu 8.10 x86. > Here is the result : > > chauk-mean at MyUbuntu:~/wxruby2$ ruby19 -v > ruby 1.9.1 (2008-10-28 revision 19983) [i686-linux] > chauk-mean at MyUbuntu:~/wxruby2$ rake19 WXRUBY_VERSION=1.9.9 gem > (in /home/chauk-mean/wxruby2) > Enabling DYNAMIC build > Enabling RELEASE build > Enabling UNICODE build > The following wxWidgets features are not available and will be skipped: > PrinterDC > src/AboutDialogInfo.cpp:1776:20: error: rubyio.h: No such file or directory Thanks for the report. I've also been tracking ruby-1.9 with wxRuby not had any problems, but I haven't tried with 1.9.1. This is my version which works: Abaddon:~ alex$ ~/bleed/bin/ruby -v ruby 1.9.0 (2008-10-04 revision 19669) [i386-darwin9.5.0] I've filed this a bug, must fix for 2.0, http://rubyforge.org/tracker/index.php?func=detail&aid=22745&group_id=35&atid=218 cheers alex From chauk.mean at gmail.com Tue Nov 11 06:44:41 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 11 Nov 2008 12:44:41 +0100 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: <49195FA8.9090200@pressure.to> References: <49195FA8.9090200@pressure.to> Message-ID: Alex, 2008/11/11 Alex Fenton : > Chauk-Mean P wrote: >> >> chauk-mean at MyUbuntu:~/wxruby2$ ruby19 -v >> ruby 1.9.1 (2008-10-28 revision 19983) [i686-linux] >> chauk-mean at MyUbuntu:~/wxruby2$ rake19 WXRUBY_VERSION=1.9.9 gem > Thanks for the report. I've also been tracking ruby-1.9 with wxRuby not had > any problems, but I haven't tried with 1.9.1. This is my version which > works: > > Abaddon:~ alex$ ~/bleed/bin/ruby -v > ruby 1.9.0 (2008-10-04 revision 19669) [i386-darwin9.5.0] > Some notes on my configuration : - I've built and installed SWIG 1.3.35 with the default options - I have installed ruby-1.9.1 with the program suffix 19. Thus I can switch easily from ruby 1.8.7 to ruby 1.9.1 by just appending 19 to all ruby related commands (ruby19, gem19, rake19). I've already done that when I tried ruby-1.9.0-4 with wxRuby. With the modifications between ruby-1.9.1 and ruby-1.9.0-4, do you think that I have to install ruby-1.9.1 with the default name (i.e. ruby and not ruby19) wrt to SWIG ? Cheers. Chauk-Mean. From alex at pressure.to Tue Nov 11 07:22:17 2008 From: alex at pressure.to (Alex Fenton) Date: Tue, 11 Nov 2008 12:22:17 +0000 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: References: <49195FA8.9090200@pressure.to> Message-ID: <491978F9.4090708@pressure.to> Chauk-Mean P wrote: > With the modifications between ruby-1.9.1 and ruby-1.9.0-4, do you > think that I have to install ruby-1.9.1 with the default name (i.e. > ruby and not ruby19) wrt to SWIG ? No, SWIG doesn't care what ruby version you have installed, or even whether you have it installed it all. Our rakefiles at some points naively do `ruby ...` to call ruby scripts, but the behaviour of those scripts shouldn't vary by ruby version. It seems to be down to two changes in ruby 1.9.1 1) rubyio.h has been removed (in favour of ruby/io.h), so SWIG's generated code is now wrong. This is only properly fixable by a patch to SWIG, but we can add a temporary workaround in our SWIG-fixing rakefiles. 2) Our own typemaps call RARRAY(rb_array)->len when the correct 1.9 way is RARRAY_LEN(rb_array). I guess the old way is now completely removed in 1.9.1. We should update in all places to use the new way, as SWIG provides compatibility macros for ruby 1.8. a From noreply at rubyforge.org Tue Nov 11 18:18:02 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Nov 2008 18:18:02 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22765 ] Wx::ListCtrl needs a get_selections method Message-ID: <20081111231802.D09A318581B8@rubyforge.org> Bugs item #22765, was opened at 2008-11-11 23:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22765&group_id=35 Category: Missing API call Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Wx::ListCtrl needs a get_selections method Initial Comment: It's not very easy at the moment to get a list of the selections from a Wx::ListCtrl ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22765&group_id=35 From alex at pressure.to Wed Nov 12 08:12:28 2008 From: alex at pressure.to (Alex Fenton) Date: Wed, 12 Nov 2008 13:12:28 +0000 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: <491978F9.4090708@pressure.to> References: <49195FA8.9090200@pressure.to> <491978F9.4090708@pressure.to> Message-ID: <491AD63C.2020902@pressure.to> Alex Fenton wrote: > 1) rubyio.h has been removed (in favour of ruby/io.h), so SWIG's > generated code is now wrong. This is only properly fixable by a patch > to SWIG, but we can add a temporary workaround in our SWIG-fixing > rakefiles. I've submitted a patch to SWIG to fix this. The patch is attached here; it should be applied to /usr/local/share/swig-1.3.xx/ruby/file.i. I'll hope that the SWIG team pick this up soon and release it, so won't hack a workaround into our > 2) Our own typemaps call RARRAY(rb_array)->len when the correct 1.9 > way is RARRAY_LEN(rb_array). I guess the old way is now completely > removed in 1.9.1. We should update in all places to use the new way, > as SWIG provides compatibility macros for ruby 1.8. I've fixed all the occurrences in subversion. With the SWIG patch, SVN HEAD is now compiling ok with 1.9 cheers alex From alex at pressure.to Wed Nov 12 08:19:12 2008 From: alex at pressure.to (Alex Fenton) Date: Wed, 12 Nov 2008 13:19:12 +0000 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: <491AD63C.2020902@pressure.to> References: <49195FA8.9090200@pressure.to> <491978F9.4090708@pressure.to> <491AD63C.2020902@pressure.to> Message-ID: <491AD7D0.60509@pressure.to> Alex Fenton wrote: > I've submitted a patch to SWIG to fix this. The patch is attached > here; it should be applied to /usr/local/share/swig-1.3.xx/ruby/file.i. Oops, SWIG-fix patch now actually attached. The sourceforge tracker item is here: https://sourceforge.net/tracker2/?func=detail&aid=2263850&group_id=1645&atid=301645 a -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ruby_191_rubyio.patch URL: From chauk.mean at gmail.com Wed Nov 12 14:55:46 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Wed, 12 Nov 2008 20:55:46 +0100 Subject: [wxruby-development] Build problem with ruby-1.9.1-preview1 In-Reply-To: <491AD7D0.60509@pressure.to> References: <49195FA8.9090200@pressure.to> <491978F9.4090708@pressure.to> <491AD63C.2020902@pressure.to> <491AD7D0.60509@pressure.to> Message-ID: Hi Alex, 2008/11/12 Alex Fenton : >> I've submitted a patch to SWIG to fix this. The patch is attached here; it >> should be applied to /usr/local/share/swig-1.3.xx/ruby/file.i. > > Oops, SWIG-fix patch now actually attached. This works great now. Cheers. Chauk-Mean. From noreply at rubyforge.org Thu Nov 13 08:53:39 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Nov 2008 08:53:39 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22782 ] AuiDefaultDockArt class missing Message-ID: <20081113135340.07B5018585A7@rubyforge.org> Bugs item #22782, was opened at 13/11/2008 08:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22782&group_id=35 Category: Missing API call Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: AuiDefaultDockArt class missing Initial Comment: Concerning the Aui art providers, the AuiDockArt class already exists but AuiDefaultDockArt is missing from wxRuby (being present in wxWidgets). Adding the AuiDefaultDockArt class may let us easily subclass it instead of re-implementing every method in the AuiDockArt class (which is an abstract class in C++) Also, take good care of how these classes have to be GC managed. When passing an instance of these classes to AuiManager#set_art_provider the AuiManager takes ownership. It will C++ delete the instance at destruction time or when a new call to set_art_provider is done. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22782&group_id=35 From noreply at rubyforge.org Fri Nov 14 06:08:43 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Nov 2008 06:08:43 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22805 ] get_item_data methods are broken for TreeCtrl from GenericDirCtrl Message-ID: <20081114110843.9AFB018585AB@rubyforge.org> Bugs item #22805, was opened at 2008-11-14 11:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22805&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 4 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: get_item_data methods are broken for TreeCtrl from GenericDirCtrl Initial Comment: The item data in it are C++ structs, so should be returned direct to ruby. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22805&group_id=35 From noreply at rubyforge.org Fri Nov 14 07:32:06 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Nov 2008 07:32:06 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22810 ] Add Wx::get_mouse_state Message-ID: <20081114123206.DD94318585A0@rubyforge.org> Bugs item #22810, was opened at 2008-11-14 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22810&group_id=35 Category: Missing API call Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Add Wx::get_mouse_state Initial Comment: Analogous to Wx::get_mouse_position ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22810&group_id=35 From noreply at rubyforge.org Sat Nov 15 04:44:06 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Nov 2008 04:44:06 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-22828 ] XRCise does not work with Ruby 1.9 Message-ID: <20081115094406.60CEE18581AE@rubyforge.org> Bugs item #22828, was opened at 2008-11-15 09:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22828&group_id=35 Category: Incorrect behavior Group: wxSugar Status: Open Resolution: None Priority: 4 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: XRCise does not work with Ruby 1.9 Initial Comment: Some of the rdoc files it requires have moved. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=22828&group_id=35 From chauk.mean at gmail.com Mon Nov 17 05:12:12 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Nov 2008 11:12:12 +0100 Subject: [wxruby-development] About graphics_ctx requirement, gem for ruby-1.9.1, and cross compiling Message-ID: Hi, I'd really like to start using wxRuby with ruby-1.9.1 on Windows. Here are my feature requests by priority order : 1/ Currently, the build of wxRuby requires that the available build of wxWidgets has graphics_ctx. On Windows, this requires gdi+ support by wxWidgets and thus getting gdi+ files, patching wxWidgets code ... I wanted to build wxRuby trunk for ruby-1.9.1 on Windows. I don't use graphics_ctx in my application so the steps for supporting gdi+ are a bit restrictive. Can you consider removing this graphics_ctx requirement ? 2/ Otherwise, can you consider delivering upcoming wxRuby 2.0 gems for ruby-1.9.1 on Windows ? 3/ Cross-compiling wxWidgets for Windows from Linux via mingw works well. This seems not working with wxRuby. To benefit from all the comfort of a *NIX system, it would be great if cross-compiling is supported by wxRuby. Cheers. Chauk-Mean. From alex at pressure.to Mon Nov 17 05:48:55 2008 From: alex at pressure.to (Alex Fenton) Date: Mon, 17 Nov 2008 10:48:55 +0000 Subject: [wxruby-development] About graphics_ctx requirement, gem for ruby-1.9.1, and cross compiling In-Reply-To: References: Message-ID: <49214C17.6070205@pressure.to> Hi Chauk-Mean Chauk-Mean P wrote: > I'd really like to start using wxRuby with ruby-1.9.1 on Windows. Great. I've just recently switched over development to target 1.9. It all works nicely, apart from Ruby's dire performance with some methods on UTF-8 strings. > 1/ Currently, the build of wxRuby requires that the available build of > wxWidgets has graphics_ctx. > On Windows, this requires gdi+ support by wxWidgets and thus getting > gdi+ files, patching wxWidgets code ... > > I wanted to build wxRuby trunk for ruby-1.9.1 on Windows. > I don't use graphics_ctx in my application so the steps for supporting > gdi+ are a bit restrictive. > Can you consider removing this graphics_ctx requirement ? > Yes, we could. Happy to have a look at it if you file it as a feature request. As an alternative, I posted a pre-patched set of gdiplus headers and the dll to our website: http://wxruby.rubyforge.org/GDIplus_for_mingW.zip You should be able to just drop these into the MingW lib and include directories. > 2/ Otherwise, can you consider delivering upcoming wxRuby 2.0 gems for > ruby-1.9.1 on Windows ? > We'll definitely have wxRuby 2.0 gems for both versions. However at this stage it doesn't seem that the rubygems developers have come up with a way of distinguishing 1.8 from 1.9 gems. I tried renaming the 1.9 gems to wxruby_ruby19 but them gem install won't find the gems for remote install. I'm looking into it > 3/ Cross-compiling wxWidgets for Windows from Linux via mingw works well. > This seems not working with wxRuby. > To benefit from all the comfort of a *NIX system, it would be great if > cross-compiling is supported by wxRuby. Possible, but I personally know very little about cross-compiling. It would mean another dev environment and set of rake scripts to maintain, and with a working set for four compilers already (gcc on 3 platforms, MSVC7.1 on Windows) I'm not that keen to take on another. cheers alex From noreply at rubyforge.org Mon Nov 17 07:28:25 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Nov 2008 07:28:25 -0500 (EST) Subject: [wxruby-development] [ wxruby-Feature Requests-22844 ] Remove requirement for graphics_ctx in wxWidgets for building wxRuby Message-ID: <20081117122825.E8CDD18581A2@rubyforge.org> Feature Requests item #22844, was opened at 17/11/2008 13:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22844&group_id=35 Category: Other Group: User request Status: Open Priority: 3 Submitted By: Chauk-Mean P (chauk-mean) Assigned to: Kevin Smith (qualitycode) Summary: Remove requirement for graphics_ctx in wxWidgets for building wxRuby Initial Comment: Currently, the build of wxRuby requires that the available build of wxWidgets has graphics_ctx. On Windows, this requires gdi+ support by wxWidgets and thus getting gdi+ files, patching wxWidgets code ... This is a bit restrictive. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22844&group_id=35 From noreply at rubyforge.org Mon Nov 17 07:32:03 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Nov 2008 07:32:03 -0500 (EST) Subject: [wxruby-development] [ wxruby-Feature Requests-22846 ] Add textile documentation in source tarball Message-ID: <20081117123203.CD69A18581A2@rubyforge.org> Feature Requests item #22846, was opened at 17/11/2008 13:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22846&group_id=35 Category: Other Group: User request Status: Open Priority: 3 Submitted By: Chauk-Mean P (chauk-mean) Assigned to: Kevin Smith (qualitycode) Summary: Add textile documentation in source tarball Initial Comment: To avoid using subversion just for getting the textile documentation, the latter should be included into the source tarball or a new full source tarball. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22846&group_id=35 From noreply at rubyforge.org Mon Nov 17 07:34:19 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Nov 2008 07:34:19 -0500 (EST) Subject: [wxruby-development] [ wxruby-Feature Requests-22847 ] Remove wxWidgets requirement for the html_docs rake task Message-ID: <20081117123419.A5DB418581A2@rubyforge.org> Feature Requests item #22847, was opened at 17/11/2008 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22847&group_id=35 Category: Other Group: None Status: Open Priority: 3 Submitted By: Chauk-Mean P (chauk-mean) Assigned to: Kevin Smith (qualitycode) Summary: Remove wxWidgets requirement for the html_docs rake task Initial Comment: The html_docs rake task should not require the availability of wxWidgets. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22847&group_id=35 From chauk.mean at gmail.com Mon Nov 17 07:45:43 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Nov 2008 13:45:43 +0100 Subject: [wxruby-development] About graphics_ctx requirement, gem for ruby-1.9.1, and cross compiling In-Reply-To: <49214C17.6070205@pressure.to> References: <49214C17.6070205@pressure.to> Message-ID: Hi Alex, 2008/11/17 Alex Fenton : > Hi Chauk-Mean >> Can you consider removing this graphics_ctx requirement ? > > Yes, we could. Happy to have a look at it if you file it as a feature > request. Done. Feature Request #22844. > As an alternative, I posted a pre-patched set of gdiplus headers and the dll > to our website: > > http://wxruby.rubyforge.org/GDIplus_for_mingW.zip > > You should be able to just drop these into the MingW lib and include > directories. OK. Do I still need to patch the wxWidgets src\msw\graphics.cpp file ? > >> 2/ Otherwise, can you consider delivering upcoming wxRuby 2.0 gems for >> ruby-1.9.1 on Windows ? > > We'll definitely have wxRuby 2.0 gems for both versions. However at this > stage it doesn't seem that the rubygems developers have come up with a way > of distinguishing 1.8 from 1.9 gems. I tried renaming the 1.9 gems to > wxruby_ruby19 but them gem install won't find the gems for remote install. > I'm looking into it If we can download the gem and install it locally (with -l flag), I think that's a suitable workaround. > >> 3/ Cross-compiling wxWidgets for Windows from Linux via mingw works well. >> This seems not working with wxRuby. >> To benefit from all the comfort of a *NIX system, it would be great if >> cross-compiling is supported by wxRuby. > > Possible, but I personally know very little about cross-compiling. It would > mean another dev environment and set of rake scripts to maintain, and with a > working set for four compilers already (gcc on 3 platforms, MSVC7.1 on > Windows) I'm not that keen to take on another. OK. Cheers. Chauk-Mean. From chauk.mean at gmail.com Mon Nov 17 07:48:24 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Nov 2008 13:48:24 +0100 Subject: [wxruby-development] About Textile documentation for wxRuby In-Reply-To: References: <49183DEB.30207@pressure.to> Message-ID: Hi Alex, 2008/11/10 Chauk-Mean P : > Alex, > > 2008/11/10 Alex Fenton : >> Chauk-Mean P wrote: >>> - what about adding the Textile documentation into the source tarball ? >>> (this will avoid using subversion just for the documentation). >> >> I tested this out and it looks like adding the Textile sources to the source >> tarball would increase its size by about 600kb. I'm not sure this is >> justifiable on its own as the base tarball is only 1MB. But like wxWidgets, >> I guess we could offer a wxruby-src-full tarball with more stuff in it like >> textile sources > > That's fine. > >> and possibly generated docs. > > I don't think that it is useful. Unlike the textile documentation, the > generated docs already has its own tarball. > I've filed Feature Request #22846. >>> - can the requirements on wxWidgets be removed for the html_docs rake task ? >> >> Yes, only the textile_docs task depends on the wxWidgets sources being >> installed. And we never normally need to run this task, except to generate >> docs when new classes are added. I've filed Feature Request #22847. Cheers. Chauk-Mean. From noreply at rubyforge.org Tue Nov 18 16:07:31 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Nov 2008 16:07:31 -0500 (EST) Subject: [wxruby-development] [ wxruby-Feature Requests-22878 ] TEST: who is this assigned to? Message-ID: <20081118210731.2D58F185859F@rubyforge.org> Feature Requests item #22878, was opened at 2008-11-18 16:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22878&group_id=35 Category: None Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: TEST: who is this assigned to? Initial Comment: Just a test... please ignore - AF ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=22878&group_id=35