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

Back to archive index

ruby-****@sourc***** ruby-****@sourc*****
2012年 11月 3日 (土) 03:24:49 JST


-------------------------
REMOTE_ADDR = 184.145.83.139
REMOTE_HOST = 
        URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-mnstbs-mnui
-------------------------
@@ -102,7 +102,12 @@
 
 {{image_left("mitems-n-submenus.png")}}
 
-Just as in our introductory example above also in the next example we expand our program from section [9.1] entitled: ((<Pop-up Menus|tut-gtk2-mnstbs-popup>)). Due to the complexity that is introduced by multi-dimensional menus this example is split into two parts. In the first part we build and implement a realistic menu hierarchy architecture, which you often encounter in real life applications, and in the second we add signal handlers and callbacks, to the code we developed in the first part. Indeed we continue to use the context menu from from section [9.1]. The difference is that now we added sub-menus. In our example programs here the menu hierarchy is built with the help of 'mk_submenu' helper method, which serves to build a sub-menu (note, that 'submenu' is an object of Gtk:Menu class). As you can see on the image here on the left, this time we have two levels deep menu hierarchy (context menu -> Test2 /menu/ (1st level) -> sub-sub-menu1 /menu/ (2nd-level)). Menu ite
 ms in every menu can be either (1) final "leaf" items, which trigger by the developer provided action when user selects such a leaf menu item, or (2) sub-menus for which Gtk default action is to open the menu assigned to the selected (non-leaf) sub-menu item in a cascading fashion, and usually no callback is specified for these sub-menu items by the developer.
+Just as in our introductory example above also in the next example we expand our program from section [9.1] entitled: ((<Pop-up Menus|tut-gtk2-mnstbs-popup>)). Due to the complexity that is introduced by multi-dimensional menus this example is split into two parts. In the first part we build and implement a realistic menu hierarchy architecture, which you often encounter in real life applications, and in the second we add signal handlers and callbacks, to the code we developed in the first part. Indeed we continue to use the context menu from from section [9.1]. The difference is that now we added sub-menus. In our example programs here the menu hierarchy is built with the help of 'mk_submenu' helper method, which serves to build a sub-menu (note, that 'submenu' is an object of Gtk:Menu class). As you can see on the image here on the left, this time we have two levels deep menu hierarchy (context menu -> Test2 /menu/ (1st level) -> sub-sub-menu1 /menu/ (2nd-level)).
+
+:Note:
+    The distinction between menu items and sub-menus a narrative can become blurry, graphics clears the confusion by placing a little arrow beside each menu item that is a menu. If you imagine the string '/menu/' in the narrative above represents the arrow the text may also become more clear. You may need to add visual aids like this to your documents, when you are planning or documenting menus with many sub-menus.
+
+Menu items in every menu can be either (1) final "leaf" items, which trigger by the developer provided action when user selects such a leaf menu item, or (2) sub-menus for which Gtk default action is to open the menu assigned to the selected (non-leaf) sub-menu item in a cascading fashion, and usually no callback is specified for these sub-menu items by the developer.
 
 
 'mk_submenu' can receive more than two arguments. The last argument must be a Boolean value, indicating whether the returned sub-menu should contain a tear-off menu item. All the arguments before the 'tearoff' Boolean argument are either leaf menu items, i.e. strings, or other sub-menus, which you should have previously created.




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