From zdennis at mktec.com Thu Dec 2 21:34:15 2004 From: zdennis at mktec.com (Zach Dennis) Date: Thu Dec 2 21:33:45 2004 Subject: [Wxruby-users] Testing Printing In-Reply-To: <41A9EBB6.9050107@qualitycode.com> References: <41A559E7.60504@mktec.com> <41A9649D.2030407@mktec.com> <41A9EBB6.9050107@qualitycode.com> Message-ID: <41AFD0A7.2080408@mktec.com> I haven't been able to my Printing additions to wxRuby because I can't get my OSX (10.2.8) box to connect to my Windows shared printer. I also dont' have this working on my *Nix box either, but I think I can get this one going. Anyone out there w/a Mac and a printer willing to test my additions before I send them to Nick for review? Thanks, Zach From devel at nicreations.com Fri Dec 3 08:50:32 2004 From: devel at nicreations.com (Nick) Date: Fri Dec 3 08:52:34 2004 Subject: [Wxruby-users] Testing Printing In-Reply-To: <41AFD0A7.2080408@mktec.com> References: <41A559E7.60504@mktec.com> <41A9649D.2030407@mktec.com> <41A9EBB6.9050107@qualitycode.com> <41AFD0A7.2080408@mktec.com> Message-ID: <41B06F28.8090500@nicreations.com> I've got a Mac with a network printer you can try. Nick Zach Dennis wrote: > I haven't been able to my Printing additions to wxRuby because I can't > get my OSX (10.2.8) box to connect to my Windows shared printer. > > I also dont' have this working on my *Nix box either, but I think I can > get this one going. > > Anyone out there w/a Mac and a printer willing to test my additions > before I send them to Nick for review? > > Thanks, > > Zach > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sdate at everestkc.net Thu Dec 9 23:40:53 2004 From: sdate at everestkc.net (Shashank Date) Date: Thu Dec 9 23:39:51 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid Message-ID: <41B928D5.6050506@everestkc.net> Hi, Thanks to the newly added event handlers for Wx::Grid in the 0.6.0 release, I can now provide a much slicker intreface to my "data widgets" which heavily rely on that control. However, I haven't quite figured out how to programmatically scroll to the last row of a populated grid (actually, the first empty row). So say that I have a grid with 200 rows only 20 of which are visible at any given time. If say 80 of these rows are currently populated with some data and the top 20 are being viewed. Now, I have to provide "Add" functionality via a button which when clicked, the grid should scroll to the 81st row so that it comes in the view (say towards the top). How do I go about doing that? I tried grid.set_scroll_y( ) but it did not seem to work. Then I tried grid.move_page_down() which worked, but I could not figure out how to know when to stop. Any ideas? -- shanko From devel at nicreations.com Fri Dec 10 07:38:19 2004 From: devel at nicreations.com (Nick) Date: Fri Dec 10 07:39:32 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <41B928D5.6050506@everestkc.net> References: <41B928D5.6050506@everestkc.net> Message-ID: <41B998BB.4070700@nicreations.com> Hi Shanko, wxGrid inherits from wxScrolledWindow, so try the "scroll" method. Nick Shashank Date wrote: > Hi, > > Thanks to the newly added event handlers for Wx::Grid in the 0.6.0 > release, I can now provide a much slicker intreface to my "data widgets" > which heavily rely on that control. > However, I haven't quite figured out how to programmatically scroll to > the last row of a populated grid (actually, the first empty row). So > say that I have a grid with 200 rows only 20 of which are visible at any > given time. If say 80 of these rows are currently populated with some > data and the top 20 are being viewed. Now, I have to provide "Add" > functionality via a button which when clicked, the grid should scroll to > the 81st row so that it comes in the view (say towards the top). How do > I go about doing that? > > I tried grid.set_scroll_y( ) but it did not seem to work. Then I tried > grid.move_page_down() which worked, but I could not figure out how to > know when to stop. > > Any ideas? > -- shanko > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sdate at everestkc.net Fri Dec 10 07:59:56 2004 From: sdate at everestkc.net (Shashank Date) Date: Fri Dec 10 07:58:50 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <41B998BB.4070700@nicreations.com> References: <41B928D5.6050506@everestkc.net> <41B998BB.4070700@nicreations.com> Message-ID: <41B99DCC.6080807@everestkc.net> Nick wrote: > Hi Shanko, > > wxGrid inherits from wxScrolledWindow, so try the "scroll" method. Thanks, Nick. I will work in that direction. Like I said earlier, I haven't figured out how to know how much to scroll. Of course, I can always find out how many rows are populated , multiply that by the size in pixels of each row, convert the pixels into scroll units and then scroll those many units. But that is too much of work ;-) I was wondering if there is a smarter way of doing this. Thanks again, -- shanko From wxruby at qualitycode.com Fri Dec 10 09:38:54 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri Dec 10 09:37:52 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <41B99DCC.6080807@everestkc.net> References: <41B928D5.6050506@everestkc.net> <41B998BB.4070700@nicreations.com> <41B99DCC.6080807@everestkc.net> Message-ID: <1102689534.23854.361.camel@localhost> On Fri, 2004-12-10 at 06:59 -0600, Shashank Date wrote: > Thanks, Nick. I will work in that direction. Like I said earlier, I > haven't figured out how to know how much to scroll. > Of course, I can always find out how many rows are populated , multiply > that by the size in pixels of each row, convert the pixels into scroll > units and then scroll those many units. But that is too much of work ;-) And it may not work. At least the way I read the wxGrid docs, each row could be a different size, so you would have to loop through, adding up each row's height. Another crude approach might be to call move_cursor_down once for each row you want to scroll by. But hopefully you won't need do do that, because... > I was wondering if there is a smarter way of doing this. Just looking at the wxWindows docs (not at wxRuby itself), it looks like you want wxGrid::CellToRect. Given a cell (row/col), it should return the logical X/Y position, which you could pass to scroll(x,y) [inherited from ScrolledWindow], or set_scroll_y (if it works), or at worst, to know when to stop calling move_page_down. Kevin From sdate at everestkc.net Sat Dec 11 23:38:46 2004 From: sdate at everestkc.net (Shashank Date) Date: Sat Dec 11 23:37:42 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <1102689534.23854.361.camel@localhost> References: <41B928D5.6050506@everestkc.net> <41B998BB.4070700@nicreations.com> <41B99DCC.6080807@everestkc.net> <1102689534.23854.361.camel@localhost> Message-ID: <41BBCB56.4010002@everestkc.net> Hi, Kevin Smith wrote: >Another crude approach might be to call move_cursor_down once for each >row you want to scroll by. > That approach, although crude, worked like a charm. Since none of the grids I am having are larger than few hundred rows, it is OK for now. >But hopefully you won't need do do that, >because... > > > >>I was wondering if there is a smarter way of doing this. >> >> > >Just looking at the wxWindows docs (not at wxRuby itself), it looks like >you want wxGrid::CellToRect. Given a cell (row/col), it should return >the logical X/Y position, which you could pass to scroll(x,y) [inherited >from ScrolledWindow], or set_scroll_y (if it works), or at worst, to >know when to stop calling move_page_down. > > I could not get it to work. I could be missing something. See example below (modified grid sample with the non-working code commented out). I am on Win XP (Home) using the latest one-click installer and wxRuby 0.6.0 Thanks, Kevin. >Kevin > > -- shanko ################################################################# require 'wxruby' class MyFrame < Wx::Frame def initialize(parent, id = -1, title = "MyFrame", pos = Wx::DEFAULT_POSITION, size = Wx::DEFAULT_SIZE, style = Wx::DEFAULT_FRAME_STYLE) super(parent, id, title, pos, size, style) create_status_bar() set_status_text(Wx::VERSION_STRING) panel = Wx::Panel.new(self) btn = Wx::Button.new(panel, :btn.id, "Add", Wx::Point.new(10, 300),Wx::Size.new(50,30)) evt_button(:btn.id){|event| on_button_add(event)} make_grid(panel) populate_grid() evt_grid_cell_left_click() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} is clicked") evt.skip end evt_grid_cell_right_click() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} is right clicked") evt.skip end evt_grid_cell_left_dclick() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} is double clicked") evt.skip end evt_grid_cell_right_dclick() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} is right double clicked") evt.skip end evt_grid_label_left_click() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} label is clicked") evt.skip end evt_grid_label_right_click() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} label is right clicked") evt.skip end evt_grid_label_left_dclick() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} labelis double clicked") evt.skip end evt_grid_label_right_dclick() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} label is right double clicked") evt.skip end evt_grid_select_cell() do |evt| set_status_text("#{evt.get_row} x #{evt.get_col} cell is selected") evt.skip end evt_grid_row_size do |evt| set_status_text("Row #{evt.get_row_or_col} size changed") evt.skip end evt_grid_col_size do |evt| set_status_text("Column #{evt.get_row_or_col} size changed") evt.skip end evt_grid_editor_shown do |evt| set_status_text("Begin editing") evt.skip end evt_grid_editor_hidden do |evt| set_status_text("End editing") evt.skip end evt_grid_range_select do |evt| top = evt.get_top_left_coords bottom = evt.get_bottom_right_coords set_status_text("[ #{top[0].to_s} x #{top[1].to_s} ] to [ #{bottom[0].to_s} x #{bottom[1].to_s} ] is selected") end evt_grid_editor_created do |evt| set_status_text("Control #{evt.get_control} created") evt.skip end evt_grid_cell_change() do |evt| set_status_text("Cell #{evt.get_row} x #{evt.get_col} has changed") end end def on_button_add(event) @grid.set_grid_cursor(0,0) @grid.get_number_rows.times{|i| val = @grid.get_cell_value(i,0) @grid.move_cursor_down(false) if val.to_s.length > 0 } # rect=@grid.cell_to_rect(10,1) # x,y = rect.x, rect.y # @grid.scroll(x,y) # # row = @grid.y_to_row(y) # col = @grid.x_to_col(x) # # Wx::message_box("(#{x},#{y}) (#{row},#{col})","(x,y) (row,col)") rescue Wx::message_box($!.to_s,"add") end def make_grid(panel) # Create a wxGrid object @grid = Wx::Grid.new(panel, :grid.id, Wx::Point.new(10,10), Wx::Size.new(925,275)) # Then we call CreateGrid to set the dimensions of the grid # (11 rows and 12 columns in this example) @grid.create_grid( 51, 12 ) # We can set the sizes of individual rows and columns # in pixels, and the label value string @grid.set_row_size( 1, 40 ) @grid.set_row_size( 9, 30 ) @grid.set_row_label_value( 0, "Row1" ) @grid.set_row_label_alignment(Wx::ALIGN_CENTRE, Wx::ALIGN_CENTRE) @grid.set_col_size( 0, 120 ) @grid.set_col_label_value( 0, "Col1" ) @grid.set_col_label_alignment(Wx::ALIGN_CENTRE, Wx::ALIGN_CENTRE) # And set grid cell contents as strings @grid.set_cell_value( 0, 0, "wxGrid is good" ) # We can specify that some cells are read-only @grid.set_cell_value( 0, 3, "This is read-only" ) @grid.set_read_only( 0, 3 ) # Colours can be specified for grid cell contents @grid.set_cell_value(3, 3, "white on black") @grid.set_cell_text_colour(3, 3, Wx::WHITE) @grid.set_cell_background_colour(3, 3, Wx::BLACK) # We can specify the some cells will store numeric # values rather than strings. Here we set grid column 5 # to hold floating point values displayed with width # of 6 and precision of 2 @grid.set_col_format_float(5, 6, 2) @grid.set_cell_value(0, 6, "3.1415") end def populate_grid() %w{one two three four five six seven eight nine ten eleven twelve}.each_with_index do|val,i| @grid.set_cell_value( i, 0, val) end end end class MyApp < Wx::App def on_init frame = MyFrame.new(nil, -1, "Grid Sample", Wx::Point.new(10, 100), Wx::Size.new(1000,400)) frame.show(TRUE) set_top_window(frame) end end app = MyApp.new app.main_loop() -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20041211/7ede6462/attachment-0001.htm From devel at nicreations.com Sun Dec 12 12:38:45 2004 From: devel at nicreations.com (Nick) Date: Sun Dec 12 12:39:54 2004 Subject: [Wxruby-users] Re: Problem building wxRuby: htmlproc.h not found In-Reply-To: <41bc544b$0$29842$9b4e6d93@newsread2.arcor-online.net> References: <41bc544b$0$29842$9b4e6d93@newsread2.arcor-online.net> Message-ID: <41BC8225.4020702@nicreations.com> I've heard of this before. Try running this line and send me the output ruby -e "p RUBY_PLATFORM" Nick Andreas Schwarz wrote: > I'm trying to build wxRuby 6.0 on Linux (Ubuntu). When I run make I get > an error because htmlproc.h is not found (it does not exist in the Linux > version of wxWidgets). I see that the html* object files are removed > from $objs in the extconf.rb if /linux/ =~ RUBY_PLATFORM, but still the > Makefile tries to build them. > > $ ruby -v > ruby 1.8.2 (2004-08-24) [i386-linux] > $ wx-config --version > 2.4.2 > > > > From assaph at gmail.com Sun Dec 12 18:01:20 2004 From: assaph at gmail.com (Assaph Mehr) Date: Sun Dec 12 18:00:08 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <41BBCB56.4010002@everestkc.net> References: <41B928D5.6050506@everestkc.net> <41B998BB.4070700@nicreations.com> <41B99DCC.6080807@everestkc.net> <1102689534.23854.361.camel@localhost> <41BBCB56.4010002@everestkc.net> Message-ID: <3ff47be904121215011a55ab45@mail.gmail.com> On Sat, 11 Dec 2004 22:38:46 -0600, Shashank Date wrote: > I could not get it to work. I could be missing > something. See example below (modified grid sample > with the non-working code commented out). > > I am on Win XP (Home) using the latest one-click installer and wxRuby > 0.6.0 [snip] > def on_button_add(event) > > @grid.set_grid_cursor(0,0) > > @grid.get_number_rows.times{|i| > val = @grid.get_cell_value(i,0) > @grid.move_cursor_down(false) if val.to_s.length > 0 > } > > # rect=@grid.cell_to_rect(10,1) > # x,y = rect.x, rect.y > # @grid.scroll(x,y) > # > # row = @grid.y_to_row(y) > # col = @grid.x_to_col(x) > # It shoud be simply: @grid.move_cursor_down_block(false) # move to last cell that has content @grid.move_cursor_down(false) # move one row down If you know the cell you want to move to (and not just the last cell with content) use: @grid.set_grid_cursor row, col @grid.scroll col, row Notice that the parameters to #scroll and #set_grid_cursor are inverted. Both are zero-based. I didn't see #scroll in the docs, but it recieves the number of of the col and row, not the screen parameters. It will position itself so that the cell is at the bottom of the screen. You can also use; @grid.make_cell_visible col, row which will place the visible cell 3 rows from the bottom. Works for me on WinXP, wxRuby 0.6. Cheers, Assaph From devel at nicreations.com Sun Dec 12 20:00:32 2004 From: devel at nicreations.com (Nick) Date: Sun Dec 12 20:01:36 2004 Subject: [Wxruby-users] Re: Problem building wxRuby: htmlproc.h not found In-Reply-To: <41bca36b$0$16046$9b4e6d93@newsread4.arcor-online.net> References: <41bc544b$0$29842$9b4e6d93@newsread2.arcor-online.net> <41BC8225.4020702@nicreations.com> <41bca36b$0$16046$9b4e6d93@newsread4.arcor-online.net> Message-ID: <41BCE9B0.8060602@nicreations.com> It's possible the depends file has references to it. My linux box bit the big one, but I'll look into it. Nick Andreas Schwarz wrote: > Nick wrote: > >> >> I've heard of this before. Try running this line and send me the output >> >> ruby -e "p RUBY_PLATFORM" > > > I don't have access to the system at the moment, but I know that /linux/ > =~ RUBY_PLATFORM is true. I put some debug statements in the extconf.rb > to make sure that the html* objects are removed from $objs, and they were. > > > > From zdennis at mktec.com Sun Dec 12 22:15:39 2004 From: zdennis at mktec.com (Zach Dennis) Date: Sun Dec 12 22:17:41 2004 Subject: [Wxruby-users] Re: Problem building wxRuby: htmlproc.h not found In-Reply-To: <41BC8225.4020702@nicreations.com> References: <41bc544b$0$29842$9b4e6d93@newsread2.arcor-online.net> <41BC8225.4020702@nicreations.com> Message-ID: <41BD095B.7000803@mktec.com> Nick wrote: > > I've heard of this before. Try running this line and send me the output > > ruby -e "p RUBY_PLATFORM" > > Nick > > > Andreas Schwarz wrote: > >> I'm trying to build wxRuby 6.0 on Linux (Ubuntu). When I run make I >> get an error because htmlproc.h is not found (it does not exist in the >> Linux version of wxWidgets). I see that the html* object files are >> removed from $objs in the extconf.rb if /linux/ =~ RUBY_PLATFORM, but >> still the Makefile tries to build them. >> >> $ ruby -v >> ruby 1.8.2 (2004-08-24) [i386-linux] >> $ wx-config --version >> 2.4.2 I've had this problem on my Windows box, but I do not have this problem on my linux box. I have the same setup and I do not get the same problem with wxRuby 0.6.0 on my Debian box. I am also using wxWindows 2.4.2. 1 - My html*.h files are in my /usr/include/wx/html directory. Are they in yours? If not, if you do a find, where are they located, and is that path in your extconf.rb file? (Looking for path discrepanices here) 2- Do you get anything to compile or does it fail on the html*.h files right off the start? 3- Do you have wxWindows src? and not just devel tools. I know w/Debian there are a few different wxWindows packages available... Zach From devel at nicreations.com Sun Dec 12 22:44:12 2004 From: devel at nicreations.com (Nick) Date: Sun Dec 12 22:45:17 2004 Subject: [Wxruby-users] Re: Problem building wxRuby: htmlproc.h not found In-Reply-To: <41BD095B.7000803@mktec.com> References: <41bc544b$0$29842$9b4e6d93@newsread2.arcor-online.net> <41BC8225.4020702@nicreations.com> <41BD095B.7000803@mktec.com> Message-ID: <41BD100C.3000200@nicreations.com> Zach, The default wxGTK 2.4.2 doesn't include one of the HTML files (by accident). It's the whole reason we need to remove the functionality for linux. Nick Zach Dennis wrote: > Nick wrote: > >> >> I've heard of this before. Try running this line and send me the output >> >> ruby -e "p RUBY_PLATFORM" >> >> Nick >> >> >> Andreas Schwarz wrote: >> >>> I'm trying to build wxRuby 6.0 on Linux (Ubuntu). When I run make I >>> get an error because htmlproc.h is not found (it does not exist in >>> the Linux version of wxWidgets). I see that the html* object files >>> are removed from $objs in the extconf.rb if /linux/ =~ RUBY_PLATFORM, >>> but still the Makefile tries to build them. >>> >>> $ ruby -v >>> ruby 1.8.2 (2004-08-24) [i386-linux] >>> $ wx-config --version >>> 2.4.2 > > > I've had this problem on my Windows box, but I do not have this problem > on my linux box. I have the same setup and I do not get the same problem > with wxRuby 0.6.0 on my Debian box. I am also using wxWindows 2.4.2. > > 1 - My html*.h files are in my /usr/include/wx/html directory. Are they > in yours? If not, if you do a find, where are they located, and is that > path in your extconf.rb file? (Looking for path discrepanices here) > > 2- Do you get anything to compile or does it fail on the html*.h files > right off the start? > > 3- Do you have wxWindows src? and not just devel tools. I know w/Debian > there are a few different wxWindows packages available... > > Zach > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sdate at everestkc.net Sun Dec 12 23:44:45 2004 From: sdate at everestkc.net (Shashank Date) Date: Sun Dec 12 23:43:42 2004 Subject: [Wxruby-users] Scrolling to the bottom of a Grid In-Reply-To: <3ff47be904121215011a55ab45@mail.gmail.com> References: <41B928D5.6050506@everestkc.net> <41B998BB.4070700@nicreations.com> <41B99DCC.6080807@everestkc.net> <1102689534.23854.361.camel@localhost> <41BBCB56.4010002@everestkc.net> <3ff47be904121215011a55ab45@mail.gmail.com> Message-ID: <41BD1E3D.5040908@everestkc.net> Hi Assaph, > >It shoud be simply: > @grid.move_cursor_down_block(false) # move to last cell that has content > @grid.move_cursor_down(false) # move one row down > > That worked perfectly! >If you know the cell you want to move to (and not just the last cell >with content) use: > @grid.set_grid_cursor row, col > @grid.scroll col, row > > Oh, and I was passing (x,y) values to scroll instead of (col,row). That worked too ... >I didn't see #scroll in the docs, but it recieves the number of of the >col and row, not the screen parameters. It will position itself so >that the cell is at the bottom of the screen. > > I always refer to the wxWindows documentation if I don't find it in wxRuby docs. I guess the wxWindows docs has this wrong then ... or is it one of those places where wxRuby is different from wxWindows? >You can also use; > @grid.make_cell_visible col, row > > Ah ha ! That worked too ... >which will place the visible cell 3 rows from the bottom. >Works for me on WinXP, wxRuby 0.6. > > Thanks Assaph for offering so many ways to do so many different things. >Cheers, >Assaph > > -- shanko From devel at nicreations.com Tue Dec 14 09:51:51 2004 From: devel at nicreations.com (Nick) Date: Tue Dec 14 09:52:59 2004 Subject: [Wxruby-users] wxRuby and other GUI toolkits Message-ID: <41BEFE07.5080304@nicreations.com> So, having subscribed recently to the ruby-talk mailing list, I've noticed that wxruby doesn't seem to have the "respect" of other GUI libraries. I know GUI-library preference is a holy war almost up there with vi versus emacs, but since I'm a wxruby developer, I'd like to know what people "don't" like about wxruby. Otherwise, how else do we improve? Browsing online, I've found a few complaints: Difficulty in getting it installed - Daniel Sheppard, http://www.jroller.com/page/soxbox/ Use of ugly integer values for event handlers - http://homepages.ihug.com.au/~naseby/31.html It's a good start (though I don't know what platform Mr. Sheppard is trying to install on), but any other discussion would be most helpful. Thanks, Nick From zdennis at mktec.com Tue Dec 14 10:22:20 2004 From: zdennis at mktec.com (Zach Dennis) Date: Tue Dec 14 10:21:21 2004 Subject: [Wxruby-users] wxRuby and other GUI toolkits In-Reply-To: <41BEFE07.5080304@nicreations.com> References: <41BEFE07.5080304@nicreations.com> Message-ID: <41BF052C.7050309@mktec.com> I like wxRuby and here are the pitfalls I think it has: - documentation is not up to date. it is missing classes, methods, etc... that are implemented, but aren't in the API, see http://wxruby.rubyforge.org/wxrubydoc.html - the Widgets Supported page is out of date, see http://wxruby.rubyforge.org/wiki/wiki.pl?Widgets_Supported Last night on IRC, i asked a few questions in general about using the different Gui toolkits that are available for ruby, and some folks said that in general: - they don't like referring to c++ documentation. - they have an impression that wxRuby is still real young - they are waiting for wxRuby to support all widgets Zach From wxruby at qualitycode.com Tue Dec 14 10:58:17 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue Dec 14 10:57:05 2004 Subject: [Wxruby-users] wxRuby and other GUI toolkits In-Reply-To: <41BF052C.7050309@mktec.com> References: <41BEFE07.5080304@nicreations.com> <41BF052C.7050309@mktec.com> Message-ID: <41BF0D99.5030402@qualitycode.com> Zach Dennis wrote: > > - they don't like referring to c++ documentation. > - they have an impression that wxRuby is still real young > - they are waiting for wxRuby to support all widgets Personally, I think those are the biggest drawbacks of wxruby right now. Basically, it's "not done yet". After we get to the point where all the widgets are supported, and there are no big bugs (like crashes or memory leaks), and everything is easy to install and well documented, then we will face the next big drawback: Parts of the API are clunky and non-ruby-like. That can be fixed with wrappers, or where necessary, non-compatible changes in the API. The final challenge will be any negative aspects of wxWindows itself that are difficult or impossible to wrap or hide. Hopefully there won't be too many of those, but I suspect there will be some. On the bright side, wx is still the only liberally-licensed, full-featured, native-widget, cross-platform GUI toolkit. If those features are important to you, then wx is really where you want to be. Kevin From zdennis at mktec.com Tue Dec 14 11:17:37 2004 From: zdennis at mktec.com (Zach Dennis) Date: Tue Dec 14 11:16:37 2004 Subject: [Wxruby-users] wxRuby and other GUI toolkits In-Reply-To: <41BF0D99.5030402@qualitycode.com> References: <41BEFE07.5080304@nicreations.com> <41BF052C.7050309@mktec.com> <41BF0D99.5030402@qualitycode.com> Message-ID: <41BF1221.3060400@mktec.com> Kevin Smith wrote: > On the bright side, wx is still the only liberally-licensed, > full-featured, native-widget, cross-platform GUI toolkit. If those > features are important to you, then wx is really where you want to be. > Can I get the same license on that statement, so I can post in on the Ruby ML when people ask about Ruby/GUIs? Zach From wxruby at qualitycode.com Tue Dec 14 11:18:01 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue Dec 14 11:16:47 2004 Subject: [Wxruby-users] Leadership change Message-ID: <41BF1239.3010208@qualitycode.com> Greetings all, Sadly, I must announce my "retirement" as the wxruby project leader. I still believe in the project, and really want it to succeed. Unfortunately, there are other projects that are higher priority for me right now. I cannot be an effective wxruby lead at this time. Perhaps at some point in the future, wxruby will again become a top priority for me. If that happens, I'll evaluate how best to help out at that time. For almost a year now, Nick has been the de-facto wxruby lead. He is the main reason that progress hasn't completely stalled. He has agreed to officially become the lead now, although (like most of us who volunteer for free software projects) he also has other demands on his time. Park Heesob initiated the wxruby project, and most of the 0.6.0 code is still his work. Anyone who has benefitted from wxruby owes thanks to him. I just wanted to say that again. I have to thank Curt for his "behind-the-scenes" efforts. He has contributed greatly to this project in quiet ways. Finally, thanks to everyone else who has submitted a patch, edited the wiki, submitted a bug report, sent an email to the list, or raised public awareness of wxruby. This is a community project, and the more involvement we get, the healthier the project will be. Please realize that a project like this NEEDS non-coders who can help with publicity, test and file bug reports, update documentation, write tutorials and samples, etc. The less of this that the core maintainers have to do, the more time and energy they have to actually write code. Moving forward, I will remain a part of the wxruby community. I still believe that wxruby-swig is the future, so any effort I put in will be on that side. I will still try to answer questions, and provide input when I think it might be helpful. Cheers, Kevin From wxruby at qualitycode.com Tue Dec 14 11:42:02 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue Dec 14 11:40:49 2004 Subject: [Wxruby-users] wxRuby and other GUI toolkits In-Reply-To: <41BF1221.3060400@mktec.com> References: <41BEFE07.5080304@nicreations.com> <41BF052C.7050309@mktec.com> <41BF0D99.5030402@qualitycode.com> <41BF1221.3060400@mktec.com> Message-ID: <41BF17DA.3030208@qualitycode.com> Zach Dennis wrote: > Kevin Smith wrote: > >> On the bright side, wx is still the only liberally-licensed, >> full-featured, native-widget, cross-platform GUI toolkit. If those >> features are important to you, then wx is really where you want to be. >> > > Can I get the same license on that statement, so I can post in on the > Ruby ML when people ask about Ruby/GUIs? :-) Feel free to use that statement, or any derivative, any way you see fit, and I encourage you to do so without attributing it to me. I just hope it's true :-/ Be aware that at any moment, if a new contender pops up, it may no longer be true. I suppose if you added "mature" in there somewhere, it would remain true for several more years, but wxruby itself isn't yet "mature", so that would only apply to wxWindows/wxWidgets itself. Kevin From zdennis at mktec.com Tue Dec 14 14:39:16 2004 From: zdennis at mktec.com (Zach Dennis) Date: Tue Dec 14 14:38:15 2004 Subject: [Wxruby-users] Leadership change In-Reply-To: <41BF1239.3010208@qualitycode.com> References: <41BF1239.3010208@qualitycode.com> Message-ID: <41BF4164.9000508@mktec.com> To Kevin: It is sad to read you go. (i have never met you, so I can't say I'll see you go). Enjoy life beyond wxRuby and be sure to check in! Best of wishes! To Nick: Great to have you as the new wxRuby leader. If there is anything I can do to help, just let me know, but be aware (as you already know) my c++ skills aren't that hot. To Curt: The silent, but effective force. Zach From devel at nicreations.com Tue Dec 14 18:11:57 2004 From: devel at nicreations.com (Nick) Date: Tue Dec 14 18:13:05 2004 Subject: [Wxruby-users] Re: wxRuby and other GUI toolkits In-Reply-To: <41BF6F5C.7050402@nicreations.com> References: <41BEFE07.5080304@nicreations.com> <41BF6F5C.7050402@nicreations.com> Message-ID: <41BF733D.2000500@nicreations.com> To add to my last post: I'd also love to hear if you do GUI developement and haven't tried wxruby, why haven't you tried it? Nick Nick wrote: > > > Any chance you could provide a simplified interface along the lines > > discussed at length in > > > > > http://groups-beta.google.com/group/comp.lang.ruby/messages/36fe4224ced792ff,7824fe1d05b4f648,ffa0c9b33be25877,453e05fefa6610b4,79dd1925715e2b10,3c7c01a279f685f6,fc636d28f68f9266,78ac98a3c718caa4,4f3960a377f7eed1,99bd3fcd397cf7d1?thread_id=b901e483a6711f72&mode=thread&noheader=1&q=UI+hal+fulton#doc_36fe4224ced792ff > > > > > It basically let's Ruby code look structurally like the ui structure, > and > > uses some variation of dynamic binding to more cleanly define, > override, and > > lookup wide-ranging defaults. > > It's a good suggestion, though a little outside the scope of the > wxWidgets project. Lit window has conceptually similar to what your > talking about for C++. > > http://www.litwindow.com/lwl/doc/html/comparison_10x.html > > I don't want this to get into a battle of which GUI toolkit is more > virtuous; there are different toolkits because people want different > functionality. I'd like to hear from anybody who has tried wxruby and > didn't like it, and why they didn't like it. > > Nick > > itsme213 wrote: > >> Any chance you could provide a simplified interface along the lines >> discussed at length in >> >> http://groups-beta.google.com/group/comp.lang.ruby/messages/36fe4224ced792ff,7824fe1d05b4f648,ffa0c9b33be25877,453e05fefa6610b4,79dd1925715e2b10,3c7c01a279f685f6,fc636d28f68f9266,78ac98a3c718caa4,4f3960a377f7eed1,99bd3fcd397cf7d1?thread_id=b901e483a6711f72&mode=thread&noheader=1&q=UI+hal+fulton#doc_36fe4224ced792ff >> >> >> It basically let's Ruby code look structurally like the ui structure, and >> uses some variation of dynamic binding to more cleanly define, >> override, and >> lookup wide-ranging defaults. >> >> I for one would gravitate strongly towards such a simplified interface >> ... >> >> "Nick" wrote in message >> news:41BEFE07.5080304@nicreations.com... >> >>> So, having subscribed recently to the ruby-talk mailing list, I've >>> noticed that wxruby doesn't seem to have the "respect" of other GUI >>> libraries. I know GUI-library preference is a holy war almost up there >>> with vi versus emacs, but since I'm a wxruby developer, I'd like to know >>> what people "don't" like about wxruby. Otherwise, how else do we >>> improve? >>> >>> Browsing online, I've found a few complaints: >>> >>> Difficulty in getting it installed - Daniel Sheppard, >>> http://www.jroller.com/page/soxbox/ >>> Use of ugly integer values for event handlers - >>> http://homepages.ihug.com.au/~naseby/31.html >>> >>> It's a good start (though I don't know what platform Mr. Sheppard is >>> trying to install on), but any other discussion would be most helpful. >>> >>> Thanks, >>> >>> Nick >>> >>> >> >> >> >> >> >> >> > > > > > From devel at nicreations.com Wed Dec 15 15:24:19 2004 From: devel at nicreations.com (Nick) Date: Wed Dec 15 15:25:25 2004 Subject: [Wxruby-users] Leadership change In-Reply-To: <41BF1239.3010208@qualitycode.com> References: <41BF1239.3010208@qualitycode.com> Message-ID: <41C09D73.2060708@nicreations.com> I think we can all agree that Kevin has done a fantastic job during his tenure as wxruby lead. To list off some of his accomplishments: 1) Oversaw the release of version 0.1 through 0.5 2) Created the framework for wxruby-swig 3) Created the wxruby wiki front page which is ever-expanding. 4) Has shown a significant presence on the mailing list. 5) Has shown both excellent management and technical skill Kevin leaves big shoes to fill, and sadly my shoe size is 8 and a half. I'm going to try my best to continue the work he did. My goals are 1) To complete the migration to wxruby-swig 2) Improve the wxruby documentation 3) Keep the same level of discussion on the mailing list 4) Increase the wxruby presence on the ruby-talk mailing list Of course, open source projects are not one-man operations. There are a number of ways to contribute to the project: If you're a C++ developer or have SWIG experience, then we need help with wxruby-swig. There are still many classes to convert, and lots of support code to write. If you're a wxruby user, then let the list know what you need! Lots of classes have been added by user requests. Also, contributing articles to the wiki or adding to the samples is a great way to give your support. Like I said before, Kevin leaves big shoes to fill. I hope I can rise to the challenge. Nick Kevin Smith wrote: > Greetings all, > > Sadly, I must announce my "retirement" as the wxruby project leader. I > still believe in the project, and really want it to succeed. > Unfortunately, there are other projects that are higher priority for me > right now. I cannot be an effective wxruby lead at this time. Perhaps at > some point in the future, wxruby will again become a top priority for > me. If that happens, I'll evaluate how best to help out at that time. > > For almost a year now, Nick has been the de-facto wxruby lead. He is the > main reason that progress hasn't completely stalled. He has agreed to > officially become the lead now, although (like most of us who volunteer > for free software projects) he also has other demands on his time. > > Park Heesob initiated the wxruby project, and most of the 0.6.0 code is > still his work. Anyone who has benefitted from wxruby owes thanks to > him. I just wanted to say that again. > > I have to thank Curt for his "behind-the-scenes" efforts. He has > contributed greatly to this project in quiet ways. > > Finally, thanks to everyone else who has submitted a patch, edited the > wiki, submitted a bug report, sent an email to the list, or raised > public awareness of wxruby. This is a community project, and the more > involvement we get, the healthier the project will be. > > Please realize that a project like this NEEDS non-coders who can help > with publicity, test and file bug reports, update documentation, write > tutorials and samples, etc. The less of this that the core maintainers > have to do, the more time and energy they have to actually write code. > > Moving forward, I will remain a part of the wxruby community. I still > believe that wxruby-swig is the future, so any effort I put in will be > on that side. I will still try to answer questions, and provide input > when I think it might be helpful. > > Cheers, > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From devel at nicreations.com Thu Dec 16 20:46:13 2004 From: devel at nicreations.com (Nick) Date: Thu Dec 16 20:52:14 2004 Subject: [Wxruby-users] [Fwd: Re: Ruby Cocoa (OS X) questions: deployment & interface builder] Message-ID: <41C23A65.9020908@nicreations.com> This is a re-post (slightly edited) from the ruby-talk list. I think I'm going to add a wiki page on the topic. -------- Original Message -------- Subject: Re: Ruby Cocoa (OS X) questions: deployment & interface builder Date: Fri, 17 Dec 2004 07:48:26 +0900 From: Nick Reply-To: ruby-talk@ruby-lang.org To: ruby-talk@ruby-lang.org (ruby-talk ML) References: <838ec8ff0412160946608bc574@mail.gmail.com> > I'm interested in Mac/Cocoa development. > > Are there tools available for .app packaging of Ruby/Cocoa apps? > Can this be done w/o reliance on the downlevel Ruby 1.6 included in > Panther? Actually, I've wrapped a number of ruby apps. If done right, ruby apps can look just like Mac OS X applications. The trick is that you need some PPC binary in the Contents/MacOS directory. I wrote a wrapper that links to the ruby static library, figures out where the Resources directory of the bundle is, and then executes "start.rb" in the resources directory. You can download it at: http://www.nicreations.com/boot.cpp To build it, use g++ -c -I -x objective-c++ -framework Cocoa boot.cpp g++ -o boot -L -lruby-static -framework Cocoa boot.o An app is just a set of directories: Root.app + Contents Info.plist + MacOS boot (output binary) + Resources Ruby scripts and extensions The "executable" script needs to be named "start.rb". Any extensions need to be put into the Resources directory. For example, I put the wxruby.bundle in the Resources directory, and it allows me to create full GUI apps on the Mac. However, wxruby is a 4 mb library, and makes for a fat executable. (wxruby-swig will be build-able as a shared framework, allowing all wxruby apps to share a single framework). Finally, you need to create a Info.plist file in the Contents directory. It is a simple XML file OS X uses to get properties about your application. Here is a sample: CFBundleInfoDictionaryVersion 6.0 CFBundleIdentifier org.ruby.your.app.name.here CFBundleDevelopmentRegion English CFBundleExecutable boot CFBundleName Your App Name CFBundlePackageType APPL CFBundleSignature ???? CFBundleVersion 1.0 CFBundleShortVersionString 1.0 CFBundleGetInfoString Your App Name (c) 2004 Your Name CFBundleLongVersionString Your App Name (c) 2004 Your Name NSHumanReadableCopyright Copyright 2004 Your Name LSRequiresCarbon CSResourcesFileMapped You should change CFBundleIdentifier, CFBundleName, CFBundleGetInfoString, CFBundleLongVersionString, NSHumanReadableCopyright for your own application. If you take this approach, your ruby app will look and feel exactly like any other Mac application - and no one needs to know that your development time was one tenth everybody elses for using a better language. :-) Nick Michael DeHaan wrote: > Folks, > > I'm interested in Mac/Cocoa development. > > Are there tools available for .app packaging of Ruby/Cocoa apps? > Can this be done w/o reliance on the downlevel Ruby 1.6 included in > Panther? > > Anyhow, any pointers would be greatly appreciated. > > I guess, bottom line, is that i'd like to write applications that > other people can use -- so I'm a bit concerned about deployment > considerations. > > On a somewhat related note, is there a way of using interface files > w/o reliance on XCode and interface builder? I can't see any > documentation to the effect that it is possible, but it must be > possible somehow... Coding in vim is preferable to me than using > XCode, it's yet another interface to deal with and I like my > terminals! :) > > (Yes, I've asked about Ruby/Tk and Tcl/Tk Aqua before -- Tcl/Tk Aqua > does look awesome ... but that's even a greater deployment problem, > IMHO... I was having substantial trouble setting it up even on my box > to work with Ruby per the Ruby Garden article) > > Thanks, > > --Michael DeHaan > > > > From melfstrand at maf.org Fri Dec 17 12:06:12 2004 From: melfstrand at maf.org (Marshall Elfstrand) Date: Fri Dec 17 12:04:49 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x Message-ID: A while back there was a discussion about what version of WxWidgets to target with WxRuby-SWIG. I don't remember seeing any resolution, but I gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the thinking that WxRuby-SWIG would quickly mature to the point that it could replace WxRuby, and once that was done the focus would shift to working with 2.5.x. I'd like to request that the focus of WxRuby-SWIG switch to targeting 2.5.x. Mostly this is because the Mac OS X support in 2.4.2 is so poor that I'm not even bothering with it until 2.5.x, and the thought of having to wait to support OS X for two phases of development (finishing WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite discouraging, especially since the move to WxRuby-SWIG is taking longer than originally anticipated. But I'm also thinking that, since WxWidgets has some core changes in 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to incorporate those changes. Application code will need to change to adapt to 2.5, and although WxRuby-SWIG hasn't been expected to introduce changes of its own, this would be a perfect time to incorporate some of the planned features (e.g. label=() vs. set_label()) and only have to break existing code *once.* For those wanting to add classes to WxRuby-SWIG, I would think it would be preferable to just work on the 2.5 version, rather than adding one for 2.4 and then having to revisit it for the change to 2.5. I recognize that 2.5 is currently not regarded as the "stable" release, but for me the problems of the Mac port combined with the bugs in 2.4 (such as missing XRC support for status bars) make 2.5 much more attractive, and I'd like to move to it as soon as possible. Thoughts? Thanks very much to Nick, Kevin, Park, Curt, and the rest for this excellent project. I really appreciate the time you've put into it. I'm using it daily and hope to contribute in the future as I become more comfortable with how WxWidgets works, although my C++ is pretty rusty at the moment. :-) Marshall From rshaw at opendarwin.org Fri Dec 17 12:12:20 2004 From: rshaw at opendarwin.org (Robert Shaw) Date: Fri Dec 17 12:10:58 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: Message-ID: I tend to agree with Marshall on this. I suspect that by the time WxRuby-SWIG is ready for release, that wxWidgets 2.5.x will also be considered stable. I would also like to see this happen because of the MacOSX issues as well. Thanks! -Robert On 12/17/04 9:06 AM, "Marshall Elfstrand" wrote: > A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don't remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with > the thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I'd like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that > I'm not even bothering with it until 2.5.x, and the thought of having > to wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I'm also thinking that, since WxWidgets has some core changes in > 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn't been expected to > introduce changes of its own, this would be a perfect time to > incorporate some of the planned features (e.g. label=() vs. > set_label()) and only have to break existing code *once.* For those > wanting to add classes to WxRuby-SWIG, I would think it would be > preferable to just work on the 2.5 version, rather than adding one for > 2.4 and then having to revisit it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I'd like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you've put into it. > I'm using it daily and hope to contribute in the future as I become > more comfortable with how WxWidgets works, although my C++ is pretty > rusty at the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From seanlong at smccabinets.com Fri Dec 17 12:30:13 2004 From: seanlong at smccabinets.com (Sean Long) Date: Fri Dec 17 12:28:55 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: Message-ID: <000901c4e45e$1403d230$0b00a8c0@SeansLaptop> I agree with Marshall. I have not touched wxRuby lately because I needed to move to wx 2.5.x to fix a "chicken/egg" condition in 2.4.x printing. Another reason to move to 2.5.x now is the changes to break-up the libs. Also wxPython is using 2.5.3 and we can't let that lesser language show us up ;) Sean -----Original Message----- From: wxruby-users-bounces@rubyforge.org [mailto:wxruby-users-bounces@rubyforge.org] On Behalf Of Marshall Elfstrand Sent: Friday, December 17, 2004 9:06 AM To: General discussion of wxRuby Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x A while back there was a discussion about what version of WxWidgets to target with WxRuby-SWIG. I don't remember seeing any resolution, but I gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the thinking that WxRuby-SWIG would quickly mature to the point that it could replace WxRuby, and once that was done the focus would shift to working with 2.5.x. I'd like to request that the focus of WxRuby-SWIG switch to targeting 2.5.x. Mostly this is because the Mac OS X support in 2.4.2 is so poor that I'm not even bothering with it until 2.5.x, and the thought of having to wait to support OS X for two phases of development (finishing WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite discouraging, especially since the move to WxRuby-SWIG is taking longer than originally anticipated. But I'm also thinking that, since WxWidgets has some core changes in 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to incorporate those changes. Application code will need to change to adapt to 2.5, and although WxRuby-SWIG hasn't been expected to introduce changes of its own, this would be a perfect time to incorporate some of the planned features (e.g. label=() vs. set_label()) and only have to break existing code *once.* For those wanting to add classes to WxRuby-SWIG, I would think it would be preferable to just work on the 2.5 version, rather than adding one for 2.4 and then having to revisit it for the change to 2.5. I recognize that 2.5 is currently not regarded as the "stable" release, but for me the problems of the Mac port combined with the bugs in 2.4 (such as missing XRC support for status bars) make 2.5 much more attractive, and I'd like to move to it as soon as possible. Thoughts? Thanks very much to Nick, Kevin, Park, Curt, and the rest for this excellent project. I really appreciate the time you've put into it. I'm using it daily and hope to contribute in the future as I become more comfortable with how WxWidgets works, although my C++ is pretty rusty at the moment. :-) Marshall _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users From zdennis at mktec.com Fri Dec 17 12:35:37 2004 From: zdennis at mktec.com (Zach Dennis) Date: Fri Dec 17 12:34:30 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <000901c4e45e$1403d230$0b00a8c0@SeansLaptop> References: <000901c4e45e$1403d230$0b00a8c0@SeansLaptop> Message-ID: <41C318E9.8050506@mktec.com> I favor this as well, because I do believe that wxWidgets 2.5.x has alpha transparency...and that would be so sweet...we have a work app we do in java right now I could move to wxRuby if I could use the transparency.... I'm also a plus 1 (as Nick already knows) to help wherever and whenever I can, Zach Sean Long wrote: > I agree with Marshall. > > I have not touched wxRuby lately because I needed to move to wx 2.5.x to > fix a "chicken/egg" condition in 2.4.x printing. Another reason to move > to 2.5.x now is the changes to break-up the libs. Also wxPython is using > 2.5.3 and we can't let that lesser language show us up ;) > > Sean > > -----Original Message----- > From: wxruby-users-bounces@rubyforge.org > [mailto:wxruby-users-bounces@rubyforge.org] On Behalf Of Marshall > Elfstrand > Sent: Friday, December 17, 2004 9:06 AM > To: General discussion of wxRuby > Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x > > > A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don't remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with > the thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I'd like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that > I'm not even bothering with it until 2.5.x, and the thought of having > to wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I'm also thinking that, since WxWidgets has some core changes in > 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn't been expected to > introduce changes of its own, this would be a perfect time to > incorporate some of the planned features (e.g. label=() vs. > set_label()) and only have to break existing code *once.* For those > wanting to add classes to WxRuby-SWIG, I would think it would be > preferable to just work on the 2.5 version, rather than adding one for > 2.4 and then having to revisit it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I'd like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you've put into it. > I'm using it daily and hope to contribute in the future as I become > more comfortable with how WxWidgets works, although my C++ is pretty > rusty at the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > From devel at nicreations.com Fri Dec 17 16:09:24 2004 From: devel at nicreations.com (Nick) Date: Fri Dec 17 16:10:22 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: References: Message-ID: <41C34B04.4020701@nicreations.com> I'd like to make a move too, but it's not a "throw a switch for a solution" problem. The biggest issue is that wxruby-swig depends on a generated XML file created off the wxWidgets 2.4.2 documentation. We only have the XML file; we don't have the script that made it. Without an XML file description of the 2.5.2, the move to 2.5.2 has to be done by hand. A good ruby project would be to generate a similar ruby script to do what was already done earlier - a script that parses the wxWidgets docs and generates an XML description of the library. The original file can be seen at: http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/wxclasses-2.4.2.xml?rev=1.1&cvsroot=wxruby&content-type=text/vnd.viewcvs-markup (try to avoid slashdotting rubyforge by not going all at once :-) I'd also like to hear what issues your having with wxruby for the Mac. I know Marshall would like XRC toolbar support, but what other issues are arising? It may be that there are more wxruby issues than wx issues. Nick Marshall Elfstrand wrote: > A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don't remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the > thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I'd like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that I'm > not even bothering with it until 2.5.x, and the thought of having to > wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I'm also thinking that, since WxWidgets has some core changes in 2.5 > versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn't been expected to introduce > changes of its own, this would be a perfect time to incorporate some of > the planned features (e.g. label=() vs. set_label()) and only have to > break existing code *once.* For those wanting to add classes to > WxRuby-SWIG, I would think it would be preferable to just work on the > 2.5 version, rather than adding one for 2.4 and then having to revisit > it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I'd like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you've put into it. > I'm using it daily and hope to contribute in the future as I become more > comfortable with how WxWidgets works, although my C++ is pretty rusty at > the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From wxruby at qualitycode.com Fri Dec 17 21:41:02 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri Dec 17 21:39:45 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C34B04.4020701@nicreations.com> References: <41C34B04.4020701@nicreations.com> Message-ID: <41C398BE.6000709@qualitycode.com> Nick wrote: > > I'd like to make a move too, but it's not a "throw a switch for a > solution" problem. The biggest issue is that wxruby-swig depends on a > generated XML file created off the wxWidgets 2.4.2 documentation. We > only have the XML file; we don't have the script that made it. Actually, we do. But it's a complex and error-prone script, written in perl: http://www.bzzt.net/~wxwindows/index2.html > A good ruby project would be to generate a similar ruby script to do > what was already done earlier - a script that parses the wxWidgets docs > and generates an XML description of the library. An alternative that has been mentioned before would be to create a swig script that uses their parser to go through the wxWidgets C++ header files, and outputs a sanitized and simplified version of those headers, which could then be fed into the wxRuby rake build process. I find writing swig scripts challenging enough that I was happier to use the existing XML file (even though it contained errors where the docs didn't match the actual headers). Perhaps someone else here would be less intimidated by swig and could do this. I wonder if it would be possible or worth it to support both. Gentoo doesn't seem to have an ebuild for wxWidgets 2.5 yet. > The original file can be seen at: (snip) > (try to avoid slashdotting rubyforge by not going all at once :-) Especially since it is HUGE!!! Don't bother looking at it unless you're serious. It's just an enormous XML file representing everything in the html wxWindows docs. Kevin From zdennis at mktec.com Fri Dec 17 23:42:29 2004 From: zdennis at mktec.com (Zach Dennis) Date: Fri Dec 17 23:44:26 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C34B04.4020701@nicreations.com> References: <41C34B04.4020701@nicreations.com> Message-ID: <41C3B535.5070300@mktec.com> Nick wrote: > > A good ruby project would be to generate a similar ruby script to do > what was already done earlier - a script that parses the wxWidgets docs > and generates an XML description of the library. The original file can > be seen at: > > http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/wxclasses-2.4.2.xml?rev=1.1&cvsroot=wxruby&content-type=text/vnd.viewcvs-markup > This just parses the same docs that wxWindows has alone, into this xml format? Is there anything else added manually besides that? Zach From zdennis at mktec.com Sat Dec 18 00:28:06 2004 From: zdennis at mktec.com (Zach Dennis) Date: Sat Dec 18 00:30:02 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C34B04.4020701@nicreations.com> References: <41C34B04.4020701@nicreations.com> Message-ID: <41C3BFE6.8020903@mktec.com> Nick wrote: > > I'd like to make a move too, but it's not a "throw a switch for a > solution" problem. The biggest issue is that wxruby-swig depends on a > generated XML file created off the wxWidgets 2.4.2 documentation. We > only have the XML file; we don't have the script that made it. Without > an XML file description of the 2.5.2, the move to 2.5.2 has to be done > by hand. To comment on my last post. If all the xml file is, is an automated file created by existing wxWindows docs, and if the format is to stay consistent with the existing XML file format (is there a dtd i can check against?), then I wouldn't mind starting the parsing project for getting 2.5.x going... If there are any other takers who'd like to assist on a project like this, let me know and let's try to coordinate something. If someone has already taken the liberty to start this project, please let me know so I don't duplicate effort. If you need assistance then just hollar at me... Thanks, Zach From curt at hibbs.com Sat Dec 18 00:46:30 2004 From: curt at hibbs.com (Curt Hibbs) Date: Sat Dec 18 00:45:05 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C3BFE6.8020903@mktec.com> Message-ID: Zach Dennis wrote: > > Nick wrote: > > > > > I'd like to make a move too, but it's not a "throw a switch for a > > solution" problem. The biggest issue is that wxruby-swig depends on a > > generated XML file created off the wxWidgets 2.4.2 documentation. We > > only have the XML file; we don't have the script that made it. Without > > an XML file description of the 2.5.2, the move to 2.5.2 has to be done > > by hand. > > To comment on my last post. If all the xml file is, is an automated file > created by existing wxWindows docs, and if the format is to stay > consistent with the existing XML file format (is there a dtd i can check > against?), then I wouldn't mind starting the parsing project for getting > 2.5.x going... I don't think its particularly important to stay consistent with the existing format. The main thing is to get the essential information. One of the reasons why the current XML file is sometimes wrong is because it was generated from the comment blocks in the wxWidgets code. If the comment block is wrong, then the XML is wrong. The approach that Kevin described eliminates this problem by using the code itself, not the comment blocks) by parsing the output from a swig pass. > If there are any other takers who'd like to assist on a project like > this, let me know and let's try to coordinate something. > > If someone has already taken the liberty to start this project, please > let me know so I don't duplicate effort. If you need assistance then > just hollar at me... I think you've got it. I'm not aware of any one else working on this. Curt From wxruby at qualitycode.com Sat Dec 18 09:34:59 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat Dec 18 09:33:44 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: References: Message-ID: <41C44013.204@qualitycode.com> Curt Hibbs wrote: > Zach Dennis wrote: >>To comment on my last post. If all the xml file is, is an automated file >>created by existing wxWindows docs, and if the format is to stay >>consistent with the existing XML file format (is there a dtd i can check >>against?), then I wouldn't mind starting the parsing project for getting >>2.5.x going... > > I don't think its particularly important to stay consistent with the > existing format. The main thing is to get the essential information. Right. The XML format could change, as long as wxruby-swig/swig/extractxml.rb is updated to handle the new format. Note that the bulk of extractxml is correcting errors in the XML file. If the XML were 100% correct, it would be a pretty small and simple tool. > The approach that Kevin described eliminates this problem by using the code > itself, not the comment blocks) by parsing the output from a swig pass. Yes. Our goal is to have clean .h files representing the wxWindows classes, that we can hand to SWIG so it can auto-generate wrappers. The XML file is just a mechanism to get there. Whether we write our own wxWidget doc extraction tool, or a swig-based extraction tool, we could bypass the XML step and directly generate simple .h files. Cheers, Kevin From zdennis at mktec.com Sat Dec 18 10:05:39 2004 From: zdennis at mktec.com (Zach Dennis) Date: Sat Dec 18 10:04:30 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C44013.204@qualitycode.com> References: <41C44013.204@qualitycode.com> Message-ID: <41C44743.7060906@mktec.com> Kevin Smith wrote: > Curt Hibbs wrote: > >> Zach Dennis wrote: >> >>> To comment on my last post. If all the xml file is, is an automated file >>> created by existing wxWindows docs, and if the format is to stay >>> consistent with the existing XML file format (is there a dtd i can check >>> against?), then I wouldn't mind starting the parsing project for getting >>> 2.5.x going... >> >> >> I don't think its particularly important to stay consistent with the >> existing format. The main thing is to get the essential information. > > > Right. The XML format could change, as long as > wxruby-swig/swig/extractxml.rb is updated to handle the new format. > Note that the bulk of extractxml is correcting errors in the XML file. > If the XML were 100% correct, it would be a pretty small and simple tool. > >> The approach that Kevin described eliminates this problem by using the >> code >> itself, not the comment blocks) by parsing the output from a swig pass. > > > Yes. Our goal is to have clean .h files representing the wxWindows > classes, that we can hand to SWIG so it can auto-generate wrappers. The > XML file is just a mechanism to get there. Whether we write our own > wxWidget doc extraction tool, or a swig-based extraction tool, we could > bypass the XML step and directly generate simple .h files. What would be the most preferred way to receive this input...generate xml first....or skip and generate .h files? Or do xml first, then go after .h files? If we go xml, then .h files route, we can work with where we are now, and improve on it. While development is still underway I can work on the .h files output, and then when that is stable/ready/tested we can switch over...what do you guys think of this? If .h files is it could I get someone to post a sample .h file so I can see in comparison, what the original wxWindows .h file looked like and what the outputted .h file I'd be generating looks like? For existing inputs and outputs, waht scripts, files, etc... do I want to be looking so i can see how the process happens now.Is is just the xml file and the extractxml.rb files? Thanks, Zach From wxruby at qualitycode.com Sat Dec 18 11:01:30 2004 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat Dec 18 11:00:19 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C44743.7060906@mktec.com> References: <41C44013.204@qualitycode.com> <41C44743.7060906@mktec.com> Message-ID: <41C4545A.4090009@qualitycode.com> Zach Dennis wrote: > What would be the most preferred way to receive this input...generate > xml first....or skip and generate .h files? Or do xml first, then go > after .h files? There is not a single correct answer. > If we go xml, then .h files route, we can work with where we are now, > and improve on it. While development is still underway I can work on the > .h files output, and then when that is stable/ready/tested we can switch > over...what do you guys think of this? I generally like incremental approaches that build on working code. But in this case, the XML format may be more complex than we need, and it might be much simpler for you to output .h files directly. > If .h files is it could I get someone to post a sample .h file so I can > see in comparison, what the original wxWindows .h file looked like and > what the outputted .h file I'd be generating looks like? The simplified .h files that wxruby-swig generates from XML and feeds to SWIG can be seen here: http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/classes/include/?cvsroot=wxruby It's a bit harder to point at the complex original wxWindows .h files, because they are split by target platform, and are nested (headers including other headers). You can look in your own include/wx directory, or browse here (on a painfully slow server, it seems): http://cvs.wxwidgets.org/viewcvs.cgi/wxWindows/include/wx/ If you compare bitmap.h in each context, you will see a typical example the dramatic difference. One of my secondary goals was to create a set of .h files that were completely independent of wxruby. Such a set of .h files would help anyone trying to swig wx into another language, so they wouldn't have to go through this same hassle to get simple, swiggable .h files. Kevin From zdennis at mktec.com Sat Dec 18 11:26:35 2004 From: zdennis at mktec.com (Zach Dennis) Date: Sat Dec 18 11:25:25 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C4545A.4090009@qualitycode.com> References: <41C44013.204@qualitycode.com> <41C44743.7060906@mktec.com> <41C4545A.4090009@qualitycode.com> Message-ID: <41C45A3B.70202@mktec.com> Kevin Smith wrote: > Zach Dennis wrote: > >> What would be the most preferred way to receive this input...generate >> xml first....or skip and generate .h files? Or do xml first, then go >> after .h files? > > > There is not a single correct answer. So what you're saying is the answer is "Yes" to all the above? =) > >> If we go xml, then .h files route, we can work with where we are now, >> and improve on it. While development is still underway I can work on >> the .h files output, and then when that is stable/ready/tested we can >> switch over...what do you guys think of this? > > > I generally like incremental approaches that build on working code. But > in this case, the XML format may be more complex than we need, and it > might be much simpler for you to output .h files directly. > >> If .h files is it could I get someone to post a sample .h file so I >> can see in comparison, what the original wxWindows .h file looked like >> and what the outputted .h file I'd be generating looks like? > > > The simplified .h files that wxruby-swig generates from XML and feeds to > SWIG can be seen here: > > http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/classes/include/?cvsroot=wxruby > > > It's a bit harder to point at the complex original wxWindows .h files, > because they are split by target platform, and are nested (headers > including other headers). You can look in your own include/wx directory, > or browse here (on a painfully slow server, it seems): > > http://cvs.wxwidgets.org/viewcvs.cgi/wxWindows/include/wx/ > > If you compare bitmap.h in each context, you will see a typical example > the dramatic difference. > > One of my secondary goals was to create a set of .h files that were > completely independent of wxruby. Such a set of .h files would help > anyone trying to swig wx into another language, so they wouldn't have to > go through this same hassle to get simple, swiggable .h files. Ok, I will look into these this weekend and into this next week and I'll be sure to post any questions I have. Thanks, Zach From devel at nicreations.com Sun Dec 19 11:37:25 2004 From: devel at nicreations.com (Nick) Date: Sun Dec 19 11:38:17 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C3BFE6.8020903@mktec.com> References: <41C34B04.4020701@nicreations.com> <41C3BFE6.8020903@mktec.com> Message-ID: <41C5AE45.2080904@nicreations.com> Zach, Before you get too far into making the XML file, I have a task for you that is a bit more pressing: A new documentation script for wxruby-swig. Currently, wxruby has a documentation script that was created for the .t files. You (and others) have mentioned the output is a bit hard to use, and they constantly need to return to the C++ docs. Since the XML file has all of the C++ docs inside of it, I'd like you to get wxruby-swig from CVS and write a ruby script that extracts the XML docs for all the classes in the swig/classes directory. Now - what output format you want to use is up to you. I personally hate the HTML docs that rdoc generates (or perhaps I simply like my class/method listing on the side as opposed to the top), but if people here like rdoc then I think it should be the chosen output format. There is also doxygen and ndoc, which both have really good output formats. As far as converting to 2.5 is concerned, it may be that not all that many methods have changed underneath, and we can solve the problem with existing tools. Nick Zach Dennis wrote: > Nick wrote: > >> >> I'd like to make a move too, but it's not a "throw a switch for a >> solution" problem. The biggest issue is that wxruby-swig depends on a >> generated XML file created off the wxWidgets 2.4.2 documentation. We >> only have the XML file; we don't have the script that made it. Without >> an XML file description of the 2.5.2, the move to 2.5.2 has to be done >> by hand. > > > To comment on my last post. If all the xml file is, is an automated file > created by existing wxWindows docs, and if the format is to stay > consistent with the existing XML file format (is there a dtd i can check > against?), then I wouldn't mind starting the parsing project for getting > 2.5.x going... > > If there are any other takers who'd like to assist on a project like > this, let me know and let's try to coordinate something. > > If someone has already taken the liberty to start this project, please > let me know so I don't duplicate effort. If you need assistance then > just hollar at me... > > Thanks, > > Zach > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From zdennis at mktec.com Sun Dec 19 15:10:02 2004 From: zdennis at mktec.com (Zach Dennis) Date: Sun Dec 19 15:11:58 2004 Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x In-Reply-To: <41C5AE45.2080904@nicreations.com> References: <41C34B04.4020701@nicreations.com> <41C3BFE6.8020903@mktec.com> <41C5AE45.2080904@nicreations.com> Message-ID: <41C5E01A.80607@mktec.com> Nick wrote: > > Zach, > > Before you get too far into making the XML file, I have a task for you > that is a bit more pressing: A new documentation script for wxruby-swig. > > Currently, wxruby has a documentation script that was created for the .t > files. You (and others) have mentioned the output is a bit hard to use, > and they constantly need to return to the C++ docs. > > Since the XML file has all of the C++ docs inside of it, I'd like you to > get wxruby-swig from CVS and write a ruby script that extracts the XML > docs for all the classes in the swig/classes directory. Now - what > output format you want to use is up to you. I personally hate the HTML > docs that rdoc generates (or perhaps I simply like my class/method > listing on the side as opposed to the top), but if people here like rdoc > then I think it should be the chosen output format. There is also > doxygen and ndoc, which both have really good output formats. I'll shift gears and start getting on this. Zach From warpeace at zworg.com Wed Dec 22 13:19:59 2004 From: warpeace at zworg.com (Kushagra Merchant) Date: Wed Dec 22 13:12:24 2004 Subject: [Wxruby-users] (no subject) Message-ID: <9018.1103739599@zworg.com> Hi, While running the sample application controls/control.rbw I encountered the following error: controls.rbw:1064:in `onAbout': undefined method `free' for # (NoMethodError) from controls.rbw:1039:in `initialize' from controls.rbw:1039:in `call' from controls.rbw:1164:in `main_loop' from controls.rbw:1164 I'm running wxruby 0.6 on Windows XP. Is an explicit free call required for BusyCursor? Regards, Kushagra From sdate at everestkc.net Wed Dec 22 17:11:12 2004 From: sdate at everestkc.net (Shashank Date) Date: Wed Dec 22 17:09:42 2004 Subject: [Wxruby-users] (no subject) In-Reply-To: <9018.1103739599@zworg.com> References: <9018.1103739599@zworg.com> Message-ID: <41C9F100.5050407@everestkc.net> Hi, Kushagra Merchant wrote: >Hi, > While running the sample application controls/control.rbw I >encountered the following >error: > controls.rbw:1064:in `onAbout': undefined method `free' for >#827db0> (NoMethodError) > from controls.rbw:1039:in `initialize' > from controls.rbw:1039:in `call' > from controls.rbw:1164:in `main_loop' > from controls.rbw:1164 > >I'm running wxruby 0.6 on Windows XP. Is an explicit free call required >for BusyCursor? > > The BusyCursor syntax has changed in 0.6.0 ... you no longer need the free call. All you need to do is pass a block. So if you did this earlier: def onAbout(event) bc = BusyCursor.new dialog = MessageDialog.new(self, "This is a control sample", "About Controls", OK ) dialog.show_modal() bc.free end now you will have to do: def onAbout(event) BusyCursor.new { dialog = MessageDialog.new(self, "This is a control sample", "About Controls", OK ) dialog.show_modal() } end HTH, -- Shashank >Regards, >Kushagra >_______________________________________________ >wxruby-users mailing list >wxruby-users@rubyforge.org >http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sdate at everestkc.net Wed Dec 22 17:15:24 2004 From: sdate at everestkc.net (Shashank Date) Date: Wed Dec 22 17:13:51 2004 Subject: [Wxruby-users] (no subject) In-Reply-To: <41C9F100.5050407@everestkc.net> References: <9018.1103739599@zworg.com> <41C9F100.5050407@everestkc.net> Message-ID: <41C9F1FC.1040806@everestkc.net> Oops ! Shashank Date wrote: > def onAbout(event) > BusyCursor.new { This should be : BusyCursor.busy { > dialog = MessageDialog.new(self, "This is a control > sample", "About Controls", OK ) > dialog.show_modal() > } > end Sorry for the confusion. -- Shashank From lgomez at vfxnetwork.com Fri Dec 31 16:26:53 2004 From: lgomez at vfxnetwork.com (=?ISO-8859-1?Q?=22Luis_G=2E_G=F3mez=22?=) Date: Fri Dec 31 16:25:03 2004 Subject: [Wxruby-users] catch keystrokes Message-ID: <41D5C41D.7010008@vfxnetwork.com> is it possible to intercept keystrokes using wxruby?