ruby-****@sourc*****
ruby-****@sourc*****
2012年 12月 12日 (水) 15:16:56 JST
-------------------------
REMOTE_ADDR = 184.145.81.223
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dnd-intro
-------------------------
@@ -876,6 +876,6 @@
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.
+ 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.