Drag and Drop protocol
Colin (478) 2433 posts |
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 This means, for example, to extend the selection to the right in a writable icon you drag outside 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 This will stop a writable icon scrolling when you start a drag on the right hand side of the icon When dragging and dropping the pause zone/duration is as outlined in the document. |
Ben Avison (25) 445 posts |
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! |
Colin (478) 2433 posts |
Thanks for the update. The specification has an October 2007 date so Regarding a zone of 0. When extending a selection just because I 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 1) If you have the centre part of a drawing nicely positioned in the 2) Because the scroll is proportional to the distance from the edge 3) You can’t drop anything accurately in the pause zone because it Had the pause zone been 0 I could drag to the edge and over the edge I note that Draw only implements autoscroll for selecting – probably |
Martin Bazley (331) 379 posts |
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. |
Colin (478) 2433 posts |
When dragging as part of ‘Drag and Drop’, where you can drag to another However the pause zone should just be used to tell you that dragging outside 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. 4) The scrolling mode is cancelled by either releasing the drag, pressing |
Ben Avison (25) 445 posts |
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.
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! |
Steve Revill (20) 1361 posts |
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. |
Colin (478) 2433 posts |
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? |
Ben Avison (25) 445 posts |
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.
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. |
nemo (145) 2529 posts |
Colin wrote:
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. :-/ |
Colin (478) 2433 posts |
Having had a good look at the DnD protocol I think the DnD protocol should be scrapped. nemo wrote:
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. |
nemo (145) 2529 posts |
I should have said “I’m leaning toward a far simpler protocol for VISUAL FEEDBACK DURING non-DnD drags”. |