From stefano.grioni at epfl.ch Wed Sep 1 06:16:40 2010 From: stefano.grioni at epfl.ch (Grioni Stefano) Date: Wed, 1 Sep 2010 12:16:40 +0200 Subject: [wxruby-development] Problems with Wx::XmlResource documentation In-Reply-To: References: <4C7CA339.2040809@fastmail.fm> Message-ID: Hello, I am not sure to fully understand what you mean. If I come back to my case of choice-box. I would like to call the "change_something" method each time the choice of the menu is changed. What would be the correct way to do it? Because I first have to retrieve such Choice object (and I did not see anywhere in the documentation an explanation about how to perform this) and then call evt_choice(my_choice_object, : change_something) in order to bound them together. Right? Wouldn't it just be easier to perform it automatically on init? I mean, when the xrc is parsed, and an handler tag is encountered, everything we need is already there, so why just not call the method at that time? I feel that I am mis-understanding the logic behind your choice, so excuse me for such questions. Bests, Stefano From: wxruby-development-bounces at rubyforge.org [mailto:wxruby-development-bounces at rubyforge.org] On Behalf Of Mario Steele Sent: mercredi 1 septembre 2010 01:39 To: Internal/technical wxruby discussions Subject: Re: [wxruby-development] Problems with Wx::XmlResource documentation Hello Stefano, On Tue, Aug 31, 2010 at 2:25 PM, Grioni Stefano > wrote: Hi, Thanks for your answer. However how comes that the init_all_handlers method exists? Is it some work-in-progress or may I prune it as well ? The method init_all_handlers initializes all handlers that WxWidget's use, such as Images, Media, so on and so forth. This method is actually called when Wx::main_loop is called, but users can run the method before the main loop, so as to allow for loading of certain resources before going into the main loop, such as a splash screen, or such. We don't support all init*handler functions in the wxWidgets library, as it's generally covered by a main one, and it's automatically called upon without the need for the user to call them manually. We would need to see a valid reason to allow the function to be wrapped into wxRuby, that can't be covered by something that already exists. The other part, where your importing an XRC File, in most general cases the XRC members for function calls on events, is generally used in generation of the C/C++ Code by the XRC WYSIWYG designer. It lays forth the ground work in the C++ files that it generates, and nothing further is connected. I believe trying to get event handlers to connect with Methods in Ruby, would be a bit harder to get working, as we have to get the class and symbol name, in order to correctly make the connection. Some people don't define method call-backs in the same class as the GUI Element. Which is part of what makes wxRuby so much more dynamic, instead of having a singular static way of doing things, there are many ways in which to connect things together. hth, Mario Bests, Stefano ________________________________________ From: wxruby-development-bounces at rubyforge.org [wxruby-development-bounces at rubyforge.org] On Behalf Of Pascal Hurni [pascal_hurni at fastmail.fm] Sent: Tuesday, August 31, 2010 8:37 AM To: Internal/technical wxruby discussions Subject: Re: [wxruby-development] Problems with Wx::XmlResource documentation Hi, Welcome to wxruby! AFAICT the classes docs were initially created by parsing the original WxWidget code or doc. Then they were modified to match ruby behaviour where it matches. Thus the XmlResource doc is out of date because as you discovered several methods are not implemented. Got from the SWIG files: // Can't write XRC handlers in Ruby %ignore wxXmlResource::AddHandler; %ignore wxXmlResource::ClearHandlers; %ignore wxXmlResource::InsertHandler; So these methods are not available in ruby, I think you may submit a ticket with a patch removing the doc for these methods. We certainly can re-doc them the day we support handlers. Once again AFAIK, handlers & events are ignored for the moment. So you may not register an event method like shown on your XML. Personnaly I patched and subclassed some items in wxruby (all from ruby code, no C patches) that simplifies working with XRC (sorry folks I'm not on the xrcise side). These patches may be a little outdated (back to version ~1.9.7). Best Regards, Pascal Le 26.08.10 15:21, Grioni Stefano a ?crit : Hello, I have just started using WxWidgets, as I now need to design cross-plateform GUIs for an application and I have been experiencing some troubles finding my way through the existing documentation (several broken links, lack of description about some methods,...) I am therefore compiling a little patch correcting the mistakes I found. There are however some things I just don't get, and I would like to have your point of view about them. - In the online doc of xmlresource class (http://wxruby.rubyforge.org/doc/xmlresource.html) , there is a link named "XML-based resource system overview" that is broken. Do you wanna remove such link of did the resource just move elsewhere, and so the link just has to be fixed? - Several methods ( like "add_handler" seem to be removed from the actual class, do you want me to remove them from the page as well?) - I really don't understand what the "init_all_handlers" is supposed to do. In fact I created a handler in my xrc for a "choice" : change_something 0 Swiss Production Only World Production comparison World Consumption comparison Swiss detailed charts default normal MS Shell Dlg 2 0 12 But in fact, nothing happens when I change the selected item in the menu (despite the fact that I actually have a "change_something" method). I would be glad to bring my little help to the project so that future devs won't ask themselves the same questions, I just need a little infos in order to see how this things were imagined. Bests, Stefano _______________________________________________ wxruby-development mailing list wxruby-development at rubyforge.org> http://rubyforge.org/mailman/listinfo/wxruby-development _______________________________________________ wxruby-development mailing list wxruby-development at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-development -- Mario Steele Lieutenant Commander 3 XO - Geo 99 XO - STO IFT Fleet http://www.trekfederation.com http://geo99.ruby-im.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.grioni at epfl.ch Mon Sep 6 05:43:08 2010 From: stefano.grioni at epfl.ch (Grioni Stefano) Date: Mon, 6 Sep 2010 11:43:08 +0200 Subject: [wxruby-development] Question about Event.clone Message-ID: Hello, I today noticed a surprising behavior while trying to duplicate a CommandEvent object. In fact I have the following lines in my program : p evt @previous_event = evt.clone p @previous_event The output is the following: # # Wheras I would expect @previous_event to be an instance of CommandEvent as well. I guess (did not check yet) that CommandEvent did not define its specialization of the clone method. In this kind of case, who do you react? Do you correct it into the C code? Do you correct it in Ruby code? To you let the "users" deal with it in their own program? Thanks for your answer, Bests Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at ruby-im.net Tue Sep 7 20:39:09 2010 From: mario at ruby-im.net (Mario Steele) Date: Tue, 7 Sep 2010 20:39:09 -0400 Subject: [wxruby-development] wxRuby and SWIG-2.0 In-Reply-To: References: Message-ID: Hey Chauk, I just took a look to see where it was, and it looks like you checked in to branches/wxruby_2_0_stable the stuff for SWIG. It probably would have been best to check the stuff into trunk/wxruby directly, so that way it's in there, we can always backout, or revert your changes if need be. Just a FYI. On Mon, Aug 30, 2010 at 5:08 PM, Chauk-Mean Proum wrote: > Hi, > > 2010/8/30 Mario Steele : > > and if you have been able to get wxRuby > > to compile against 2.0 of SWIG, then I say go ahead and commit it. > > Done. > I've also tested on Ubuntu 9.10 with ruby-1.9.2-p0 and the > wxWidgets-2.8.10 package from Ubuntu. > > Cheers, > Chauk-Mean > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > -- Mario Steele Lieutenant Commander 3 XO - Geo 99 XO - STO IFT Fleet http://www.trekfederation.com http://geo99.ruby-im.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonxrowland at gmail.com Tue Sep 7 21:13:07 2010 From: jasonxrowland at gmail.com (Jason Rowland) Date: Tue, 7 Sep 2010 19:13:07 -0600 Subject: [wxruby-development] wxruby compile on Snow Leopard Message-ID: I am trying to compile and install from source on Snow Leopard 10.6.4. I want to use the trunk version with the hope of being able to contribute in the future. I get an error indicating it can't figure out the architecture type. I assume this is related to the 64bit vs 32bit issue. I've included the commands I used to compile. Any help would be appreciated. # Download, compile, install the 2.8.11 version of wxMac for 10.6 only mkdir osx-build cd osx-build arch_flags="-arch i386" ../configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --enable-universal_binary --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk --with-macosx-version-min=10.4 --disable-shared --enable-unicode --enable-static --disable-debug --enable-catch_segvs --enable-graphics_ctx --enable-mediactrl --with-opengl --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-expat=builtin --enable-gui --enable-xrc --enable-mdi --enable-gif --enable-pcx --enable-iff --enable-pnm --enable-xpm --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-macosx-version-min=10.6 make sudo make install # Download, compile, install SWIG 1.3.38 ( I also tried 2.0.0 as I thought i read an email stating trunk was going to be updated to require this) cd /usr/local/swig-1.3.38 sudo ./configure --disable-ccache #--disable-ccache is because I do not have yodl2man installed sudo make sudo make install # Check out, compile wxruby from subversion svn checkout svn://rubyforge.org/var/svn/wxruby cd wxruby/trunk rake # ---------------- ERROR I get the following error: lipo: can't figure out the architecture type of: /var/folders/pI/pIyyNf1MGiaa6DODFaul2U+++TI/-Tmp-//ccmdge2D.out lipo: can't open input file: /var/folders/pI/pIyyNf1MGiaa6DODFaul2U+++TI/-Tmp-//ccsraXTA.out (No such file or directory) rake aborted! Command failed with status (1): [g++ -c -I/usr/local/lib/wx/include/mac-un...] Thanks, Jason Rowland -------------- next part -------------- An HTML attachment was scrubbed... URL: From chauk.mean at gmail.com Thu Sep 9 15:29:50 2010 From: chauk.mean at gmail.com (Chauk-Mean Proum) Date: Thu, 9 Sep 2010 21:29:50 +0200 Subject: [wxruby-development] wxRuby and SWIG-2.0 In-Reply-To: References: Message-ID: Hi Mario, 2010/9/8 Mario Steele : > Hey Chauk, > I just took a look to see where it was, and it looks like you checked in to > branches/wxruby_2_0_stable the stuff for SWIG. ?It probably would have been > best to check the stuff into trunk/wxruby directly, so that way it's in > there, we can always backout, or revert your changes if need be. > Just a FYI. The reasons why I committed the changes on the wxruby_2_0_stable branch are twofold : - switching to SWIG-2.0 does not introduce any incompatible changes for the user. SWIG is an internal/development dependency. - I find it valuable that the upcoming stable wxRuby release will rely on a stable/up to date SWIG release. Cheers, Chauk-Mean.