ruby-****@sourc*****
ruby-****@sourc*****
2012年 10月 28日 (日) 02:20:26 JST
-------------------------
REMOTE_ADDR = 74.14.158.59
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-mnstbs-statb
-------------------------
@@ -210,12 +210,35 @@
+{{br}}
+When working with signals we usually have to be concerned about the callback block parameters that are passed along when a callback is invoked. Especially when we use a single callback method for more than one different signals, like in our((*statusbar_hint*))method, we should rely on these parameters to identify which event occurred, and most likely which device (in our case menu item) emitted it. Both the((*'enter-notify-event'*))and((*'leave-notify-event'*))signals pass the signal emitting widget, as well as the event object whose type or class is Gdk::EventCrossing, the subclass of Gdk::Event class. This event object will provide us with the information, that will allow us to define whether we are dealing with a cursor entering or leaving a menu item. To identify whether the event was emitted by an entering or a leaving cursor in our signal handler callback we employ the Gdk::Event#event_type accessor method retrieving either Gdk::Event::ENTER_NOTIFY or Gdk::Event::LEAVE
_NOTIFY event id value.
+If you remember we have created two different categories of status bar's stack messages, namely the temporary messages which we also call hints, and the more permanent application state messages. The former, menu hint messages, are created in 'create_popup_menu' method, where we store status messages in a hash using menu item's name as the key, and processed in the signal handler callback method called 'statusbar_hint'. And the latter 'application state messages' are maintained and managed in 'pulse_activated', 'fill_activated' and 'clear_activated' methods.
+Note however, that eventually both of these two categories of messages identified by the 'StatBarHints' and 'CurrentStatus' strings respectively, end up, though not in our case, nevertheless potentially intermingled, on the same status bar's message stack. The rendering of these status messages is managed exclusively by pushing and popping the messages from this stack, where you always have to identify the massage context id:
+ cntxt_id = sbar.get_context_id("CurrentStatus")
+ sbar.pop(cntxt_id)
+ sbar.push(cntxt_id, "Pulsating")
+or
-When working with signals we usually have to be concerned about the callback block parameters that are passed along when a callback is invoked. Especially when we use a single callback method for more than one different signals, like in our((*statusbar_hint*))method, we should rely on these parameters to identify which event occurred, and most likely which device (in our case menu item) emitted it. Both the((*'enter-notify-event'*))and((*'leave-notify-event'*))signals pass the signal emitting widget, as well as the event object whose type or class is Gdk::EventCrossing, the subclass of Gdk::Event class. This event object will provide us with the information, that will allow us to define whether we are dealing with a cursor entering or leaving a menu item. To identify whether the event was emitted by an entering or a leaving cursor in our signal handler callback we employ the Gdk::Event#event_type accessor method retrieving either Gdk::Event::ENTER_NOTIFY or Gdk::Event::LEAVE
_NOTIFY event id value.
+ cntxt_id = sbar.get_context_id("StatBarHints")
+ if event.event_type == Gdk::Event::ENTER_NOTIFY
+ sbar.push(cntxt_id, hints[menui.name])
+ else
+ sbar.pop(cntxt_id)
+ end
+
+
+:Hint Status Messages:
+
+ To identify the menu item's hint status messages in our 'create_popup_menu' and finally in the callback 'statusbar_hint' method, we had to do some preparation work at the time when menu items were created. First we assigned the name to all our menu items by calling Gtk::Widget#name= on these objects. As mentioned above we use this name in two places: (1) 'create_popup_menu' method, and (2) in the callback - signal handler method (statusbar_hint), where we use this hash to retrieve the appropriate message, extracting the key for the hash entry from the signal emitting widget name, and then if the event type indicates cursor entering a menu item push it onto the status bar's message stack by first identifying its category or context id as 'StatBarHints', and finally when ((*'leave-notify-event'*))signal triggers invocation of 'statusbar_hint' method, we pop the message belonging to 'StatBarHints' category off the stack. Note, that before you push a message of certain cont
ext id onto the stack, there may have been other messages belonging to different categories with different context ids already on the stack. So despite very orderly behaviour of messages belonging to 'StatBarHints', namely, every invocation of push of 'StatBarHints' context id is always followed exclusively by the invocation of pop for the same context id, you can have messages belonging to 'CurrentStatus' category present on stack before you pushed onto it your 'StatBarHints' context id. When you pop the message belonging to 'StatBarHints' category, whatever was there on the stack before is then rendered in the status bar.
+
+:Application State Messages:
+
+ The application state messages are simple. They are hard-coded in their respective methods, and each time we are about to push a new message on the stack, we remove the previous message belonging to 'CurrentStatus' category.
+
-To identify the menu item's description status messages in our 'create_popup_menu' and finally in the callback 'statusbar_hint' method, we had to do some preparation work at the time when menu items were created. First we assigned the name to all our menu items by calling Gtk::Widget#name= on these objects. We use this name in two places: (1) first in 'create_popup_menu' method where we store status messages in a hash by using menu item's name as the key, and (2) in the callback - signal handler method (statusbar_hint), where we use this hash to retrieve the appropriate message, extracting the key for the hash enty from the signal emitting widget name.
+You have to be careful that you do not pile messages onto the stack, without properly removing them. Check our example program again to see that we are meticulously removing the messages for each of our two categories.