ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 14日 (金) 07:40:16 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -882,7 +882,12 @@
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 also 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 wi
th the '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. This is accomplished by what we earlier announced as a pseudo recursive call. At this point the newly populated frame with the dropped toolbar has to be registered as the new dnd source, and the vacated frame as the new destination widget, which also has to register as the listener for the possible returning((*'drag-drop'*))signal. This registration of the vacated frame as the listener is performed in the 'set_dnd_destination_frame_widget' method, hence this subsequent "pseudo recursive" 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.
+
+ 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.
+
+ All this is accomplished in the 'drag-drop' signal-handler connected to the current destination widget (frame), where the GUI widgets are rearranged or repositioned and finalized in the the auxiliary 'reverse_dnd_source_n_destination' method, in particular in what we earlier announced as a pseudo recursive call, where the newly positioned widgets are reassigned their source and destination designations, as well as the new destination is re-registered as the new listener for the possible returning 'drag-drop' signal.
+
:Why pseudo recursive call?