This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: DragDrop Part 5 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

We're almost done with the whole DragDrop discussion here. One final detail to go: DragDrop Visual Affordances.

About Face by Alan Cooper and Design Of Everyday Things by Donald Norman talk about Affordances

The word "affordance" was invented by the perceptual psychologist J. J. Gibson (1977, 1979) to refer to the actionable properties between the world and an actor (a person or animal). To Gibson, affordances are relationships. They exist naturally: they do not have to be visible, known, or desirable.

In our case, we want to make it easier for the developer (you) to let the user know what they can do when they are dragging and dropping. We (or I guess I should say, I) can do this by providing affordance methods that can be utilized during a DragDrop.

If you remember my examples from Part 2, there are many possible ways a widget might display a visual queue to the user that implies what the user is allowed to do.

First, is the cursor itself. The cursor can have a look like an arrow with something along with it. For instance, in Explorer, when you drag drop, the cursor has a transparent visual of the item being dragged: the icon and name of the file. Pollock will not go quite that far, although it would be nice. Pollock will provide a set of cursors for dragging that basically are an arrow with a little black and white "document" icon. For multiple items, it will look like a group of documents. For Copy operations, there will be a little plus sign in the body of the document icon.

The emphasis affordances are quite another thing. For list like widgets, the widget will provide a #dragDrawEmphasisForBetween: , and #dragDrawEmphasisForOver: (there will also be #dragHide... versions of each). The former will draw a dark line between two items in a list closest to wherever the current mouse point is. The latter will do a highlight of the item closest to the passed in mouse point.

Wait a minute, I hear you say, what if I want to do both in a widget, how do I know which to call. The DragDrop Session will help you there. It will provide you with it's own affordance method #draggingBetween, which will answer true only when you are within the bottom two or top two pixels of an item in a list. So you could write your #dragDisplayEmphasis: like this:

myDragDisplayEmphasis: aDragDropSession
	| targetWidget currentPosition |
	targetWidget := aDragDropSession currentTarget.
	currentPosition := aDragDropSession mousePoint.
	aDragDropSession draggingBetween
		ifTrue: [targetWidget dragDrawEmphasisForBetween: currentPosition]
		ifFalse: [targetWidget dragDrawEmphasisForOver: currentPosition]

As you might guess, the "draggingBetween" will only be true for list widgets when it is appropriate.

All widgets will also support a single pair of simple emphasis affordance methods: #dragDisplayEmphasisAffordance: and #dragHideEmphasisAffordance:. Each widget will react differently to this method according to it's wont (polymorphism!). For instance, a list widget, and entry fields will display a dashed line just inside their bounds. I'm not yet sure what a button will do, maybe it will slightly brighten it's foreground color... maybe it tool will display a dashed line just inside it's inner bounds. I'll decide that when I get there.

You can also ask the DragDropSession if extended emphasis (such as for a list widget) is available: #currentTargetSupportsExtendedEmphasis. When this is true, then the ..ForBetween: and ...ForOver: affordances will do something meaningful. If this is false, you will still be able to send the extended emphasis affordance methods, but they won't do anything.

Finally, we need to speak about Dropping. When you get the dragDrop: event (and after that, if the operation is a move, the #dragSourceMove: event related to the source widget), it is up to you to do the right thing. For instance, if you had a list of objects and dropped one or more into a list of strings (or other things), it is up to you to add the proper thing into the target widget (and on the move, remove it from the source widget). The DragDropSession will have all kinds of good information that you can get as to what is going on, such as the target widget itself, if there is a "between" going on, the index of the items that indicate the between position in the list, or if it is a text widget, the linear position within the text where the drop occurred and stuff like that. There will also be access to the dragged item or items. Remember, the widgets are dumb, it is you that has to be smart.

Over the last two years, I have laid out the details of how a mouse drag knows it's happening in my talks about Pollock. Basically it is a state machine. For completeness sake, I'll include the contents of the slides that describe that here:

For single select lists and widgets that have no multiple draggable thing, the following are the rule states

1. If you click on an unselected item, and you do NOT move the mouse more than 2@2 while you have the mouse down, nothing happens until you release the mouse, at which time the target item is selected.
2. If you click on an unselected item, and you DO move the mouse more than 2@2, the target item is selected, and you are put into Drag mode for that item if it is turned on, if not, the selection changes as you drag the mouse over successive unselected items.
3. If you click on a selected item and do NOT move the mouse more than 2@2, nothing happens until you release the mouse, at which time the target item is unselected.
4. If you click on a selected item and DO move the mouse more than 2@2, you are put into Drag mode for that item if it is turned on, if not, the selection changes as you drag the mouse over successive unselected items (as in rule #2)

For multi select widgets, the following are the rule states.

1. If you click on an unselected item, and you do NOT move the mouse more than 2@2 while you have the mouse down, nothing happens until you release the mouse, at which time the target item is selected. (Rules of Shift & Ctrl apply to "items" selected)
2. If you click on an unselected item, and you DO move the mouse more than 2@2, the current item is selected and any additional items you drag the mouse over get added to the current selections. (Rules of Shift & Ctrl apply to "items" selected).
3. If you click on a selected item, and you do NOT move the mouse more than 2@2 while you have the mouse down, nothing happens until you release the mouse, at which time the item is unselected. (Rules of Shift & Ctrl apply to "items" selected/unselected)
4. If you click on a selected item, and you DO move the mouse more than 2@2, you are now in Drag mode if it is turned on (Rules of Ctrl & Shift apply to move/copy mode of Drag, and not to selection modes), if not, rule #2 kicks in.

Well, that's about it. Now I actually have to write the code for all this! For those keeping track of Pollock's various releases, Production 1, which is being worked on as I speak, will only support drag and drop from/to ListBoxs, drop "onto" a Button, and drop "into" an InputField. Well, that's not exactly true. The whole system will support it. It's just that I only intend to certify these specific cases for Production 1.