ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 12日 (水) 15:09:54 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -866,3 +866,16 @@
# (10.2.2.3.2)
:'set_dnd_destination_frame_widget(htbframe, vtbframe)' method
+
+ At first glance the odd thing about this method may be the fact that we receive as parameters both frames. This will only become clear after we study the destination widget's (frame's) signal-handler. Indeed, for this we first need to set (register) the destination widget, i.e. our destination frame. When called the first time, from initialize method, this frame is the vertical and empty one on the left side of the window. For this registration we use the regular Gtk::Drag.dest_set method.
+
+ Gtk::Drag.dest_set(
+ widget=dest_widg,
+ flags=Gtk::Drag::DEST_DEFAULT_MOTION,
+ targets=TBDND_TARGETS, # [["toolbar", Gtk::Drag::TARGET_SAME_APP, 100]]
+ actions=TBDND_ACTIONS, # Gdk::DragContext::ACTION_ASK
+ )
+
+ There is nothing new about this method. We've seen it already in our 'button-to-label-dnd.rb' program. The difference is minor, namely, the token string and the info integer, though these are more formality than strict settings (we already said you can set them to anything you like, providing you use them consistently for both your source and the destination in each application). Another similarity with the previous "button-to-label-dnd" program is the use of the same actions constant. In fact you should notice also the similarity, how the actions (signal-handlers as well as signals themselves) are handled.
+
+ 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.