Drag and Drop protocol

Is the drag and drop protocol specification in ‘documents→individual specifications’ still open for comments?

If so I’d like to propose the following change to do with autoscrolling windows.

4.1.3.2 Scrolling

When drag extending a selection the pause zone should be 0 and pause duration should be 0
instead of a quarter width pause zone and 0 pause duration as outlined in 4.1.3.1.

This means, for example, to extend the selection to the right in a writable icon you drag outside
the right hand side of the icon to make it scroll.

Similarly you can start drags near the edges of a windows visible area without causing a scroll

You need to ensure that the pointer can go outside the screen otherwise you won’t be
able to scroll a window/icon which is up against the edge of the screen.

This will stop a writable icon scrolling when you start a drag on the right hand side of the icon
and scroll to the left – problem outlined in section 4.1.3.3

When dragging and dropping the pause zone/duration is as outlined in the document.

Comment by all means – as far as I’m aware, nobody’s started work on it. I haven’t been able to find time to do so myself at any point in the 14 years (ouch!) since I originally wrote the spec.

Details like the ones you’ve highlighted are what I’d consider to be things that would likely need a bit of polishing and tweaking once it’s written and you have chance to see how well it works in practice.

The history of all this stuff is that it was originally developed by Iota for DataPower 2, and that remains the “reference implementation” of the drag-and-drop user interface, even though Acorn later incorporated much of the information into its Application Notes.

The drag-and-drop specification I wrote was in part an attempt to more fully document the way the user interface works, but needed some deviation from DataPower where its user interface was lacking. IIRC, icons with overflowing text was one thing which was particularly unusable in DataPower, and given the frequent occurrence of that in Wimp icons, I tried to design a scheme which would work better, and ideally be able to re-use the autoscroll code already in the Wimp.

I have no idea how well it would work as I described, though I’m a little sceptical of how well a zone of 0 as you describe would work, because you could never see what was coming until after it had scrolled past you. I believe the ideal user interface would minimise the amount of mouse travel, and mandating overshoot like that sounds problematic – though I’m happy to be proved wrong if and when this stuff ever gets written!

Thanks for the update. The specification has an October 2007 date so
thought it was relatively recent. I’ll go back to the Acorn
application note. We can at least standardize how autoscrolling
works for RO5 applications.

Regarding a zone of 0. When extending a selection just because I
drag near the edge of the work area doesn’t mean that I want it to
scroll. By having the scroll zone outside the visible area I can
choose when to scroll and when not.

The pause zone in the filer is so small it may as well be 0.

Look at how autoscroll has been implemented in Draw. (Selection
only)

1) If you have the centre part of a drawing nicely positioned in the
visible area and drag a selection over it if you go near the edges
it scrolls so have to go back and reposition the scroll bars when
you’ve finished.

2) Because the scroll is proportional to the distance from the edge
of the pause zone if I start the drag very near the edge of the
visible area it scrolls uncontrolably as soon as the drag starts.

3) You can’t drop anything accurately in the pause zone because it
moves the work area so you have to dip into it to scroll and move
back to position accurately – exactly what you would have to do with
a pause zone of 0 except that you effectively lose the pause zone as
a usable part of the visible area.

Had the pause zone been 0 I could drag to the edge and over the edge
if I wanted a scroll.

I note that Draw only implements autoscroll for selecting – probably
with good reason as having a pause zone would cause problems – I’ll
have to try adding a pause zone 0 to all drags in Draw when I’ve
finished with Edit to see how it works.

I have to admit, I completely agree with everything Colin posted above.

Opening a blank document in Draw, positioning the scrollbars in one corner and clicking and holding in the other does indeed produce a very large and uncontrollable scroll.

I think pause zones are a bad idea, full stop, because as Colin points out they effectively make that area of the document worse than useless, since they’re effectively a no-go area and if you accidentally stray into them you have to start all over again. The best solution is to carefully scroll so that the area you want is in the middle beforehand, which completely defeats the point of autoscroll in the first place.

