Yes, the Shoes reference refers to the method-based API (which is the standard), but you can just use the object-based API if you'd prefer, which is actually modelled on FXRuby (I originally copied the FXRuby stuff that seemed to make sense and the class names are the same as FXRuby for the most part). Of course, there should be no reason to actually use the objects directly, so maybe I should forget about that (yes, the intention is to give Shoes API (terse and makes assumptions) along with FXRuby complexity if you need it (lots of complex controls and options))
# shoesish
pack :vertical do
button text: "hello" do
# handle event
end
end
# FXRubyish
VerticalPacker.new(container) do |packer|
button = Button.new(packer, text: "hello")
button.subscribe :clicked_left_mouse_button do
# handle event
end
end
Well, the idea is that generally you want to just mess with the options (I haven't implemented :border_width or :background_image yet, since I don't personally need them, but they do fit in with my plan). If you want to override, there is nothing stopping you and you have the option of completely overriding #draw OR overriding #draw_background, #draw_border and/or #draw_foreground to have more fine control (#draw just calls those three protected methods).
Yes, you'd have to monkey-patch the original Fidgit class, but since Container#combo_box(options, &block) just calls ComboBox.new(parent, options, &block) you could also either monkey-patch ComboBox#initialize or the Container#combo_box methods. Three options, then, but all monkey-patch based, so I can see they aren't ideal...
What I had considered, however, was that you could have an Element.container_method(type) that you'd call in your overriding class so that it would automatically add (or replace) the Shoesie methods. Avoids the requirement of monkey-patching, which is a good thing, though not sure it is the best way:
# Overriding the defaults.
class MyComboBox < Fidgit::ComboBox
container_method :combo_box # Replaces the default Container#combo_box.
end
# Creating new methods.
class MyComboBox < Fidgit::ComboBox
container_method :my_combo_box # Adds Container#my_combo_box, so you can still have access to the original type.
end
Thoughts on that?
By jlnr (dev)
Date 2010-11-05 17:32
I don't mind the monkey patching so much. In C++, I'd have given Button an abstract/missing draw() so that the user has to supply their look. In your lib, I also implement draw, except that I happen to delete the original implementation on my way. Not too horrible. :)
What bugs me is that I carry around lots of hashy things that I don't need. Usually my GUI is pre-rendered images all the way, not even using Font to label the buttons. (Yes, my game has a folder with lots of pre-rendered buttons. :)) But that is just me, and the Ruby ecosystem is full of stuff I ignore anyway. So that's not a very pragmatic argument from my side.
Ha, well, the defaults for Fidgit are actually just the settings I want for Sidney :) That might explain it! People can use those defaults, modify them a little bit with the hash arguments (or use a schema.yaml file, which I haven't implemented yet and maybe won't bother with) or override, which is their choice.
You aren't really needing to use the hashes if you don't need them (you can just completely ignore them in your initialization code and they will just default to {} anyway).
My reasoning for having lots of defaults is to ensure that you can come to Fidgit and make a simple GUI in about 37 seconds. You can worry about the presentation after you've got it working (and in LD, you just leave it as it is).
By jlnr (dev)
Date 2010-11-05 18:11
Hmm, I think that is an awesome thing about the hashes. Unlike having accessor methods for everything, they are a completely transparent channel from widget creation to #draw. Not only do they not bother me after I monkey-patch #draw, they actually can transport my own stuff.
The LD argument is definitely true.