ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 11日 (火) 01:12:51 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -540,7 +540,7 @@
# (10.2.2)
== Dragging a Toolbar Within a Window (oo version)
-Let's first get out of the way the 'oo stuff'. There is nothing new in the preamble (the first three lines after '$:' line) here. With the exception of main window class name, everything we explained above under the title '((<Time To Start Using Object-Oriented Programming Paradigm|tut-gtk2-dnd-intro#Time To Start Using Object-Oriented Programming Paradigm>))' still holds here. Besides we are not extending our driving (main) class with the methods from our debugging module. One thing that needs our attention is the choice of the instance variables. As you see, we choose to use only two instance variables (@entry and @toolbar). All other variables in which we hold references to the needed GUI widgets are stored in local variables. The reasoning behind this choice is the ephemeral nature of source and destination widgets on one hand, and on the other the need to access variables holding references to Gtk widgets from other methods, namely, only entry and toolbar widgets are us
ed elsewhere. The ephemeral nature of source and destination widgets can be realized, when observing that after a user drags the toolbar from its original source location (frame), and drops it on current destination (frame), the two frames swap their source and destination designation, so the widget that is registered as source in initialize method every drag-and-drop operation starts to alter its source or destination association! In other words, the original source frame, after the first drop becomes the new destination, and the frame that used to be the destination before the drop now becomes the new source widget. Notice the difference between either of the two toolbar programs and the above 'button-to-label-dnd.rb' example. Here, the object we drag is the toolbar and the source and destination frames stay on their locations only they swap their source/destination designations. The point here is that an object being dragged may actually be a completely different widget t
han are the source and destination widgets, which most likely are container widgets holding the 'draggable' items. On the other hand, as we saw above in 'button-to-label-dnd.rb' example, the object we drag is simultaneously also the source widget. There are many different scenarios we can come up with, for instance multiple source and destinations, as well as multiple objects to be dragged between them. Needless to say that we have to implement the actions that take place after their respective (drags) and particularly 'drops' for all widgets without native dnd support, and that different situations or dnd scenarios require different implementations of these actions. We can see this the two examples presented here in section 10.2.
+Let's first get out of the way the 'oo stuff'. There is nothing new in the preamble (the first three lines after '$:' line) here. With the exception of main window class name, everything we explained above under the title '((<Time To Start Using Object-Oriented Programming Paradigm|tut-gtk2-dnd-intro#Time To Start Using Object-Oriented Programming Paradigm>))' still holds here. Besides we are not extending our driving (main) class with the methods from our debugging module. One thing that needs our attention is the choice of the instance variables. As you see, we choose to use only two instance variables (@entry and @toolbar). All other variables in which we hold references to the needed GUI widgets are stored in local variables. The reasoning behind this choice is the ephemeral nature of source and destination widgets on one hand, and on the other the need to access variables holding references to Gtk widgets from other methods, namely, only entry and toolbar widgets are us
ed elsewhere. The ephemeral nature of source and destination widgets can be realized, when observing that after a user drags the toolbar from its original source location (frame), and drops it on current destination (frame), the two frames swap their source and destination designation, so the widget that is registered as source in the initialize method after every drag-and-drop operation alters its source or destination association! In other words, the original source frame, after the first drop becomes the new destination, and the frame that used to be the destination before the drop now becomes the new source widget. Notice the difference between either of the two toolbar programs and the above 'button-to-label-dnd.rb' example. Here, the object we drag is the toolbar and the source and destination frames stay on their locations only they swap their source/destination designations. The point here is that an object being dragged may actually be a completely different widget
than are the source and destination widgets, which most likely are container widgets holding the 'draggable' items. On the other hand, as we saw above in 'button-to-label-dnd.rb' example, the object we drag is simultaneously also the source widget. There are many different scenarios we can come up with, for instance multiple source and destinations, as well as multiple objects to be dragged between them. Needless to say that we have to implement the actions that take place after their respective (drags) and particularly 'drops' for all widgets without native dnd support, and that different situations or dnd scenarios require different implementations of these actions. We can see this the two examples presented here in section 10.2.