Filer enhancement

Would it be possible for the filer to be enhanced to include the RISC OS 6.10 and MS Windows abililty to drop files on to directory icons, thus allowing saving or moving of files in to a directory with out opening it.

In RISC OS 6.10 this is achieved by use of the Alt key in conjunction with the mouse keys. In addition Shift_Alt Select moves the file in to an unopened directory and also opens the directory window as well.

What a whopper of a misfeature! It breaks the fundamental criterion for a good GUI that every action should give visual feedback of whether it succeeds or not. Apart from that, directory icons are smaller targets than open windows. If RO 6.10 has this it strikes me as a shockingly retrograde step. That MS Windows might have it does not surprise me.

I’m a huge proponent of feedback, but perhaps you missed the last bit – the filer window would open after the drop. In addition, there would be highlighting of the directory during the dragging. This is much as it is in both Windows and various Linux desktops.

The problem with RISC OS drag and drop has always been that if you forgot to open a filer window, then you have to abort the operation, which this goes some way to addressing. For consistency, iconbar filer icons should be subject to the same behaviour, although without a generic filer handling these, this needs to be done on a per FS basis.

I generally dislike the way that filer windows on other operating systems are minefields, where you need to be careful (often very careful, particularly if a ‘small icons’/list-style view is selected) where you drop things. Having the feature activated using a modifier key, though, with Filer windows otherwise ‘safe’, strikes me as a good way to approach it.

If the directory window opens to receive the dragged object, so that you can see that the copy or move has taken place then I withdraw my remarks, of course. In copying or moving one wants to be able to see whether any objects with the same leafname are likely to be overwritten; that is another reason for wanting to view the contents of the directory before the action takes place.

The problem of objects being overwritten c/should be handled by whatever is sourcing the drag checking to see if there is something else with the same name – though as far as I can see, the Style Guide doesn’t mandate such behaviour.

However, that aside, the beauty of it happening only if a particular keyboard modifier is used is that it’s entirely up to the user anyway: if you are worried that this might happen, you don’t use the modifier. Simple.

Not having the correct Filer window open when you’ve started a drag is indeed a pain. The solution proposed alleviates this somewhat but if you don’t have the correct parent window open you still have to abort the drag or drop the files somewhere and then move later.

What would be useful is if you could navigate whilst a drag is in progress. Mac OS provides such an option through its ‘spring-loaded folders’, hover over a folder and it will open automatically. The problem with this approach is that if the pointer happens to be over a folder in the newly opened window then that folder would be opened as well which may not what’s desired. To avoid this a delay must be introduced before a folder opens automatically, but this makes navigating this way slower.

In light of the above I’d like to propose the following solution:

When the pointer is over a directory and Alt is pressed the directory opens,
if it's an Adjust drag then the parent directory is closed as well.

This has the following advantages:

- You can navigate whilst dragging
- There is clear visual feedback
- You're not dropping files blindly in a directory
- There's less chance of dropping in the wrong directory
- There's no additional delay as there is on Mac OS

Any thoughts?

That sounds good. Filing system icons on the iconbar would count as directory icons, I take it?

I vote for Fred’s scheme :)

Adam

And if you hover over the close icon, it opens the parent directory and closes the current directory ?

Tank

Filing system icons on the iconbar would count as directory icons, I take it?

Yes, ideally it should allow you to navigate to any directory regardless of starting point.

And if you hover over the close icon, it opens the parent directory and closes the current directory ?

Navigating back up is slightly less obvious than moving down. But hovering over the close icon and pressing Alt seems a logical choice. The current directory would be closed on an Adjust drag but not on a Select drag.

In that case it would be useful to be able to switch between select drag and adjust drag while the drag is in progress. To switch from a select drag to an adjust drag, maybe the user could press and hold the adjust button after having started the select drag, then release the select button to make the switch to an adjust drag?

‘spring-loaded folders’, hover over a folder and it will open automatically.

Nemo, are you seriously looking into this?

Oh, hi! Erm, yes. I am.

As a test I implemented the simple hack of making a modifier key act like a click during a drag. It works, but ain’t nice.

Doing it properly has parallels with the (insanely complicated :-p) drag-n-drop protocol, but obviously CANNOT be done using that method (phew!) as the applications may be doing that already.

So the approach I settled on was a new message sent by the Wimp during particular types of drag. If the task under the pointer ignores the message, no more are sent for that window (or iconbar icon). If it is acknowledged then they’ll keep being sent – every time the pointer moves or every ¼s whichever is sooner.

There is then a corresponding modification in the Filer (and only the Filer :-D). When it receives a hover message (H,I,X,Y,buttons,dragtype etc) it does the necessary to achieve these behaviours:

