From noreply at rubyforge.org Tue Sep 4 03:58:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 Sep 2007 03:58:19 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-13640 ] Invalid value for TreeCtrl#get_root_id when TR_HIDE_ROOT style is set (MSW) Message-ID: <20070904075819.D4E195240D6D@rubyforge.org> Bugs item #13640, was opened at 2007-09-04 07:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13640&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Invalid value for TreeCtrl#get_root_id when TR_HIDE_ROOT style is set (MSW) Initial Comment: When a TreeCtrl is created with the TR_HIDE_ROOT style, the id values returned by add_root and get_root_id are invalid (-65636) - if passed back into get_item_text , get_item_data, item_has_children etc nothing is returned. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13640&group_id=35 From noreply at rubyforge.org Wed Sep 5 00:01:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 5 Sep 2007 00:01:02 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-13676 ] xrc listctrl windows custom data crash Message-ID: <20070905040103.A75665240E9A@rubyforge.org> Bugs item #13676, was opened at 2007-09-05 14:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13676&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Bela Babik (teki321) Assigned to: Nobody (None) Summary: xrc listctrl windows custom data crash Initial Comment: I have attached the source and the xrc files. Double click on any line to get the crash: $ ./wxb.rb ./wxb.rb:28: [BUG] Segmentation fault ruby 1.8.6 (2007-03-13) [i386-mswin32] This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. >From the documentation: Boolean set_item_data(Integer item, Integer data) Integer get_item_data(Integer item) They shouldn't accept non integer data. Right now this is accepted: @lst.set_item_data(x,[x,x]) I don't know how it supposed to work, but it seems that the ruby object is converted to long and then back (ListCtrl.i): VALUE get_item_data(int row) { if ( row < 0 || row >= self->GetItemCount() ) return Qnil; long item_data = self->GetItemData(row); if ( item_data == 0 ) return Qnil; return (VALUE)item_data; } VALUE set_item_data(int row, VALUE ruby_obj) { if ( row < 0 || row >= self->GetItemCount() ) { rb_raise(rb_eIndexError, "Uninitialized item"); } long item_data = (long) ruby_obj; bool result = self->SetItemData(row, item_data); if ( result ) return Qtrue; return Qnil; } ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13676&group_id=35 From mario at ruby-im.net Wed Sep 5 00:13:12 2007 From: mario at ruby-im.net (Mario Steele) Date: Tue, 04 Sep 2007 23:13:12 -0500 Subject: [wxruby-development] [wxruby-users] listctrl set_item_data In-Reply-To: References: <46DD211D.8080207@pressure.to> Message-ID: <46DE2CD8.7000308@ruby-im.net> Bela Babik wrote: > Created a bug report: > http://rubyforge.org/tracker/index.php?func=detail&aid=13676&group_id=35&atid=218 > > From Bug Report: > I don't know how it supposed to work, but it seems that the ruby object is converted to long and then back (ListCtrl.i): > VALUE get_item_data(int row) > { > if ( row < 0 || row >= self->GetItemCount() ) return Qnil; > long item_data = self->GetItemData(row); > if ( item_data == 0 ) return Qnil; > return (VALUE)item_data; > } > > VALUE set_item_data(int row, VALUE ruby_obj) > { > if ( row < 0 || row >= self->GetItemCount() ) > { > rb_raise(rb_eIndexError, "Uninitialized item"); > } > long item_data = (long) ruby_obj; > bool result = self->SetItemData(row, item_data); > if ( result ) > return Qtrue; > return Qnil; > } >From this information you provided, I belive that the wxListCtrl#set_item_data and wxListCtrl#get_item_data need a Integer based value, and the way Alex has interpreted this to work, is to convert the Ruby Object into a pointer to it, so that the data can be saved to the wxListCtrlItem, and then later retrived via converting the pointer back into a Ruby Object, and returning the value of it. However, all that is being returned, is either nil, or corrupt data. There is two options for this. One option, is to correct the way set_item_data and get_item_data in the backend, /OR/ modify the Ruby Side of the Code, using a class attribute for ListCtrlItem, to store the data in a hash, with the item instance as the key, and the data as the value, and then overloading the set_item_data/get_item_data to code that will simply set and fetch the data from the hash. Just my two cents. Also, sending this to the Development list to, so that way, it's on both lists. Mario Steele From noreply at rubyforge.org Fri Sep 7 01:43:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 01:43:55 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-13734 ] Problem with TreeCtrl#get_first_child and #get_next_child on MSW Message-ID: <20070907054355.C7249A97000B@rubyforge.org> Bugs item #13734, was opened at 2007-09-07 05:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13734&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: Problem with TreeCtrl#get_first_child and #get_next_child on MSW Initial Comment: On Windows, the "cookie" value does not seem to be getting returned correctly when looping over children in TreeCtrl. It is always returned as 0 - this can be seen in the treectrl.rb sample. This also causes assertion failures in debug mode. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=13734&group_id=35 From mario at ruby-im.net Fri Sep 7 02:15:29 2007 From: mario at ruby-im.net (Mario Steele) Date: Fri, 07 Sep 2007 01:15:29 -0500 Subject: [wxruby-development] Ruby IDE with wxRuby Message-ID: <46E0EC81.3010509@ruby-im.net> Hello All, There seems to have been a lot of interest in getting wxScintilla incorperated, and I think most of us who want it, want it so we can create an editor, so to avoid multiple projects comming out with the same goal (Not really that bad of a problem....), I'm going to kick start this, and ask that anyone interested in developing a Editor with wxRuby and wxScintilla, to send me an Email off list, and I'll establish an Email List for us to talk about with getting an IDE together. More programmers on a project definatly can help out. Make sure you use the email address that you want to receive the emails from the list on, when you email me. L8ers, Mario Steele From alex at pressure.to Sun Sep 9 07:25:59 2007 From: alex at pressure.to (Alex Fenton) Date: Sun, 09 Sep 2007 12:25:59 +0100 Subject: [wxruby-development] building wxruby on 64-bit arch Message-ID: <46E3D847.3020503@pressure.to> Hi Just to report the outcome of a recent request about building wxRuby2 on AMD64 architecture - after a bit of to-ing and fro-ing, turns out to be quite possible. What's needed is a few extra flags appended to the recommended configure options of wxWidgets |CFLAGS=-fPIC CXXFLAGS=-fPIC LDFLAGS=-fPIC This seems to be needed because we compile a static wxWidgets which ends up in a dynamically loaded ruby .so file. This is written up here http://wxruby.rubyforge.org/wiki/wiki.pl?HowToBuildWxWidgets Thanks to Glenn Davy who tried out different options and has also now provided a binary gem for x86_64-linux. Hopefully this will also help people who want to install on Intel-64 and/or 64-bit Windows - if anyone has these platforms and wants to provide a binary gem, drop me a line... cheers alex | From alex at pressure.to Mon Sep 10 16:39:41 2007 From: alex at pressure.to (Alex Fenton) Date: Mon, 10 Sep 2007 21:39:41 +0100 Subject: [wxruby-development] syntax II Message-ID: <46E5AB8D.9090109@pressure.to> Hi Given the warm response to the syntax additions in 1.9.1 I'm considering moving one or two more syntax extensions into core, and would like your thoughts. Last ones, I promise. Realise we don't want much more API change now, but also we'll probably also have to live with whatever we settle on for 2.0 for a little while, so... 1) Setting up event handlers In most real apps, I think the most normal way to set up event handlers is for the event to be dealt with by a corresponding method. At the moment this has to be done using a block: evt_button(AN_ID) { on_button_click } evt_button(my_button.get_id) do | event | on_button_click(event) end evt_size { | event | on_size(event) } This is a sensible way to organise classes but it seems to have redundancy in it. The bigger one is having to create a block, with param, just to call a method; the smaller one is having to call a method to get a window id. So I'd like to suggest as alternatives: evt_button(AN_ID, :on_button_click) evt_button my_button, :on_button_click evt_size :on_size If a symbol is passed instead of a block, it's assumed the event handler should call that method in self. Whether or not to pass the event handling method an Event argument can be determined by looking at the method's event signature. If an event handler requires a wx window id to identify which widget's events are being listened for (as with CommandEvents like evt_button), it's assumed that if a Wx::Window is passed, we want its id. Code that does this is already in wxSugar - event_connector, but I think it would be better to build on the existing evt_xxx syntax than introduce a new syntax. This doesn't break backward compatibility, and isn't "magic". 2) 'each' for list-like classes This one I'm less bothered about, but I fairly often want to loop over a control with multiple items (eg Choice, ListCtrl, ListBox) to find or alter a particular item. So for those classes I wonder if we should add an 'each' method that passes in turn each valid index into the widget: listbox.each { | i | set_item_text(i, item_text(i).upcase) } Or even: listbox.each { | i | self.item_text[i] = item_text[i].upcase } Anyway, shout if you love this or hate these... cheers alex From mario at ruby-im.net Tue Sep 11 10:52:04 2007 From: mario at ruby-im.net (Mario Steele) Date: Tue, 11 Sep 2007 09:52:04 -0500 Subject: [wxruby-development] syntax II In-Reply-To: <46E5AB8D.9090109@pressure.to> References: <46E5AB8D.9090109@pressure.to> Message-ID: <46E6AB94.60008@ruby-im.net> Since this has yet to be commented on..... Let me be the first to say, that this would defiantly be a good thing to do. This would defiantly make code a lot cleaner, and easier to read and understand, plus make it easier for the programmer to write stuff for. If this is defiantly a go for, I will be happy to include this in the wxSocket code when I'm done. I have finally gotten all the information I need to make it work. It won't be as conventional as what is being implemented in the C++ side, as it is, shall we say, difficult to follow the C++ side, within the Ruby side of the code. Therefore, I'm making a few compromises, and utilizing what is available in wxRuby to create fully Asynchronous Sockets, that will not block the GUI, which also includes the ability to do Asynchronous Connects to servers. I will be leaving UDP, AKA Connect-less connections out of the wxSocket code that I write for now, till I get a better handle on first dealing with the Socket connection side, and getting that into the wxRuby code. I just got the 1.9.1 code, and am excited to see the StyledTextCtrl available now, and working properly on Windows XP. Good work Alex, and all those that helped out in getting it together. This is indeed a good time for wxRuby, which will help to ensure that everything will come together as we hope for. Mario Steele Alex Fenton wrote: > Hi > > Given the warm response to the syntax additions in 1.9.1 I'm considering > moving one or two more syntax extensions into core, and would like your > thoughts. Last ones, I promise. Realise we don't want much more API > change now, but also we'll probably also have to live with whatever we > settle on for 2.0 for a little while, so... > > 1) Setting up event handlers > > In most real apps, I think the most normal way to set up event handlers > is for the event to be dealt with by a corresponding method. At the > moment this has to be done using a block: > > evt_button(AN_ID) { on_button_click } > evt_button(my_button.get_id) do | event | > on_button_click(event) > end > evt_size { | event | on_size(event) } > > This is a sensible way to organise classes but it seems to have > redundancy in it. The bigger one is having to create a block, with > param, just to call a method; the smaller one is having to call a method > to get a window id. So I'd like to suggest as alternatives: > > evt_button(AN_ID, :on_button_click) > evt_button my_button, :on_button_click > evt_size :on_size > > If a symbol is passed instead of a block, it's assumed the event handler > should call that method in self. Whether or not to pass the event > handling method an Event argument can be determined by looking at the > method's event signature. > > If an event handler requires a wx window id to identify which widget's > events are being listened for (as with CommandEvents like evt_button), > it's assumed that if a Wx::Window is passed, we want its id. > > Code that does this is already in wxSugar - event_connector, but I think > it would be better to build on the existing evt_xxx syntax than > introduce a new syntax. This doesn't break backward compatibility, and > isn't "magic". > > 2) 'each' for list-like classes > > This one I'm less bothered about, but I fairly often want to loop over a > control with multiple items (eg Choice, ListCtrl, ListBox) to find or > alter a particular item. So for those classes I wonder if we should add > an 'each' method that passes in turn each valid index into the widget: > > listbox.each { | i | set_item_text(i, item_text(i).upcase) } > > Or even: > > listbox.each { | i | self.item_text[i] = item_text[i].upcase } > > Anyway, shout if you love this or hate these... > > cheers > alex > > > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > > From teki321 at gmail.com Wed Sep 12 00:24:22 2007 From: teki321 at gmail.com (Bela Babik) Date: Wed, 12 Sep 2007 14:24:22 +1000 Subject: [wxruby-development] syntax II In-Reply-To: <46E5AB8D.9090109@pressure.to> References: <46E5AB8D.9090109@pressure.to> Message-ID: > 1) Setting up event handlers ... > evt_button(AN_ID, :on_button_click) > evt_button my_button, :on_button_click > evt_size :on_size I like them. > 2) 'each' for list-like classes ... > listbox.each { | i | set_item_text(i, item_text(i).upcase) } Not bad, but I can live without it. teki From alex at pressure.to Wed Sep 12 13:26:15 2007 From: alex at pressure.to (Alex Fenton) Date: Wed, 12 Sep 2007 18:26:15 +0100 Subject: [wxruby-development] XRC Tool Message-ID: <46E82137.7000805@pressure.to> Hi Attached is a rough draft of a tool that parses XRC files and creates skeleton ruby class files from them. ruby xrc-tool.rb my_frame.xrc > my_frame.rb At the moment it only deals with Frame/Dialog/Panel subclasses, for which it creates a constructor that loads from the XML, and binds the named controls in the XML to ruby variables and accessors. THe idea is that this would make working with a visual designer easier: save your XRC files in one directory, run the tool whenever needed (poss via rake). Have the actual ruby classes you use (with the hand-written event handling code) inherit from these auto-generated files. I'll probably tidy up and add to wxSugar. - Suggestions welcome... - Not sure what to do about non-subclass Dialogs/MenuBars/ToolBars etc. - Not sure if it deals with all varieties of XRC - I've only tried it on listbook.xrc from the wxRuby samples - testing welcome cheers alex -------------- next part -------------- A non-text attachment was scrubbed... Name: xrc-tool.rb Type: application/x-ruby Size: 3002 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-development/attachments/20070912/d5ab6fe1/attachment.bin From sean.m.long at gmail.com Wed Sep 12 19:07:21 2007 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 12 Sep 2007 16:07:21 -0700 Subject: [wxruby-development] XRC Tool In-Reply-To: <46E82137.7000805@pressure.to> References: <46E82137.7000805@pressure.to> Message-ID: Very cool Alex! I think that would be a good addition to wxSugar. The only thing that bugs me on the generated code is how long the attr_reader line is. I made a modified version which allows you to choose if you want each attr_reader to be on its own line or to wrap every so many columns. Sean On 9/12/07, Alex Fenton wrote: > Hi > > Attached is a rough draft of a tool that parses XRC files and creates > skeleton ruby class files from them. > > ruby xrc-tool.rb my_frame.xrc > my_frame.rb > > At the moment it only deals with Frame/Dialog/Panel subclasses, for > which it creates a constructor that loads from the XML, and binds the > named controls in the XML to ruby variables and accessors. > > THe idea is that this would make working with a visual designer easier: > save your XRC files in one directory, run the tool whenever needed (poss > via rake). Have the actual ruby classes you use (with the hand-written > event handling code) inherit from these auto-generated files. > > I'll probably tidy up and add to wxSugar. > > - Suggestions welcome... > - Not sure what to do about non-subclass Dialogs/MenuBars/ToolBars etc. > - Not sure if it deals with all varieties of XRC - I've only tried it on > listbook.xrc from the wxRuby samples - testing welcome > > cheers > alex > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: xrc-tool-2.rb Type: text/x-ruby-script Size: 3663 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-development/attachments/20070912/e90dfb17/attachment-0001.bin From roys at mindspring.com Thu Sep 13 01:33:30 2007 From: roys at mindspring.com (Roy Sutton) Date: Thu, 13 Sep 2007 01:33:30 -0400 Subject: [wxruby-development] Scintilla In-Reply-To: <46D5FB44.7060706@pressure.to> References: <46D5FB44.7060706@pressure.to> Message-ID: <46E8CBAA.8000701@mindspring.com> Alex Fenton wrote: > Hi > > I've been trying out the StyledTextCtrl/Scintilla component bundled with > wxWidgets 2.8. Surprisingly, it's very easy to get this working at a > basic level with wxRuby (95% of credit to Roy, who originally created a > SWIG file for this). > > Sorry for the late reply on this but I'm glad to see this make it in and that the work I did was useful! Great work as always, Alex. I look forward to seeing a ruby-based editor now. :) Roy From chauk.mean at gmail.com Mon Sep 17 04:06:08 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Sep 2007 10:06:08 +0200 Subject: [wxruby-development] Re : syntax II Message-ID: Alex Fenton wrote : >1) Setting up event handlers > >In most real apps, I think the most normal way to set up event handlers >is for the event to be dealt with by a corresponding method. At the >moment this has to be done using a block: > >evt_button(AN_ID) { on_button_click } >evt_button(my_button.get_id) do | event | > on_button_click(event) >end >evt_size { | event | on_size(event) } > >So I'd like to suggest as alternatives: > >evt_button(AN_ID, :on_button_click) >evt_button my_button, :on_button_click >evt_size :on_size These are very useful additions especially the second one which removes the need for getting the id of the button, through get_id or wx_id or maybe id (see my post on [wxruby-users] wxRuby 1.9.1 and id accessor consistency problem). I would suggest that the second addition is also reported to the block form. Indeed, there are simple cases where using a block is more simple/practical than defining and using a method. It would be great to have the following addition also : evt_button(my_button) { puts "Button clicked" } This removes the burden of providing explicitly the id of the button. >2) 'each' for list-like classes > >This one I'm less bothered about, but I fairly often want to loop over a >control with multiple items (eg Choice, ListCtrl, ListBox) to find or >alter a particular item. So for those classes I wonder if we should add >an 'each' method that passes in turn each valid index into the widget: > >listbox.each { | i | set_item_text(i, item_text(i).upcase) } > Everything that makes wxRuby looks more Ruby is good. Nevertheless, I don't know if I will use this feature often. Cheers. Chauk-Mean. From alex at pressure.to Mon Sep 17 05:29:02 2007 From: alex at pressure.to (Alex Fenton) Date: Mon, 17 Sep 2007 10:29:02 +0100 Subject: [wxruby-development] Re : syntax II In-Reply-To: References: Message-ID: <46EE48DE.1010205@pressure.to> Chauk-Mean P wrote: > Alex Fenton wrote : > >> 1) Setting up event handlers >> >> ... >> evt_button(AN_ID, :on_button_click) >> evt_button my_button, :on_button_click >> evt_size :on_size >> > > These are very useful additions especially the second one which > removes the need for getting the id of the button, through get_id or > wx_id or maybe id (see my post on [wxruby-users] wxRuby 1.9.1 and id > accessor consistency problem). > Glad you like them. I was going to reply to your last post on wxruby-users that upcoming syntax changes would obviate the most common need to call Window#get_id - but you have beaten me to it :) > I would suggest that the second addition is also reported to the block form. Sure, that was implied. The syntax will be: evt_foo(window_or_id, block_or_symbol) >> listbox.each { | i | set_item_text(i, item_text(i).upcase) } >> >> > > Everything that makes wxRuby looks more Ruby is good. > Nevertheless, I don't know if I will use this feature often. > The sense I'm getting is that this is a bit marginal. I find it useful to locate the item which has an application object as item_data, when that object is updated elsewhere, eg item_to_update = listbox.each { | i | break i if listbox.item_data(i) == obj } But I think this can probably stay in wxSugar for now a From chauk.mean at gmail.com Mon Sep 17 13:27:33 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Sep 2007 19:27:33 +0200 Subject: [wxruby-development] Re : syntax II In-Reply-To: <46EE48DE.1010205@pressure.to> References: <46EE48DE.1010205@pressure.to> Message-ID: 2007/9/17, Alex Fenton : > > > Glad you like them. I was going to reply to your last post on > wxruby-users that upcoming syntax changes would obviate the most common > need to call Window#get_id I completely agree. Nevertheless, does that mean that you will keep wx_id ? If this is the case, it's a pity as it introduces an exception to the "accessor rule". I'd really prefer an id accessor. In addition to the overall consistency, you would not have to add extra documentation :-) > Sure, that was implied. The syntax will be: > > evt_foo(window_or_id, block_or_symbol) > Very cool. I'm looking forward the next version of wxRuby. When is it expected to be released ? Chauk-Mean. From alex at pressure.to Mon Sep 17 13:54:01 2007 From: alex at pressure.to (Alex Fenton) Date: Mon, 17 Sep 2007 18:54:01 +0100 Subject: [wxruby-development] Re : syntax II In-Reply-To: References: <46EE48DE.1010205@pressure.to> Message-ID: <46EEBF39.2060405@pressure.to> Chauk-Mean P wrote: > Nevertheless, does that mean that you will keep wx_id ? > If this is the case, it's a pity as it introduces an exception to the > "accessor rule". I'd really prefer an id accessor. I don't have a strong view - I think I agree with you. Does anyone else have a strong view? If you could point me to some "official" discussion of the deprecation of Object#id and its availability for library/app specific use I'd be convinced to make id mean Wx::Window#id. > Very cool. I'm looking forward the next version of wxRuby. > When is it expected to be released ? Not certain - we've just started work on 1.9.2. Given our current release cycle, I'd expect 3-6 weeks. If you're very eager, try SVN. I've recently checked in this change: http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb a From chauk.mean at gmail.com Mon Sep 17 16:30:56 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Mon, 17 Sep 2007 22:30:56 +0200 Subject: [wxruby-development] Re : syntax II In-Reply-To: <46EEBF39.2060405@pressure.to> References: <46EE48DE.1010205@pressure.to> <46EEBF39.2060405@pressure.to> Message-ID: 2007/9/17, Alex Fenton : > Chauk-Mean P wrote: > > Nevertheless, does that mean that you will keep wx_id ? > > If this is the case, it's a pity as it introduces an exception to the > > "accessor rule". I'd really prefer an id accessor. > I don't have a strong view - I think I agree with you. Does anyone else > have a strong view? If you could point me to some "official" discussion > of the deprecation of Object#id and its availability for library/app > specific use I'd be convinced to make id mean Wx::Window#id. The Ruby for Rails book (David A. Black) p110 gives the whole story of Object#id and Object#object_id. As an example, ActiveRecord is mentioned as using id for the database id which is completely different from the object_id. I hope that this is sufficiently official :-) > > Very cool. I'm looking forward the next version of wxRuby. > > When is it expected to be released ? > Not certain - we've just started work on 1.9.2. Given our current > release cycle, I'd expect 3-6 weeks. If you're very eager, try SVN. I've > recently checked in this change: > > http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb > Thanks. I will try it. Just for my information, you replied in French to a post, are you french ? Chauk-Mean. From alex at pressure.to Mon Sep 17 17:46:58 2007 From: alex at pressure.to (Alex Fenton) Date: Mon, 17 Sep 2007 22:46:58 +0100 Subject: [wxruby-development] Re : syntax II In-Reply-To: References: <46EE48DE.1010205@pressure.to> <46EEBF39.2060405@pressure.to> Message-ID: <46EEF5D2.5030408@pressure.to> Chauk-Mean P wrote: > 2007/9/17, Alex Fenton : > >> I don't have a strong view - I think I agree with you. Does anyone else >> have a strong view? If you could point me to some "official" discussion >> of the deprecation of Object#id and its availability for library/app >> specific use I'd be convinced to make id mean Wx::Window#id. >> > > The Ruby for Rails book (David A. Black) p110 gives the whole story of > Object#id and Object#object_id. As an example, ActiveRecord is > mentioned as using id for the database id which is completely > different from the object_id. > I hope that this is sufficiently official :-) > Thanks. I don't have that book, but that and the fact that Object#id is removed completely in Ruby 1.9 are good enough for me - unless anyone can think of a reason this is a bad idea. >> Not certain - we've just started work on 1.9.2. Given our current >> release cycle, I'd expect 3-6 weeks. If you're very eager, try SVN. I've >> recently checked in this change: >> >> http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb >> >> > > Thanks. I will try it. > In this case, you should be able just to copy the .rb file over the existing evthandler.rb without recompiling. > Just for my information, you replied in French to a post, are you french ? > No, I'm English, UK. I think my French would pretty quickly give me away ;) a From chauk.mean at gmail.com Tue Sep 18 04:47:58 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Tue, 18 Sep 2007 10:47:58 +0200 Subject: [wxruby-development] Re : syntax II In-Reply-To: <46EEF5D2.5030408@pressure.to> References: <46EE48DE.1010205@pressure.to> <46EEBF39.2060405@pressure.to> <46EEF5D2.5030408@pressure.to> Message-ID: 2007/9/17, Alex Fenton : > Chauk-Mean P wrote: > > 2007/9/17, Alex Fenton : > > > >> I don't have a strong view - I think I agree with you. Does anyone else > >> have a strong view? If you could point me to some "official" discussion > >> of the deprecation of Object#id and its availability for library/app > >> specific use I'd be convinced to make id mean Wx::Window#id. > >> > > > > The Ruby for Rails book (David A. Black) p110 gives the whole story of > > Object#id and Object#object_id. As an example, ActiveRecord is > > mentioned as using id for the database id which is completely > > different from the object_id. > > I hope that this is sufficiently official :-) > > > Thanks. I don't have that book, but that and the fact that Object#id is > removed completely in Ruby 1.9 are good enough for me - unless anyone > can think of a reason this is a bad idea. OK. That's great. > >> Not certain - we've just started work on 1.9.2. Given our current > >> release cycle, I'd expect 3-6 weeks. If you're very eager, try SVN. I've > >> recently checked in this change: > >> > >> http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb > > > > Thanks. I will try it. > > > In this case, you should be able just to copy the .rb file over the > existing evthandler.rb without recompiling. Yes. I've done that (late in the evening or early in the morning) and it works perfectly. Thanks again. > > Just for my information, you replied in French to a post, are you french ? > > > No, I'm English, UK. I think my French would pretty quickly give me away ;) > I noticed that your english was better than your french but I supposed that you left France a long time ago : - ). Now I understand the reason. A big cheer for the translation effort of your reply : - ) As far as I'm concerned and despite my uncommon first name, I'm french. Cheers. Chauk-Mean. From chauk.mean at gmail.com Wed Sep 19 17:23:39 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Wed, 19 Sep 2007 23:23:39 +0200 Subject: [wxruby-development] Re : syntax II In-Reply-To: <46EE48DE.1010205@pressure.to> References: <46EE48DE.1010205@pressure.to> Message-ID: 2007/9/17, Alex Fenton : > >>2) 'each' for list-like classes > >> > >>This one I'm less bothered about, but I fairly often want to loop over a > >>control with multiple items (eg Choice, ListCtrl, ListBox) to find or > >>alter a particular item. So for those classes I wonder if we should add > >>an 'each' method that passes in turn each valid index into the widget: > >> listbox.each { | i | set_item_text(i, item_text(i).upcase) } > >> > >> > >> > > Everything that makes wxRuby looks more Ruby is good. > > Nevertheless, I don't know if I will use this feature often. > > > The sense I'm getting is that this is a bit marginal. I find it useful > to locate the item which has an application object as item_data, when > that object is updated elsewhere, eg > > item_to_update = listbox.each { | i | break i if listbox.item_data(i) == > obj } > > But I think this can probably stay in wxSugar for now > Alex, It seems that your proposal is more useful than I first thought. Indeed, for a CheckListBox, there is no method for returning an array of indexes for the items that are checked. Such a method is similar as the 'selections' method (from ListBox) that returns an array of indexes for the items that are selected. Consequently, one must iterate over all item indexes of the CheckListBox and call 'checked?' to see if the item is checked or not. a) So an each method will ease the coding of such a 'checks' method b) Don't you think that such a 'checks' method is valuable for adding to the CheckListBox ? Cheers. Chauk-Mean. From chauk.mean at gmail.com Thu Sep 20 17:17:55 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Thu, 20 Sep 2007 23:17:55 +0200 Subject: [wxruby-development] Bug? in wxSugar enumerable_controls.rb Message-ID: Hi, I wanted to use wxSugar enumerable features to add a method for returning checked items' index to the CheckListBox class : require 'wx_sugar/version' require 'wx_sugar/wx_classes/control_with_items' require 'wx_sugar/wx_classes/listctrl' class Wx::CheckListBox def checked_items # use of find_all method from Enumerable items_index = find_all { |i| checked?(i) } end end The problem I had is that checked_items raises an exception. In fact, the find_all method uses the each method defined in 'wx_sugar/wx_classes/enumerable_controls.rb' as following : def each(&block) last = get_count - 1 case block.arity when 1 0.upto(last) { | i | yield i } when 2 0.upto(last) { | i | yield i, get_string(i) } when 3 0.upto(last) { | i | yield i, get_string(i), get_item_data(i) } else raise ArgumentError, "Invalid number of block parameters" end end This method works well if used directly. The problem is that methods from Enumerable like find_all, collect ... calls the each method providing a block with an arity of -1 ! (I'm running Ruby 1.8.5p12 on Win32). A workaround for this problem is to add -1 as an acceptable arity : ... when 1, -1 0.upto(last) { | i | yield i } ... Given the Pickaxe book, an arity of -1 for a block seems to be valid. So I don't know if it's a Ruby bug or a wxSugar bug. Any clarification is welcome. Cheers. Chauk-Mean. From chauk.mean at gmail.com Thu Sep 20 17:44:52 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Thu, 20 Sep 2007 23:44:52 +0200 Subject: [wxruby-development] Bug? in wxSugar enumerable_controls.rb In-Reply-To: References: Message-ID: 2007/9/20, Chauk-Mean P : > > Given the Pickaxe book, an arity of -1 for a block seems to be valid. > So I don't know if it's a Ruby bug or a wxSugar bug. > It is certainly a bug in wxSugar. An arity of -1 indicates a block that takes any number of arguments : lambda { | | }.arity # => 0 lambda { |i| }.arity # => 1 lambda { }.arity # => -1 lambda { |*n| }.arity # => -1 lambda { |i, *n| }.arity # => -2 Cheers, Chauk-Mean. From alex at pressure.to Thu Sep 20 17:46:28 2007 From: alex at pressure.to (Alex Fenton) Date: Thu, 20 Sep 2007 22:46:28 +0100 Subject: [wxruby-development] Bug? in wxSugar enumerable_controls.rb In-Reply-To: References: Message-ID: <46F2EA34.3040604@pressure.to> Chauk-Mean P wrote: > def each(&block) > last = get_count - 1 > case block.arity > when 1 > 0.upto(last) { | i | yield i } > when 2 > 0.upto(last) { | i | yield i, get_string(i) } > when 3 > 0.upto(last) { | i | yield i, get_string(i), get_item_data(i) } > else > raise ArgumentError, "Invalid number of block parameters" > end > end > > This method works well if used directly. > The problem is that methods from Enumerable like find_all, collect ... > calls the each method providing a block with an arity of -1 ! > (I'm running Ruby 1.8.5p12 on Win32). > Sounds like a wxSugar bug since -1 is a valid arity - although perhaps how Enumerable works has changed to show this up. Following recent discussions I'm inclined to think that an 'each' method is useful enough in list-like classes to make it worth adding to core so plan to do this for 1.9.2 (I see QtRuby has done something similar recently). But I think the current implementation is a bit over-elaborate, so I'll make it just pass a single block parameter in all cases, and let the user call get_string or get_item_data if desired. The implementation will be something like def each 0.upto(count - 1) { | i | yield i } end Thanks for the report &c cheers alex From chauk.mean at gmail.com Thu Sep 20 18:22:04 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Fri, 21 Sep 2007 00:22:04 +0200 Subject: [wxruby-development] Bug? in wxSugar enumerable_controls.rb In-Reply-To: <46F2EA34.3040604@pressure.to> References: <46F2EA34.3040604@pressure.to> Message-ID: 2007/9/20, Alex Fenton : > Following recent discussions I'm inclined to think that an 'each' method > is useful enough in list-like classes to make it worth adding to core so > plan to do this for 1.9.2 (I see QtRuby has done something similar > recently). That's great. > But I think the current implementation is a bit over-elaborate, so I'll > make it just pass a single block parameter in all cases, and let the > user call get_string or get_item_data if desired. The implementation > will be something like > > def each > 0.upto(count - 1) { | i | yield i } > end Simplicity is better :-) > Thanks for the report &c You're welcome. Cheers Chauk-Mean. From alex at pressure.to Wed Sep 26 05:06:17 2007 From: alex at pressure.to (Alex Fenton) Date: Wed, 26 Sep 2007 10:06:17 +0100 Subject: [wxruby-development] development status, 1.9.2 Message-ID: <46FA2109.9070603@pressure.to> Hi all Just a quick update on recent SVN activity: * added Sound and CollapsiblePane classes * added the XRC tool to wxSugar * fixed some XRC bugs in Window * added syntax sugar for event handlers and list-like controls * added some missing methods in Sizer Sean - I'm away for about 10 days from this weekend, and I'm thinking of doing a 1.9.2 release in the next day or two. Let me know what you think - if so, I'll look to tag and do the release on thursday, and we can trickle the builds on over the weekend. But not a problem to leave it I think as there aren't any critical bug fixes. Alex From chauk.mean at gmail.com Wed Sep 26 06:08:16 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Wed, 26 Sep 2007 12:08:16 +0200 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: <46FA2109.9070603@pressure.to> References: <46FA2109.9070603@pressure.to> Message-ID: 2007/9/26, Alex Fenton : > Hi all > > Just a quick update on recent SVN activity: > > * added Sound and CollapsiblePane classes > * added the XRC tool to wxSugar Will such a tool generate wxRuby code from an XRC file ? If this is the case, this is absolutely great. But why put it in wxSugar ? I thought that wxSugar is for syntatic sugar addition. > * added syntax sugar for event handlers and list-like controls Most (all ?) parts of wxSugar is now integrated in wxRuby (each, improved event handling). If I just want to use this XRC tool : - do I have to require wxSugar ? - will there be incompatibilities with deprecated wxSugar additions and my code that uses wxRuby new additions (each on ControlWithItems ...) ? Cheers. Chauk-Mean. PS : I don't forget to do my documentation contribution. From alex at pressure.to Wed Sep 26 06:29:28 2007 From: alex at pressure.to (Alex Fenton) Date: Wed, 26 Sep 2007 11:29:28 +0100 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: References: <46FA2109.9070603@pressure.to> Message-ID: <46FA3488.8020405@pressure.to> Chauk-Mean P wrote: > 2007/9/26, Alex Fenton : >> >> * added the XRC tool to wxSugar >> > > Will such a tool generate wxRuby code from an XRC file ? > Yes, it's a command-line tool that parses XRC and generates ruby classes with the initialisation code and accessor methods for the controls contained within the Frame/Dialog/Panel, possibly extending those with ruby Modules. Event handling can then be implemented in classes inheriting from these auto-generated classes. I'm finding it works really nicely and speeds development - I never used to use XRC but am now a convert. > But why put it in wxSugar ? > I thought that wxSugar is for syntatic sugar addition. > WxSugar is a testing place for extensions of various sorts. If the XRC tool is liked and stable, we can look at shipping it with core instead. The reason for not putting it in core wxRuby in the first place is that there's a reasonable guarantee that things added there will stay stable between releases. The tool needs a bit of testing and feedback before we know that. In practice, ideas first tried out in wxSugar (eg the event handling stuff) have been tweaked in the light of experience before being put in core. > Most (all ?) parts of wxSugar is now integrated in wxRuby (each, > improved event handling). If I just want to use this XRC tool : > - do I have to require wxSugar ? > No. The code generated is vanilla wxRuby, and doesn't depend on wxSugar. For the time being, you'll just need to install wxSugar to install the command-line tool ('xrcise'). Here's an example (from Weft QDA) of the generated code: http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/base.rb And an event-implementing class http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/inspectors/search.rb > - will there be incompatibilities with deprecated wxSugar additions > and my code that uses wxRuby new additions (each on ControlWithItems > ...) ? > We'll try to minimise it by gradually deprecating bits of wxSugar that are now in core, but it shouldn't be a problem, for the reasons above. cheers alex From chauk.mean at gmail.com Wed Sep 26 08:38:26 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Wed, 26 Sep 2007 14:38:26 +0200 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: <46FA3488.8020405@pressure.to> References: <46FA2109.9070603@pressure.to> <46FA3488.8020405@pressure.to> Message-ID: 2007/9/26, Alex Fenton : > Chauk-Mean P wrote: > > 2007/9/26, Alex Fenton : > >> > >> * added the XRC tool to wxSugar > >> > > > > Will such a tool generate wxRuby code from an XRC file ? > > > Yes, it's a command-line tool that parses XRC and generates ruby classes > with the initialisation code and accessor methods for the controls > contained within the Frame/Dialog/Panel, possibly extending those with > ruby Modules. Event handling can then be implemented in classes > inheriting from these auto-generated classes. I'm finding it works > really nicely and speeds development - I never used to use XRC but am > now a convert. > Here's an example (from Weft QDA) of the > generated code: > http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/base.rb > And an event-implementing class > http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/inspectors/search.rb I see. What I expected was the "real" wxRuby code corresponding to the XRC file and not only the initialization code for using the XRC file. I'm using wxFormBuilder which can produce both XRC and C++ code. The generated C++ code is the "real" C++ code corresponding to the GUI elements of the XRC file. I find it very useful to see the resulting C++ file but I really prefer seeing the wxRuby code. I also felt the need to ease the use of XRC file. But I was considering a more dynamic approach without code generation. Cheers. Chauk-Mean. From sean.m.long at gmail.com Thu Sep 27 02:54:15 2007 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 26 Sep 2007 23:54:15 -0700 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: <46FA2109.9070603@pressure.to> References: <46FA2109.9070603@pressure.to> Message-ID: > Sean - I'm away for about 10 days from this weekend, and I'm thinking of > doing a 1.9.2 release in the next day or two. Let me know what you think > - if so, I'll look to tag and do the release on thursday, and we can > trickle the builds on over the weekend. But not a problem to leave it I > think as there aren't any critical bug fixes. I'm fine with doing a release soon. Lately I have not had a chance to test any of the new features you have added, I hope to have a chance tomorrow. On a somewhat related note do you have a todo list you are working off of or are these fixes related to bugs/missing items you have come across? If you do have a list of some type can you throw it up on the wiki? Having a list might get me in gear to fix a few things. Thanks Sean From chauk.mean at gmail.com Thu Sep 27 04:04:52 2007 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Thu, 27 Sep 2007 10:04:52 +0200 Subject: [wxruby-development] Adding more sugar to wxSugar Message-ID: Hi all, New wxRuby event handling offers the choice between using blocks or methods seamlessly and easily. This is great respectively for simple app and more complex app. Nevertheless, currently the creation of an application, a frame, or a dialog is very tedious for simple app : - you need to create a subclass of Wx::App, Wx::Frame ... - you need to put the initialization code in the initialize method for Frame and Dialog - you need to call explicitly the main_loop on the app ... So I defined some sugar classes (I called them Candy :-) ) to ease the writing of simple app. The idea is to take a block for all the initialization code and to embed all other things (like calling the main_loop method for an app). class CandyApp < Wx::App attr_accessor :init_block def self.create &block # Create and run the application app = new app.init_block = block app.main_loop end def on_init instance_eval &init_block true end end class CandyFrame < Wx::Frame def self.create *args, &block frame = new args frame.instance_eval &block frame end def initialize args super *args end end Given these simple additional classes, the minimal app sample can be written like this : CandyApp.create do self.app_name = 'Minimal' frame = CandyFrame.create(nil, :title => "Minimal wxRuby App", :size => [ 400, 300 ]) do menu_file = Wx::Menu.new() menu_help = Wx::Menu.new() menu_help.append(Wx::ID_ABOUT, "&About...\tF1", "Show about dialog") menu_file.append(Wx::ID_EXIT, "E&xit\tAlt-X", "Quit this program") menu_bar = Wx::MenuBar.new() menu_bar.append(menu_file, "&File") menu_bar.append(menu_help, "&Help") set_menu_bar(menu_bar) create_status_bar(2) set_status_text("Welcome to wxRuby!") evt_menu Wx::ID_EXIT, :on_quit evt_menu Wx::ID_ABOUT, :on_about end frame.show end I find it very readable and less tedious to write (see the attached source files). What do you think about it ? This is only a proof of concept and I also intend to add support for XRC initialization for CandyDialog and CandyFrame. Cheers. Chauk-Mean. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minimal.rb Url: http://rubyforge.org/pipermail/wxruby-development/attachments/20070927/61862020/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxcandy.rb Url: http://rubyforge.org/pipermail/wxruby-development/attachments/20070927/61862020/attachment-0003.pl From mario at ruby-im.net Thu Sep 27 18:25:53 2007 From: mario at ruby-im.net (Mario Steele) Date: Thu, 27 Sep 2007 17:25:53 -0500 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: References: <46FA2109.9070603@pressure.to> <46FA3488.8020405@pressure.to> Message-ID: <46FC2DF1.10100@ruby-im.net> Chauk-Mean P wrote: > I see. > > What I expected was the "real" wxRuby code corresponding to the XRC > file and not only the initialization code for using the XRC file. > I'm using wxFormBuilder which can produce both XRC and C++ code. > The generated C++ code is the "real" C++ code corresponding to the GUI > elements of the XRC file. I find it very useful to see the resulting > C++ file but I really prefer seeing the wxRuby code. > > I also felt the need to ease the use of XRC file. But I was > considering a more dynamic approach without code generation. > > Cheers. > > Chauk-Mean. > Hello Chauk-Mean, The reason why the xrcise tool will only write a wrapper around the xrc file, is cause it's meant to do just that, write a wrapper, not generate the actual ruby code for the GUI being represented in the xrc file. That is actually better left to a IDE to generate the code. Which is what I'm going to be working on, once I get wxSocket impelemented. Creating a full fledged IDE, that will have Editor, and GUI Builder, for wxRuby. It'll be mainly geared towards wxRuby, but will allow you to write any Ruby code you want. Hopefully soon, I'll have something out for wxSocket, so that I can start work on wxRIDE, which will be in no way associated with FreeRIDE. L8ers, Mario Steele From mario at ruby-im.net Thu Sep 27 19:08:20 2007 From: mario at ruby-im.net (Mario Steele) Date: Thu, 27 Sep 2007 18:08:20 -0500 Subject: [wxruby-development] wxRuby Documentation / Textitle Docs Message-ID: <46FC37E4.1090101@ruby-im.net> Hey All, Just wanted to let you guys know, that with the HTML Generated documentation from the Textile source code, does not show *'s in stuff like Wx::FileDialog. It's interpreting this as a Bold, not as an Asterisk. Just thought you'd want to know that. L8ers, Mario Steele From sean.m.long at gmail.com Thu Sep 27 19:58:12 2007 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 27 Sep 2007 16:58:12 -0700 Subject: [wxruby-development] wxRuby Documentation / Textitle Docs In-Reply-To: <46FC37E4.1090101@ruby-im.net> References: <46FC37E4.1090101@ruby-im.net> Message-ID: Thanks for pointing that out Mario. It appears to start with (*,?) in the following paragraph: Both the X and Windows versions implement a wildcard filter. Typing a filename containing wildcards (*, ?) in the filename text item, and clicking on Ok, will result in only those files matching the pattern being displayed. The wildcard may be a specification for multiple types of file with a description for each, such as: "BMP and GIF files (*.bmp;*.gif)|*.bmp;*.gif|PNG files (*.png)|*.png" But when I paste this in to the online textile tool it works fine (http://textism.com/tools/textile/index.php) I wonder if it is a problem with RedCloth? Alex has done most of the work on the documentation, I have not used Textile all that much. Alex have any ideas? Sean On 9/27/07, Mario Steele wrote: > Hey All, > > Just wanted to let you guys know, that with the HTML Generated > documentation from the Textile source code, does not show *'s in stuff > like Wx::FileDialog. It's interpreting this as a Bold, not as an > Asterisk. Just thought you'd want to know that. > > L8ers, > Mario Steele > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > From mario at ruby-im.net Thu Sep 27 21:39:41 2007 From: mario at ruby-im.net (Mario Steele) Date: Thu, 27 Sep 2007 20:39:41 -0500 Subject: [wxruby-development] WxWizard Error Message-ID: <46FC5B5D.7050300@ruby-im.net> Hey All, Looks like there's a few bugs with the controls dealing with Wx::Wizard. I've gone through it a bit, and seems like there's some errors beyond what I could fix. An example is: # wxWizard A wizard dialog Wx::define_keyword_ctors('Wizard') do wx_ctor_params :title => '' wx_ctor_params :bitmap => Wx::NULL_BITMAP wx_ctor_params :pos, :size wx_ctor_params :style => Wx::DEFAULT_DIALOG_STYLE end After looking at the SWIG Generated Code, it looks like it generates the Director to only have the params: :title => '' :bitmap => Wx::NULL_BITMAP :pos There is no :size or :style. But after modifying keyword_defs.rb, it still errors out, with the following Error (Modified by myself): >ruby wizard.rb C:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.1-i386-mswin32/lib/wx/keyword_ctors.rb:202:in `initialize': (ArgumentError) Original Error No matching function for overloaded 'new_wxWizard' Error initializing # Sent parameters: [#, -1, "The WxRuby Wizard", #] Correct parameters are: title (String) bitmap (Wxruby2::Bitmap) pos (Wxruby2::Point) from wizard.rb:37:in `new' from wizard.rb:37:in `initialize' from wizard.rb:70:in `new' from wizard.rb:70:in `on_init' from wizard.rb:80:in `main_loop' from wizard.rb:80 >Exit code: 1 From reading this, it looks as though :bitmap is not being loaded into the mixed_args from the args_as_list method. In another example, I've fixed this problem, cause I have logo desginated, but it still errors out from another part of Wx::Wizard, which is Wx::SimpleWizardPage. >ruby RubyIM.rb C:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.1-i386-mswin32/lib/wx/keyword_ctors.rb:202:in `initialize': (ArgumentError) Original Error wrong # of arguments(5 for 0) Error initializing # Sent parameters: [#, -1, nil, nil, #] Correct parameters are: id (Fixnum) prev (NilClass) next (NilClass) bitmap (Wxruby2::Bitmap) from ./libs/Wizard.rb:7:in `new' from ./libs/Wizard.rb:7:in `initialize' from RubyIM.rb:36:in `new' from RubyIM.rb:36:in `on_init' from RubyIM.rb:41:in `main_loop' from RubyIM.rb:41 >Exit code: 1 Which by both Documentation, and by SWIG Source Code, shows that there is no ID Associated with this control type. Seems a bit funky, if you ask me. Thought I would pass this along to you guys, Mario Steele From alex at pressure.to Fri Sep 28 06:52:44 2007 From: alex at pressure.to (Alex Fenton) Date: Fri, 28 Sep 2007 11:52:44 +0100 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: References: <46FA2109.9070603@pressure.to> Message-ID: <46FCDCFC.6060903@pressure.to> Sean Long wrote: > I'm fine with doing a release soon. Lately I have not had a chance to > test any of the new features you have added, I hope to have a chance > tomorrow. > Thanks. I got swamped with work so haven't had time to do any pre-release testing esp on MSW. If it's OK with you, let's look to do a release week after next (c 8 Oct) when I'm back. > On a somewhat related note do you have a todo list you are working off > of or are these fixes related to bugs/missing items you have come > across? If you do have a list of some type can you throw it up on the > wiki? I've been a bit haphazard, sorry - it's mainly been stuff thrown up by doing my own development on Weft (eg probs with XRC and Window methods), and by integrating the syntax additions (eg Menu#insert return values). If I've spotted odd useful GUI classes that are easy to add, I've tried to do those too. Happily, I don't think we have masses left to do for a reasonable 2.0. Roughly speaking: * The bug list. Erk. The most serious I think are crashes on exit in the activation sample, which seems to be down to Wx posting events to dead windows. * Tidy up some of the messier samples, provide more "new" syntax examples, and include some classes that aren't there at the mo * Need to look into GC marking client_data in ruby (not C++) subclasses of Wx::CommandEvent * At the moment, there are lots of virtual methods in Window which generate a lot of seemingly useless director methods in all subclasses (eg GetScrollThumb). I want to see if we can reduce bloat by nodirector-ing these. * It'd be good to experiment with taking %trackobjects off Point and Size and treating them as throwaway objects (eg creating a new memory management strategy GC_MANAGE_AS_FUNGIBLE_OBJECT). I think this might improve performance slightly both on object creation and at GC phase. * I have an new rakefile which does more accurate dependency handling (eg of swig/shared files), but need to ensure it works on Windows and OS X as well before I check it in. That's about it ... plus anything else you'd like to see tweaked or fixed ... will probably not be looking at emails much for the next week or so. cheers alex From alex at pressure.to Fri Sep 28 06:55:29 2007 From: alex at pressure.to (Alex Fenton) Date: Fri, 28 Sep 2007 11:55:29 +0100 Subject: [wxruby-development] Adding more sugar to wxSugar In-Reply-To: References: Message-ID: <46FCDDA1.6020104@pressure.to> Chauk-Mean P wrote: > So I defined some sugar classes (I called them Candy :-) ) to ease the > writing of simple app. The idea is to take a block for all the > initialization code and to embed all other things (like calling the > main_loop method for an app). This looks pretty neat, thanks, haven't had a chance to play with it. Having the standard initializers for Windows (and perhaps App) yield to a block seems easy and rubyish and backwards-compatible. I'll look at this further when back cheers alex From alex at pressure.to Fri Sep 28 06:57:22 2007 From: alex at pressure.to (Alex Fenton) Date: Fri, 28 Sep 2007 11:57:22 +0100 Subject: [wxruby-development] WxWizard Error In-Reply-To: <46FC5B5D.7050300@ruby-im.net> References: <46FC5B5D.7050300@ruby-im.net> Message-ID: <46FCDE12.30504@pressure.to> Mario Steele wrote: > Hey All, > > Looks like there's a few bugs with the controls dealing with > Wx::Wizard. I've gone through it a bit, and seems like there's some > errors beyond what I could fix. > Hehe, I think both keyword_defs and the current real C++ parameters (from swig/classes/include/wxWizard.h) are wrong in that they don't line up with the current Wx 2.8 docs. These suggest that the ctor should have a position argument, but not a size one, with an optional style argument at the end. Thanks for the report - shouldn't be too hard to fix this up alex From alex at pressure.to Fri Sep 28 07:00:10 2007 From: alex at pressure.to (Alex Fenton) Date: Fri, 28 Sep 2007 12:00:10 +0100 Subject: [wxruby-development] development status, 1.9.2 In-Reply-To: References: <46FA2109.9070603@pressure.to> <46FA3488.8020405@pressure.to> Message-ID: <46FCDEBA.7050605@pressure.to> Chauk-Mean P wrote: > What I expected was the "real" wxRuby code corresponding to the XRC > file and not only the initialization code for using the XRC file. I agree this is nicer, and quite do-able - just a bit more tricky to implement. However it should be possible to use the class-ctor information in lib/wx/keywords_defs.rb to figure out the correct way to initialize anything that's in an XRC file. It would be a step towards fuller IDE integration, but at the level we're at, "real" ruby code probably isn't any more practically useful than writing the boilerplate XRC-loading code... cheers alex From alex at pressure.to Fri Sep 28 07:07:21 2007 From: alex at pressure.to (Alex Fenton) Date: Fri, 28 Sep 2007 12:07:21 +0100 Subject: [wxruby-development] wxRuby Documentation / Textitle Docs In-Reply-To: References: <46FC37E4.1090101@ruby-im.net> Message-ID: <46FCE069.1060404@pressure.to> Sean Long wrote: > But when I paste this in to the online textile tool it works fine > (http://textism.com/tools/textile/index.php) > > I wonder if it is a problem with RedCloth? Alex has done most of the > work on the documentation, I have not used Textile all that much > Thanks Mario, Sean. I think there a few bugs in RedCloth's implementation of Textile, annoyingly. As another example, the Textile online tester interprets a line with a space followed by a # character as literal text, eg when you want to write code with a comment # this form of event handler is also allowed: evt_foo my_widget, :on_foo But RedCloth parses the # as a numbered-list member. As a stopgap, ==symbol== is Textile "escape" syntax for avoiding special processing of formatting chars. I'm open to better formats for the docs, but when we last looked, the alternatives we considered (DocBook, rdoc) all had disadvantages. alex From noreply at rubyforge.org Sat Sep 29 10:48:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 29 Sep 2007 10:48:15 -0400 (EDT) Subject: [wxruby-development] [ wxruby-Bugs-14322 ] Multiple warnings, especially @__painting__ Message-ID: <20070929144815.9C8AB5240AD2@rubyforge.org> Bugs item #14322, was opened at 2007-09-29 10:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=14322&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Multiple warnings, especially @__painting__ Initial Comment: Hi, I'm drawing with "paint" outside the normal evt_paint with the following code (just as example) in a subclass of Wx::Panel: paint do |dc| dc.draw_circle( ... ) end With this I get multiple "warning: instance variable @__painting__ not initialized" warnings for each paint call. Because they are displayed on every draw event, developing with ruby -w is very hard. It would be nice if this could be fixed. There are also some other warnings during the startup. But as they are only displayed once they aren't such a big problem: .../ruby/gems/1.8/gems/wxruby-1.9.1-powerpc-darwin8.3.0/lib/wx/classes/app.rb:10: warning: method redefined; discarding old on_assert_failure .../ruby/gems/1.8/gems/wxruby-1.9.1-powerpc-darwin8.3.0/lib/wx/classes/clientdc.rb:8: warning: method redefined; discarding old initialize .../ruby/gems/1.8/gems/wxruby-1.9.1-powerpc-darwin8.3.0/lib/wx/classes/paintdc.rb:7: warning: method redefined; discarding old initialize .../ruby/gems/1.8/gems/wxruby-1.9.1-powerpc-darwin8.3.0/lib/wx/keyword_ctors.rb:214: warning: instance variable @param_flags not initialized I'm using it on Mac OS X 10.4.10 with ruby 1.8.6 compiled with macports and wxRuby 1.9.1 installed with gems as binary gem. Thanks for your help. Aside this bugs I want to they thank you for your great work. I like wxRuby very much and use it very often. It's easy and simple to use. Thanks, Simon (simon at ruderich dot com) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=14322&group_id=35 From mario at ruby-im.net Sun Sep 30 02:13:11 2007 From: mario at ruby-im.net (Mario Steele) Date: Sun, 30 Sep 2007 01:13:11 -0500 Subject: [wxruby-development] Cross-Platform Development.... Message-ID: <46FF3E77.8020100@ruby-im.net> Hello All, I figured this would be a great place in which to post this. I've recently found a program which is a dream cake of mine. I've had been looking for an easier way in which to do cross-platform development, and general administration through Graphical means to utilize a Linux System. Up until recently, I have been working with VNC as a means in which to gain access to my 800 MHz development box which runs Ubuntu Linux. I recently ran across NX (No Machine), which does Remote Administration through GUI similar to VNC, but in a more responsive, and secure way. NX runs through SSH, but that's just the security aspect of this nice little app. It does way far more. One of which, is the ability to run a full blown Desktop, like KDE, Gnome, XFCE4, or whatever your faviorate Window manager is. But not only that, it actually allows you to run Linux Applications from your box, on your Windows Computer. An example of that, is a screen shot here: http://www.trilake.net/ss_xfce4_term_on_windows.jpg which shows XFCE4's Terminal program running on my Windows Computer. And as you can notice, I have shortcuts on my desktop for XFCE4 (The Desktop System), XMMS, and XFCE4 Terminal. It's a very nice program, and you can check it out here: http://www.nomachine.com They have both a Free Version and a Paid version. The only problem I ran into, was a small problem with the Windows Client not connecting. If you want to get this running with your Windows Client, and run into a problem not connecting, send me an email, and I'll be happy to help you out. L8ers All, Mario Steele