A particularly nasty facet of pause zones is the Grandmother’s Footsteps you inevitably end up playing with them if you only want to scroll by a small amount, which is usually the case.

I don’t think having to overshoot would be unintuitive – in fact, I think it would be more intuitive.

When dragging as part of ‘Drag and Drop’, where you can drag to another
program/window, you need the pause zone so that you can trigger scrolling by
hovering over it for about 0.5 sec. This allows you to drag to another
window by passing over the pause zone without triggering it. Conversely when
dragging into the window you can trigger the scrolling mode by hovering over
the pause zone.

However the pause zone should just be used to tell you that dragging outside
the window will start scrolling (scrolling mode) not to actually scroll when
the pointer is in it.

It would work like this:

1) You drag an object to the window and pause over the pause zone.

2) After 0.5 secs the pointer changes showing you are now in scrolling mode.

3) If you just want to drop you drop – no scrolling has taken place.
Otherwise moving outside the work area scrolls.

4) The scrolling mode is cancelled by either releasing the drag, pressing
escape or moving back to the part of the window which isn’t a pause zone.

I note that Draw only implements autoscroll for selecting – probably with good reason as having a pause zone would cause problems

I think it’s probably more to do with Acorn having written Draw several years before the drag-and-drop protocol was invented – and by the time the protocol existed, Acorn lacked the will to invest effort in further application-level development, with the notable exceptions of Browse and the RISC OS 4 Configure application, and even those were only allocated a tiny number of (then-)new graduate programmers.

Draw’s solution, of course, is to force the user to navigate the menu if they want to copy anything between windows. This is a pretty poor solution, which explains why pause zones were dreamt up. In general, I’m not sure that using Draw as a template for user interface is necessarily a good thing; it represents the starting point for about a decade of rapid user interface development in third-party applications, where different authors gradually refined the interface.

However the pause zone should just be used to tell you that dragging outside the window will start scrolling

Leaving aside for the moment the fact that this introduces an inconsistency in behaviour with the applications which already support the drag-and-drop protocol, this features one of my user interface pet hates – when some state has changed, but there is no feedback to the user that anything has happened (Ctrl+C to copy to the unseen clipboard falls into this category too, but it’s hard to get away from that, at least outside the RISC OS world). At the very least, I’d like to see something like a pointer shape change when you’ve waited long enough.

If I ever look haggard when someone asks me about drag-and-drop, it’s because of some prolonged and heated arguments there were within Acorn on the subject, with different people holding firmly entrenched and opposed viewpoints of how the user interface should work. Since I was tasked with the work, I had to draw up the spec and then sit through multiple review meetings, often lasting multiple days, where the arguments went round and round. The spec is as long as it is because it was requested at these meetings that all the details be put down on paper, not just from the application notes (that this spec was supposed to supersede when published) but also from surveying the various applications that already supported the protocol.

In the end, Phoebe’s cancellation meant that I got to write barely a line of code towards all this, even though I’d put man-months into the survey, documentation, and review meetings, and this is something I’ve regretted ever since.

If you’re seriously thinking of putting real effort into implementing drag-and-drop properly, and perhaps more importantly, consistently, across the RISC OS sources, then I see that as something to be welcomed. My recommendations are on record, take them or leave them. I’ll try not to let my personal feelings get in your way, heaven knows it’s the last thing you need when facing a task that large!

I disagree with everything Ben just said because it’ll annoy him a bit :) In truth, I too would welcome seeing this stuff finally implemented across the UI in a consistent manner. Legacy apps might be a problem but it’d be a great start to get the Wimp and the “ROM” apps supporting it – with other third party apps that are still under development able to follow their lead.

I agree with Ben about the need for feedback during the protocol. I would like to see the pointer change in the pause zone to the window’s existing pointer with a scroll indicator added to show that you can continue what you are doing or scroll.

Ben as you have been bored by this subject before :-) I’d like to ask if the following has been looked at and rejected.

