This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: More DragDrop Rethinking Feed Title: Pollock Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml Feed Description: Pollock - the next VW GUI Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Pollock

From our internal developers list, Martin McClure comments:

Your example makes it clear why you want a drop target to get notification of mouse moves. However, I'm concerned about the simpler case, in which the widget wants to highlight when the cursor enters it dragging something, and un-highlight when the cursor leaves it, and wants to ignore mouse moves within the widget.

This is a lot of work that doesn't have to be done. If #dragDisplayEmphasis: was only sent on mouse entry to the widget, and #dragHideEmphasis: was only sent on mouse exit, this work wouldn't have to be done.

Martin, like Vassili before, is right

Whereas I seem to have to have made the DragDrop states more complex, the actual messages that get sent, how often and when didn't have to be as noisy and complex as I first thought.

Here is my new thinking: When a widget first enters a widget it gets the #dragEnterAcceptDrop:. Then as before, it gets a #dragDisplayEmphasis:. The scheme now changes. From then on, while the move is going on, only #dragMoveAcceptDrop: messages are sent.

If a #dragDrop: is sent while in the widget, then it is followed immediately with a #dragHideEmphasis:, and if needed because the drag is a Move drag, after that the #dragSourceMove:.

If a #dragDrop: is NOT sent while in the widget, then when the mouse focus leaves the widget, first a #dragHideEmphasis: is sent, and finally, the #dragLeaving:.

This eliminates ALL the extra dragDrawEmphasis:. and dragHideEmphasis. messages. You can just call the draw affordance methods for the widgets when you get the dragMoveAcceptDrop: method, if you want.

It then occurred to me that the dragDrawEmphasis and dragHideEmphasis affordance methods for the widgets could easily be smarter. So, I'm going to upgrade/change the behavior of the #dragDrawEmphasisForBetween: and #dragDrawEmphasisForOver: methods. I have decided to make it so that when you send either one, it is the only Over or Between emphasis on the widget. In this way, if you send the #dragDrawEmphasisForBetween: or #dragDrawEmphasisForOver: which would cause no change in the current emphasis draw, it does nothing. However, if you send either and a change is needed in how the emphasis is drawn, only then will the emphasis change and any prior emphasis will be removed.

Finally, yesterday night, while I was watching 24 I realized that my DragDrop state system had a flag in it that I hadn't explicitly talked about: Drag Enabled.

So, every widget will by default have a "Drag Enabled" flag, which will, by default, be false. Turning that flag on, turns on the ability to start a DragDrop Session in that widget.