class MenuBar < Gtk::MenuBar
def initialize
super
# create menu buttons
show
end
end
class ApplicationWindow < Gtk::Window
def initialize
super
container = Gtk::VBox.new
container.pack_start MenuBar.new
container.show
end
end
So, when the menu bar gets clicked, a signal gets emitted in the Menu
Bar object. How can the Application Window object know that a menu
bar gets clicked? Do I need to create a new signal to notify the
Application Window?
So, when the menu bar gets clicked, a signal gets emitted in the Menu
Bar object. How can the Application Window object know that a menu
bar gets clicked? Do I need to create a new signal to notify the
Application Window?
Just define a handler for the signal that calls methods on the
application window object, either finding it based on navigating up the
widget tree, or just hard-coding:
class MenuBar < Gtk::MenuBar
def initialize(app)
super()
# create menu buttons @app = app
# here, connect_signal -- connect_signal('clicked') { @app.frob }
show
end
end
Below is the actual class, would appreciate suggestions on how I can
notify another object that the menu has been clicked. Or should I not
do things this way?
class MenuBar < Gtk::MenuBar
def initialize
super
# Create the File Menu
file_menu = create_top_level_menu "File"
create_menu_item(file_menu, "Quit") { Gtk::main_quit }
# Create the Scaling Menu
scale_menu = create_top_level_menu "Scaling"
for scale in World.instance.Scales # returns an array of ints
create_menu_item(scale_menu, scale.to_s) do
# Gets ran when the menu option gets clicked. how can i
notify other objects
# that it has been clicked?
···
On 7/21/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
I have something like this
class MenuBar < Gtk::MenuBar
def initialize
super
# create menu buttons
show
end
end
class ApplicationWindow < Gtk::Window
def initialize
super
container = Gtk::VBox.new
container.pack_start MenuBar.new
container.show
end
end
So, when the menu bar gets clicked, a signal gets emitted in the Menu
Bar object. How can the Application Window object know that a menu
bar gets clicked? Do I need to create a new signal to notify the
Application Window?
#
# Also, if I print out the value of scale here , it's always
the same, no matter what
# menu option has been clicked. Why is that?
end
end
# Show the Menu
show
end
# Create a top level menu
def create_top_level_menu title
top_menu = Gtk::MenuItem.new title
sub_menu = Gtk::Menu.new
top_menu.submenu = sub_menu
sub_menu.show
top_menu.show
append top_menu
sub_menu
end
# Create a menu item that goes under a top level menu
def create_menu_item menu, title, &action
menu_item = Gtk::MenuItem.new title
menu_item.signal_connect('activate') { action.call }
menu_item.show
menu.append menu_item
end
end
I forgot to mention that I had tried that already. I think there was
a problem with the super() call in MenuBar::Initialize as it was
passing the application window object to the Gtk::MenuBar initializer.
···
On 7/21/05, Aredridel <aredridel@nbtsc.org> wrote:
> So, when the menu bar gets clicked, a signal gets emitted in the Menu
> Bar object. How can the Application Window object know that a menu
> bar gets clicked? Do I need to create a new signal to notify the
> Application Window?
Just define a handler for the signal that calls methods on the
application window object, either finding it based on navigating up the
widget tree, or just hard-coding:
class MenuBar < Gtk::MenuBar
def initialize(app)
super()
# create menu buttons @app = app
# here, connect_signal -- connect_signal('clicked') { @app.frob }
show
end
end
This is the error I get if I pass app in to MenuBar:
file.rb:16:in `initialize': wrong number of arguments (1 for 0) (ArgumentError)
And line 16 looks like:
super
There's no arguments assocatiated with the super call.
···
On 7/21/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 7/21/05, Aredridel <aredridel@nbtsc.org> wrote:
>
> > So, when the menu bar gets clicked, a signal gets emitted in the Menu
> > Bar object. How can the Application Window object know that a menu
> > bar gets clicked? Do I need to create a new signal to notify the
> > Application Window?
>
> Just define a handler for the signal that calls methods on the
> application window object, either finding it based on navigating up the
> widget tree, or just hard-coding:
>
> class MenuBar < Gtk::MenuBar
> def initialize(app)
> super()
> # create menu buttons
> @app = app
> # here, connect_signal -- connect_signal('clicked') { @app.frob }
> show
> end
> end
>
I forgot to mention that I had tried that already. I think there was
a problem with the super() call in MenuBar::Initialize as it was
passing the application window object to the Gtk::MenuBar initializer.
I forgot to mention that I had tried that already. I think there was
a problem with the super() call in MenuBar::Initialize as it was
passing the application window object to the Gtk::MenuBar initializer.
Is that the principle of Matz's least surprise coming up again? Cuz
it sure didn't meet JVD's principle of least surprise.
Joe
···
On 7/21/05, Aredridel <aredridel@nbtsc.org> wrote:
> I forgot to mention that I had tried that already. I think there was
> a problem with the super() call in MenuBar::Initialize as it was
> passing the application window object to the Gtk::MenuBar initializer.
>
But anyways, thanks for the response. Is that the common GUI idiom
for doing stuff like that?
···
On 7/21/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
What the.
Is that the principle of Matz's least surprise coming up again? Cuz
it sure didn't meet JVD's principle of least surprise.
Joe
On 7/21/05, Aredridel <aredridel@nbtsc.org> wrote:
>
> > I forgot to mention that I had tried that already. I think there was
> > a problem with the super() call in MenuBar::Initialize as it was
> > passing the application window object to the Gtk::MenuBar initializer.
> >
>
> Notice that I changed "super" to "super()".
>
> super passes all arguments on; super() does not.
>
>
>
>
>
Is that the principle of Matz's least surprise coming up again? Cuz
it sure didn't meet JVD's principle of least surprise.
Congratulations, you get to retrain your neural net.
There are good reasons for the distinction here. Frequently (I might
dare to say: most often) you want to pass the same args on to the
parent's method.
But sometimes you need more control. In fact, there is no guarantee
that the two methods will even have the same arity.
So you get to pass whatever you want. If what you pass is "nothing"
then this is a special case -- you have to surround the "nothing"
with parentheses: super()
What the. Is that the principle of Matz's least surprise
coming up again? Cuz it sure didn't meet JVD's principle
of least surprise.
Congratulations, you get to retrain your neural net.
There are good reasons for the distinction here.
Frequently (I might dare to say: most often) you want to
pass the same args on to the parent's method.
You frequently need to do this to other methods as well.
So I think it would have been both more useful and less
confusing to invent a piece of syntax for passing along the
same arguments to another method. Something like this:
def foo(bar, baz, *rest, &block) super(...)
# Do additional stuff.
end
def bar(baz, quux, *rest, &block) @moomin.bar(...).postprocess
end
I'm not trying to stir up trouble; I just wanted to let Joe
know he's not the first person whose PLS this doesn't meet.
But sometimes you need more control. In fact, there is no
guarantee that the two methods will even have the
same arity.
So you get to pass whatever you want. If what you pass is
"nothing" then this is a special case -- you have to
surround the "nothing" with parentheses: super()
And that looks really strange if you're not familiar with
this language quirk. One of the most basic facts you learn
about the Ruby syntax is that ‘foo()’ equals ‘foo’.
···
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.