• Hover over a directory icon and it changes to an open one with a little arrow pointing into it. Dropping the file there saves into the directory (and the directory opens as expected).

• Hover for long enough over a directory and it opens in place of its parent (like Adjust-click)

• Hover over the close icon and its parent opens instead (like Adjust close) IF it has a parent.

The Filer is also able to attach PostFilters to its Filer helpers (as they register with the Filer during init) enabling it to convert a long hover over a device icon into a Select click on that icon. Cool.

The hover message must be done by the Wimp as a matter of course as we can’t tell what will subsequently turn out to be some kind of desktop transfer initiator. DragASprite alone won’t do. It has to work outwith the Filer because other apps (or Filters on those apps) may want to implement similar behaviour. It has to be orthogonal to the DnD protocol for obvious reasons.

I’ve been rather busy and haven’t written it yet, but I can see where to plumb it into the Wimp’s drag handling, and the Filer stuff is trivial.

This sounds great and I don’t think you’ll find yourself short of beta-testers when you get that far!

Hover over a directory icon and it changes to an open one with a little arrow pointing into it.

Would it be feasible to consider also (or instead) swapping the normal arrow pointer for an alternative appearance, e.g. one showing an arrow diving into a folder or something similar?

I’ll see how it works without. The Filer doesn’t have a sprite file of its own, so it’s a shame to introduce one just for this – and I’m not sure it’s a reusable visual concept. I’ll keep an open mind!

The Filer doesn’t have a sprite file of its own

OK – I didn’t know that.

a shame to introduce one just for this

It could also possibly be used for later adding a ‘+’ or something when moving files.

I’ll keep an open mind!

Me too :-)

It could also possibly be used for later adding a ‘+’ or something when moving files.

Ah yes, good point.

The Filer doesn’t have a sprite file of its own, so it’s a shame to introduce one just for this

I think the logic behind this (and other ROM applications) goes back to the days of machines with very limited RAM. If every ROM application had its own sprite file which it *IconSprited, then a load of RAM would be used to hold copies of these sprites. On the other hand, by lumping them all into the Wimp’s default sprite pool, they get accessed directly from ROM and don’t use up any RAM at all.

There could be an argument that the days of RAM being that precious are long behind us now, and maybe it would be better in terms of encapsulation and maintainability for sprites to be held alongside the module to which they relate, apart from generic sprites like ptr_default.

I’ve prototyped this now. Works quite nicely. It’s called “Hover”. Some discoveries:

• The dragged icon does obscure any modification of the underlying target but that’s not important {1}
• The automatic hover-click could be used to do almost anything (eg open a menu) but in general it’s not a good idea (eg menus don’t actually work when dragging!) {2}
• It’s probably only the Filer which will ever need to handle the new message {3}

1. There is a precedent – drop a file on a filing system device icon and the file gets saved into the root of that device and the destination opens. Note that this is already more feedback than Windows gives – it just swallows the file into the directory you dropped it on.

I have directories (whether open or closed) gaining a little arrow to show you’re about to drop something into it. It also has the side effect of indicating the imminent hover-click. Anyway, dropping the file onto a directory saves into it but also switches to that directory, which is somewhat clearer.

2. Automatic hover-click: The Hover message contains the current state of the mouse buttons as you would expect, but after a certain amount of time in one place (its actually the WimpAutoMenuDelay) these buttons get shifted left by 4 bits in the next message – this is a “Hover Click”. It is NOT a normal click. We do NOT want stuff affected by this that isn’t specifically designed to be.

This means the recipient task does not do any timing – it starts getting messages when a drag enters its territory (and if it doesn’t acknowledge it gets no more), it gets the Hover Click if you stay still long enough, it gets one final message when the drag moves out of its territory or ends. Thereafter normal Wimp messages prevail.

3. In principle any task could respond to a Hover Click on its icon by opening a new empty document into which one could then drop whatever we’re dragging. In practice though that would only be useful for applications which would have ignored the filetype if dragged to its icon but not when dragged to its window… which is a poorly designed program. Secondly, if you dither a bit about where you are going to drop the thing you could end up with empty documents opened from all your running tasks.

One could mandate a drag-has-ended message at which all those tasks would close the prospective documents again, but that’s all as ugly as sin. No, I think this is going to be a rare thing to implement.

Final thoughts.

From a UI design point of view, Hover is a time machine: it allows you to do what you should have done before dragging the file icon but forgot to, without having to stop the drag (this is disastrous for !Spriter for example). However, it must not be used to enable any behaviour that could not have been done in its absence.

