ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 14日 (金) 08:16:10 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -880,7 +880,7 @@
Despite, the differences between the algorithms that handle actual placing and vacating of the source widget from source location to the destination location in the two programs, the underlying concepts including which signals drive the actions are identical. In both cases we do not care about signals on either source side (DnD system takes care of that, namely, managing the cursor appearance), and in both cases on destination side, we are listening for the same ('drag-drop') signal, which triggers albeit different, but logically very similar GUI rearrangement actions, which, by the way, in both cases we have to implement ourselves (this is why we say that widgets without the Gdk::Window are widgets without "native DnD support").
- 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.
+ 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.