[ruby-gnome2-doc-cvs] [Ruby-GNOME2 Project Website] update - tut-gtk2-mnstbs-mnui

Back to archive index

ruby-****@sourc***** ruby-****@sourc*****
2012年 10月 31日 (水) 04:12:35 JST


-------------------------
REMOTE_ADDR = 74.14.158.59
REMOTE_HOST = 
        URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-mnstbs-mnui
-------------------------
@@ -234,6 +234,19 @@
 This seems like a reasonable plan, however, for a deeply nested menu hierarchies and many menu items, it will also require some planning, and more importantly, we will need to come up with a sensible naming convention for both menu items, and their respective callback procedures. Since this process in our GUI development will most likely be repeated over and over again, it may be a very good idea to, when developing our coding strategy, to perhaps start aiming to develop a 'Ruby Gtk Menu Building Design Pattern'. But let's not get ahead of ourselves here, and see how we can best implement what we've come up with so far. 
 
 
+:Menu Program Design Based On Hash Of Items and Callbacks
+
+    We start by creating the top context menu. This process is no different than what we have been doing so far, namely we code everything on this top level by hand. At this point we can also connect all final or leaf menu items with the((*'activate'*))signal: 
+
+     menu = Gtk::Menu.new
+     menutearoff = Gtk::TearoffMenuItem.new
+     menu.append(menutearoff)
+     menu.append(mitem1 = Gtk::MenuItem.new("Test1"))
+     menu.append(mitem2 = Gtk::MenuItem.new("Test2"))	# 'Test2' is the name for the 1st level sub-menu
+     mitem1.signal_connect('activate') { |w| puts "Wigget=#{w.class} - Test1" }
+
+    Here we define the top menu items. Naturally,  Note, that the second item saved in variable 'mitem2' is the sub-menu, hence no signal handling is required for this menu item. 
+
 
 
 




ruby-gnome2-cvs メーリングリストの案内
Back to archive index