Hi,
Most wxRuby classes do not require an explicit ID :
- Window and its subclasses do not require an explicit ID during their creation
- Menu do not require an explicit ID during the addition of a menu item
Toolbar does not follow this rule. Indeed, you have to explicitly
define an ID to add a tool within a toolbar.
1/
It would be great if ToolBar#add_tool :
- takes only optionnally an ID
- if the ID is specified, the method returns the tool position as usual
- if the ID is not specified, the method returns both the "generated
ID" and the tool position (as Ruby can return more than one value).
2/
It would be even more great if ToolBar#add_tool supports "hash style"
named arguments. Then we could merge add_tool and insert_tool as
following :
# add
my_toolbar.add_tool("Text", my_bitmap)
# insert
my_toolbar.add_tool("Text", my_bitmap, :position => 3)
Cheers.
Chauk-Mean.
Chauk-Mean P wrote:> Hi, > > Most wxRuby classes do not require an explicit ID : > >....> Toolbar does not follow this rule. Indeed, you have to explicitly > define an ID to add a tool within a toolbar. >I agree this is a bit of wart. I''ve been using that class a bit recently and the API still feels a bit clumsy, though better than it was.> 1/ > It would be great if ToolBar#add_tool : > - takes only optionnally an ID > - if the ID is specified, the method returns the tool position as usual > - if the ID is not specified, the method returns both the "generated > ID" and the tool position (as Ruby can return more than one value). >It feels a bit weird to have different return values depending on the arguments. I think at least it should always return two values if that''s needed. But then multi-return values are irritating to deal with when you''re only interested in one of them. I guess my ideal API would return an instance of Wx::ToolBar::Tool, a pure ruby struct class encapsulating those, and upon which you could call toggle(), delete() etc. The same goes for Wx::Grid, where I''d like a Wx::Grid::Cell. This feels more OO-ish - but is not the way the wxWidgets API is designed - one of the reason some people don''t like it. But I''m not sure whether to pursue this at this point.> 2/ > It would be even more great if ToolBar#add_tool supports "hash style" > named arguments. Then we could merge add_tool and insert_tool as > following : > > # add > my_toolbar.add_tool("Text", my_bitmap) > # insert > my_toolbar.add_tool("Text", my_bitmap, :position => 3)I think this is pretty possible and desirable. Feel free to post a feature request or even better an implementation. alex
Hi, 2008/2/29, Alex Fenton <alex at pressure.to>:> > Toolbar does not follow this rule. Indeed, you have to explicitly > > define an ID to add a tool within a toolbar. > > > I agree this is a bit of wart. I''ve been using that class a bit recently > and the API still feels a bit clumsy, though better than it was. > > 1/ > > It would be great if ToolBar#add_tool : > > - takes only optionnally an ID > > - if the ID is specified, the method returns the tool position as usual > > - if the ID is not specified, the method returns both the "generated > > ID" and the tool position (as Ruby can return more than one value). > > > It feels a bit weird to have different return values depending on the > arguments. I think at least it should always return two values if that''s > needed. But then multi-return values are irritating to deal with when > you''re only interested in one of them.It is not unusual to have different return values depending on the arguments. For example, in Ruby 1.9.0, the enumerable methods (e.g. each) return an Enumerator if no block is provided. The advantage of my proposal is that the API can remain backward compatible.> > I guess my ideal API would return an instance of Wx::ToolBar::Tool, a > pure ruby struct class encapsulating those, and upon which you could > call toggle(), delete() etc. > > The same goes for Wx::Grid, where I''d like a Wx::Grid::Cell. This feels > more OO-ish - but is not the way the wxWidgets API is designed - one of > the reason some people don''t like it.Why not, but this will introduce some compatibility issue.> > 2/ > > It would be even more great if ToolBar#add_tool supports "hash style" > > named arguments. Then we could merge add_tool and insert_tool as > > following : > > > > # add > > my_toolbar.add_tool("Text", my_bitmap) > > # insert > > my_toolbar.add_tool("Text", my_bitmap, :position => 3) > I think this is pretty possible and desirable. Feel free to post a > feature request or even better an implementation.I will think about a better implementation. For that, where is the code that manage hash style arguments for Window and its subclasses ? I hope it is at the Ruby level and not at the SWIG level as I don''t know SWIG. Cheers. Chauk-Mean.
Hey, On 3/14/08, Chauk-Mean P <chauk.mean at gmail.com> wrote:> > I will think about a better implementation. > For that, where is the code that manage hash style arguments for > Window and its subclasses ? > I hope it is at the Ruby level and not at the SWIG level as I don''t know > SWIG.Unfortunatly Chauk-Mean, that is exactly where it''s defined, is at the Swig Level. They are defined all over the place, but we try to keep them in a common place, which you should be able to find in the file swig/typedefs.i and swig/typemap.i, as well as some are defined within swig/shared/ files. They are defined here, so that they will be able to translate at the C++ Level, the argument values, both for input, and for output. A lot of the functions, require an input variable already be defined, to store the data in, and Ruby doesn''t have that functionality, so we can''t do it at the Ruby Level, we have to do it at the SWIG / C++ Level. Cheers.> > > Chauk-Mean. > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080314/9d5ea699/attachment.html
Chauk-Mean P wrote:>> It feels a bit weird to have different return values depending on the >> arguments. I think at least it should always return two values if that''s >> needed. But then multi-return values are irritating to deal with when >> you''re only interested in one of them. >> > > It is not unusual to have different return values depending on the arguments. > For example, in Ruby 1.9.0, the enumerable methods (e.g. each) return > an Enumerator if no block is provided. >I think it''s not particularly usual or desirable; IMO that 1.9 example works only because blocks are a bit more special than your usual arguments... it would maybe better to have methods differentiated by name> The advantage of my proposal is that the API can remain backward compatible. >I like to keep backwards compatibility as far as possible, but also this is the time to break it before we get to 2.0. 1.9.5 changed the return value of Sizer#add to be struct-like class, maybe this is what ToolBar#add should return.>> The same goes for Wx::Grid, where I''d like a Wx::Grid::Cell. This feels >> more OO-ish - but is not the way the wxWidgets API is designed - one of >> the reason some people don''t like it. >> > > Why not, but this will introduce some compatibility issue. >True. And for Grid it would take a lot of coding.>> I think this is pretty possible and desirable. Feel free to post a >> feature request or even better an implementation. >> > > I will think about a better implementation. > For that, where is the code that manage hash style arguments for > Window and its subclasses ? > I hope it is at the Ruby level and not at the SWIG level as I don''t know SWIG.The hash-style arguments for Window constructors are dealt with in pure ruby; it was originally something I wrote as part of wxSugar. The implementation is in lib/wx/keyword_ctors.rb and the definitions for specific classes are in lib/wx/keyword_defs.rb. At the moment it''s geared to dealing with constructors but most of it should be generalisable to other methods. One thing I''d like to do is make Sizer#add accept hash args, probably along the lines of the wxSugar layout library cheers alex
Hi, 2008/3/14, Alex Fenton <alex at pressure.to>:> > It is not unusual to have different return values depending on the arguments. > > For example, in Ruby 1.9.0, the enumerable methods (e.g. each) return > > an Enumerator if no block is provided. > > > I think it''s not particularly usual or desirable; IMO that 1.9 example > works only because blocks are a bit more special than your usual > arguments... it would maybe better to have methods differentiated by name> > The advantage of my proposal is that the API can remain backward compatible. > > > I like to keep backwards compatibility as far as possible, but also this > is the time to break it before we get to 2.0. 1.9.5 changed the return > value of Sizer#add to be struct-like class, maybe this is what > ToolBar#add should return.OK. I understand your point of view.> One thing I''d like to do is make > Sizer#add accept hash args, probably along the lines of the wxSugar > layout libraryThis is a really good idea.> The implementation is in lib/wx/keyword_ctors.rb and the definitions for > specific classes are in lib/wx/keyword_defs.rb. At the moment it''s > geared to dealing with constructors but most of it should be > generalisable to other methods.I have a quick look at these two files and I''m not sure to understand the whole thing. Questions : 1/ Do you plan to improve ToolBar#add_tool (with a ToolItem as a return value and with hash style arguments) yourself ? 2/ Do you plan to improve Size#add with hash style arguments yourself also ? If not, I can try to propose something for 1/ and/or 2/ but probably with a different or simpler approach (for me). Cheers. Chauk-Mean.