ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 14日 (金) 08:20:08 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -882,7 +882,7 @@
The astute readers may have already noticed, it is not entirely true, that for widgets without "native DnD support" we get no help at all from Gtk system during DnD operations, and after the drop occurs. When we register either source or destination widgets, Gtk assumes certain responsibilities, such as monitoring the cursor and adjusting its appearance, and most of all, monitoring user's mouse movements and actions to which the Gtk reacts by emitting appropriate signals at right time and place, as well as driving the graphical presentation of either completions or premature terminations of the dragging actions. By now, it does not come to us as a surprise anymore that on the destination side the widgets without their own Gdk::Window respond to((*'drag-drop'*))signal. Each time a user drops the the dragged item on a destination widget this signal wakes up a callback, prepared by a GUI developer, on the destination widget. In the code, this is ensured, and defined with th
e 'signal_connect' call.
- When the 'drag-drop' signal is caught by the destination widget we have to remove the toolbar from its current (source) widget or frame, change its orientation and size properties, add (install) it to/in the new designation, i.e. current destination frame, and finally reverse the source and destination associations for newly arranged destination and source frames.
+ In this program, when the 'drag-drop' signal is caught by the destination widget we have to remove the toolbar from its current (source) widget or frame, change its orientation and size properties, add (install) it to/in the new designation, i.e. current destination frame, and finally reverse the source and destination associations for newly arranged destination and source frames.
At this point the current destination frame, which just got populated with the dropped toolbar, has to cease acting as the destination widget, and needs to register as the new dnd source. The current source and also just vacated frame, on the other hand, has to register as the new destination widget, and the new listener for the possible returning((*'drag-drop'*))signal.