Unfortunately, this draws attention to the other dreadful design decision that plagues RISC OS drag protocols: Keyboard modifiers are used completely the wrong way. But that’s a subject for a separate post.

BTW I’ve been using message &600D0 in the prototype because &400D0 is sadly already used.

Aside: RO keyboard modifier use during drags is WRONG

The drag-n-drop protocol mandates that (and many bits of RISC OS independently implement) the keyboard modifier keys being read at the point the drag starts and changes thereafter are ignored.

This is wrong, wrong, wrong. A drag does not occur when you get hold of the icon, it occurs when you drop it. Where you drop it dictates what will happen. Keyboard modifiers are, by definition, a modification of what will happen – which is only expressed when the icon is dropped!

This design is absolutely broken (as is the D’n’D protocol): The rule is that if you drag something within its “local” environment (eg from one view to another view of a single document) then that something is moved, unless you hold Shift. If you drag something to a different environment (eg from one document to another) that that something is copied, unless you hold Shift.

Here’s the misdesign: whether the entity will be copied or moved depends on where you drop it, but you have to decide where you are going to drop it before you start dragging, so you can predict whether it will as standard copy or move, so you can decide whether you should hold Shift before you start the drag.

Talk about needing a time machine.

The correct paradigm is for the state of the modifiers to affect the drag at the point it ends, within the context of where it is dropped, and preferably with visual feedback such as a modification of the pointer (the addition of a “+” for example).

Sorry, just had to get that off my chest!

Thanks for this, sounds like you’ve done some sterling work there! Looking forward to seeing it incorporated into the ROM image, along with Rik’s Filer Action window progress bar.

You may be right about the drag modifier keys, but there’s no way we’re going to be able to change this as the behaviour is determined individually in all the applications that implement dragging in any form. If any application, or the Filer, were modified so that shift could be pressed during the drag in order to perform a move, rather than being pressed from the start, it would be essential for there to be visual feedback, as many users will be used to being able to release the shift key after starting a drag, as at present, and still perform a move.

I disagree with you about the Drag And Drop protocol, however. The unmodified drag being move in the local window and copy if dragged to another window is the only way it could be implemented without being inconsistent with other long-established behaviours. Drag an object about in a Draw window? You expect it to be moved. Drag a file to another Filer window? You expect it to be copied. Too many other applications have replicated this behaviour for Drag and Drop to do anything else than specified. Personally I don’t find a problem with its use in practice. Usually when I begin a drag I know exactly where I am intending to drop the thing, and whether I want to move or not, and whether I need to hold down shift or not. The main thing I get wrong when starting a drag is not making sure that the destination is already visible, and that’s where autoscrolling of windows helps, and these various proposals for navigating into directories.

It’s probably only the Filer which will ever need to handle the new message.

I agree that hovering over an iconbar icon to open a document window is unlikely to be required, but what about hovering over window furniture to be able to bring a window to the front? This might be useful. Except it might be better achieved by using Alt-Tab to cycle through windows as is implemented by several desktop enhancement utilities already. And that, in fact, gives an example of where the user might want to release the shift key with which they started the drag, in order to operate Alt-Tab or Alt-Shift-Tab, and might forget to press shift again to effect the move (or copy)….

it would be essential for there to be visual feedback, as many users will be used to being able to release the shift key after starting a drag, as at present, and still perform a move.

True, but for new users (and returning ones who’ve in the mean time become accustomed to different implementations of functionality on other OSes) it could be argued that this should be reworked to comply with what is now the accepted norm. So perhaps it wouldn’t be unwise to work towards incorporating such visual feedback in the future.

The Style Guide refers to “a revised system of keyboard shortcuts more compatible with other non-Acorn systems” (pg.69, ‘Alt’ para).¹ IMHO GUI compatibility should be extended to other areas too – where it doesn’t drastically interfere with previously adopted and/or more intuitive methods. I’m probably not alone in believing this to be even more important in 2011 than it was in 1993 when the Style Guide was published. But perhaps it’s simply a matter of personal taste – in which case, maybe such things should be user-configurable if they are implemented.

¹ I think there may be a reference to the action of the Delete key too, but haven’t checked in detail enough to verify that. Obviously the “shift-when dragging” business is a little different but I think the principles are similar.

Nemo, this sounds like a great bit of work you’re doing. I’m looking forward to having a play around with it.

I’m not sure what I think about the modifier keys issue, but one thing I do know is that I’d really like a way of moving files using the mouse only. Is this something other people look for? I really haven’t got any good ideas yet about how it could be implemented to fit in nicely with the existing way of doing things, though… Sometimes I think adjust-drag should move a file, but I expect that would break with existing style.