The protocol you wrote says that the dragging message shouldn’t be claimed if you can’t drop under the pointer eg don’t claim if the pointer is over a margin in a text editor.

I have a DragDrop C library – it’s easier to develop that way, I’ll worry about non C programs later – plugged into risc_oslib via a wimpt_poll_filter function I added.

The program registers a window for a drop. As autoscrolling this window is linked to claiming the dragging message I think the registered window should always claim the dragging message and change the pointer to a maybe a stop sign if the pointer is over some part of the window which won’t accept the drop either because of icon,position or data type. This takes care of the situation where the part if the window that you can drop to is not in the visible area.

It would be nice if the drags from save boxes sent dragging messages then the target window, !Edit for example, could get rid of the dragged sprite (which is hiding the insertion point) and use a ghost caret for insertion. You would also get a stop sign in registered windows where you can’t drop.

Would have been nice if Wimp_DragBox DragASprite and DragAnObject could send out message dragging events.

Any thoughts – anyone?

The protocol you wrote says that the dragging message shouldn’t be claimed if you can’t drop under the pointer eg don’t claim if the pointer is over a margin in a text editor.

Whilst I might like to take credit for writing the messaging protocol, that was invented by Iota and used by various third-party software houses before Acorn adopted it, first in the application notes and then in my spec. You can tell that the clause about “dead” areas is long-standing because it isn’t underlined in my spec.

IIRC, the claim/no-claim distinction is mainly there as the means for sender and receiver to negotiate over which one of them owns the right to change the pointer shape and render object outlines and/or shadow carets. So I have no doubt that everything would still work if you claimed the message but put up a “no entry” sign or similar. Having said that, I think you’re shutting the stable door after the horse has bolted again – it’s never going to be practical to retrofit every application ever written to do likewise, maybe that’s why the protocol was written that way.

Would have been nice if Wimp_DragBox DragASprite and DragAnObject could send out message dragging events.

These calls all pre-date the drag-and-drop protocol by some years, which is why they don’t. Historically it was difficult to issue updated versions of the Wimp, and with a reduced installed base, application authors have been reluctant to use features added to newer Wimps, leading in turn to pressure to put new features in add-on modules like DragASprite or the Toolbox, rather than in the Wimp. But this is probably a good thing in terms of modularisation anyway, and I’ve always thought that the clipboard/drag-and-drop protocols are sufficiently complex and self-contained that they warrant having their own support module. Hence, the invention of SWI Clipboard_StartDrag, in section 5.4.2.2 of that spec, which does exactly what you’re asking.

It’s worth noting though, that although Fred Graute did some work on implementing the clipboard part of the Clipboard module a few years ago, I don’t think he ever got round to doing the drag-and-drop part. You might want to coordinate with him in that respect.

Colin wrote:

It would be nice if the drags from save boxes sent dragging messages… Would have been nice if Wimp_DragBox DragASprite and DragAnObject could send out message dragging events. Any thoughts – anyone?

Yeah – no. You can’t do that for Wimp drags as that’s already part of the (Insanely Complicated™) D’n’D protocol… so you’d be trying to do DnD inside DnD.

I’m leaning toward a far simpler protocol for non-DnD drags that in no way prevents ambitious applications from using DnD if they want.

But right now, and I write this with all the respect and admiration I have for the Usual Suspects, the DnD protocol is much too complicated. That’s why it hasn’t been adopted, and won’t be. :-/

Having had a good look at the DnD protocol I think the DnD protocol should be scrapped.

nemo wrote:

I’m leaning toward a far simpler protocol for non-DnD drags

There’s already a simpler protocol it’s called the data transfer protocol. The final nail in the coffin for the DnD protocol for me was when the drop required a sending a DataSave message instead of allowing either a DataLoad or DataSave as per the data transfer protocol making adding cut an paste/DnD from the filer awkward and making clipboard implementation difficult – it could have been ^C copies to file and ^V sends DataLoad at its most basic level.

I should have said “I’m leaning toward a far simpler protocol for VISUAL FEEDBACK DURING non-DnD drags”.