Filer enhancement

Good point. I think I’m right in saying that >1 button can be detected at once. Therefore, if the modifier were to be considered after the drag is initiated, could Adjust mimic the Shift key?¹ This could take some getting used to, because the user would have to release Select while still keeping Adjust pressed, or the normal action would occur. Perhaps that wouldn’t be so intuitive – but trying it out could possibly give a better idea. I guess this would mean it wouldn’t be easy to move a file and also close the parent² but perhaps that’s not an especially common action.

¹ i.e. used in combination with Select

² unless Select were to become the modifier in that case, but that’d be just far too confusing

If there were a visual indication of what the drag was doing (Perhaps the pointer could change shape?), then maybe Adjust could be used mid-drag to toggle between move/copy? Not having to do finger contortions when you’re at the point of ‘dropping’ the drag would be good so accuracy isn’t compromised!

What does Adjust-drag do at the moment? Does it close the drag source after drag completion? (Sorry to ask- no access to RO machine at the mo.) If so, I agree with Trevor; I doubt that’s a very common action. But everyone uses their machine in their own way, so I could be totally wrong about that!

What does Adjust-drag do at the moment? Does it close the drag source after drag completion?

Yep.

maybe Adjust could be used mid-drag to toggle between move/copy?

Ah, to toggle, that sounds like a good idea! I think that its interaction with Shift would ideally need considering too, just in case.

@MatthewPhilips

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

I totally agree with that. A simple ‘+’ modification to the pointer is all that is required.

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.

You aren’t disagreeing with me, that’s exactly what I’d expect too. My point is only that the modifiers should be dynamic during drags, not a snapshot at the start.

Usually when I begin a drag I know exactly where I am intending to drop the thing

And, therefore, sometimes you don’t. ;-)

I agree that hovering over an iconbar icon to open a document window is unlikely to be required

Well you’re not agreeing with me. I think that IS required. However, it can actually be implemented by the Filer via a Filter (I reckon) due to the interesting Filer-startup protocol that Filer helpers implement.

what about hovering over window furniture to be able to bring a window to the front?

Now you’re straying into another UI limitation. Did I invent adjust-click on Back to bring to front? Dunno, I’ve had it for a very long time. I have context menus on all furniture that allows better control of the window stack too, but that doesn’t apply to dragging. I already have hover-click on Close to open parent in the filer, but hovering over the rest to bring to front (and Back to send to back) is rather appealing.

Excellent idea.

@WPBlatchley

Sometimes I think adjust-drag should move a file, but I expect that would break with existing style.

Windows has the rather ugly right-button drag that opens a context menu at the destination where you choose what it was you meant. In the spirit of “Adjust is like Select, but slightly different” that’s not entirely incompatible. Ugly though.

One could imagine the Filer giving you the choice of what an Adjust drag does, with the Windows-like “ask me” as an option, and your preferred not-copy/not-move (contextually) as another.

The Filer would have to be slightly cleverer – it currently deselects the targetted icon on the Adjust-click, then reselects it when the drag comes through. Deselection would have to be a release action to avoid that.

Yeah, configuration choice:

• Close source directory.
• Same as Select drag.
• Opposite of Select drag.
• Ask me after dragging.

what about hovering over window furniture to be able to bring a window to the front?

OK I implemented this and it immediately leads to further questions so I implemented some more details:

• Hover on back to send to back (necessary)
• Hover over window background to bring to front for apps ignoring the hover message (this is debatable but I missed it when it wasn’t there).
• Hover over scroll arrows to scroll (I haven’t implemented this yet but the other bits make this seem necessary)
• Hover on any icon to click for apps ignoring hover message (I know. I said I didn’t want this, but it’s sort of neat. I suspect this will have to be optional)

Still working on it, but it looks like a how-did-I-live-without-it feature.

Curious as to whether anyone’s currently working on the Filer?

I’ve got it into my head to write a replacement Filer. This would be a big project, so don’t hold your breath. But it would make adding these new features much easier, and also be part of the proposed move to reimplement parts of the OS in C (the current Filer is Asm).

I wanted to check no one else is working on something similar, to avoid duplication of effort.

I’ve got it into my head to write a replacement Filer. This would be a big project, so don’t hold your breath.

Can I steer your initial efforts to something which delivers filer related immediate gain but that is somewhat easier to swallow whole than the filer itself?

I believe there’s likely to be an SDFS for flash memory cards being conceived, and inevitably that’ll need an SDFSFiler to do its icon bar icon and stuff. In my analysis of the filing system roadmap one common complaint was that every vendor of every filing system has to endlessly reinvent their own ThingFSFiler.

Currently, most ROMs already contain ADFSFiler; SCSIFSFiler; RAMFSFiler; ResourceFSFiler and that’s just in ROM! No doubt SDFSFiler is also going to be needed.

Putting together a spec for one generic one so those 4 (soon 5) can be chucked away would be amazing. My random thoughts would be

• Multiplee instaniatable
• Maybe configured by a text definition like a message file, or maybe a SWI with some flags
• Or maybe scans FileSwitch for known filing systems at startup and clones itself based on a table
• Needs to have the superset of features – formatting menus, share menus, rename, quit, free – but can be selectively removed depending on the FS
• Deal with drives that come and go, like USB does

This isn’t me saying the Filer in assembler is a good thing! It’s me imagining a photo of a snake swallowing an egg versus a snake swallowing a cow. Swallow the egg first to get the energy to swallow the cow.

And don’t forget CDFSFiler.

However, I favour Rik’s approach. Having the filer in C, with a plugin architecture, and maybe designed so that simple applications can also use the filer without having to provide a filing system, would be great.

I can supply a full filer window replacement in Ada 95 source code if necessary, since I had to recode the filer for CDBurn…

@Rik

Curious as to whether anyone’s currently working on the Filer?

I believe much of the work has already been done by Graham Shaw

Never tried to compile or run it, but I understand it’s functional with a few things such as implementing Filer_Boot missing. Also, I believe it was meant to be a drop-in replacement for the RISC OS (4/5?) Filer module, not xxFS as described on this thread.

The implementing language used appears to be C++, not C – hope this doesn’t start a language war ;-)

Would it be possible for the new filer to have hooks there ready for a Recycle Bin type application too?

Whilst in this thread, what happened to Nemo’s ‘Hover’ implementation?

And don’t forget CDFSFiler.

Indeed I had. So there’d be a total of 6 ThingFSFilers in ROM, all basically doing the same thing over and over again.

Filer module, not xxFS as described on this thread.

That’s worth pointing out as from a user’s point of view they’re probably blurred into the same thing. To be clear: the thing that does the drive icon for each respective filing system is not the filer (slightly counter intuitive!).

Indeed. While I appreciate what people are saying about the XXFSFiler modules, this thread, and my current thinking, is about Filer enhancement. Shall we start a new thread to talk about iconbar FSFiler modules, as they are really a totally different thing.

My intention had been to start working on a new Filer module, possibly (probably) incorporating the UI changes discussed previously, and other features deemed desirable.

I’ll take a look at Graham Shaw’s stuff, I’ve wasn’t aware of that before now. Also Steffen’s filer window clone might be interesting, although my intention was to use TreeView (which has a filer-like “flat mode”).

As a taster, here’s a screenshot of a UI prototype I’ve been working on. Now’s the chance to say “eww looks like Windows” :)

eww, looks like Windows! :P But since you’ll include an option to turn off the tree pane I don’t really mind.

One feature request for your new Filer – an improved search facility. The one in the current filer is a bit useless.

I think that looks great, Rik. Even if some don’t like it, it would be nice to have the option. And for new users coming from Windows (well, you never know!), it would probably be a big help.

Would this interface allow for selections that cover multiple locations? That’s something I’d really like to see, though I have a feeling it would require more extensive changes than just to the Filer? It would be very useful in its own right, but it would also then be possible to create a selection of all files that failed in copy operations (e.g. that were skipped). This would be very helpful, if you could then either open filer windows for all offending files, or create a text list of them or the like, for manual sorting out later. Sometimes when copying a large number of files, it’s a real headache trying to keep track if the odd one fails for whatever reason. Straying back into FilerAction here, I suppose. But the selection principle is still applicable to the Filer.

Then there’s the issue of some sort of plug-in architecture to allow more info about specific filetypes to be displayed. Track / artist fields for music files, etc. That sort of thing.

A status bar showing the result of the last operation to complete would be nice too: “20 files copied from ADFS::0.$.FromHere”

These are just a few random thoughts I’ve had every now and then and scribbled down. Feel free to ignore them, of course!

Ok I’ve read this thread through several times, and I think I’ve condensed the wish list for a new Filer to the following. Please comment and I’ll update the list as required.

• Optional directory tree display in left hand pane
  • Tree can optionally display all objects or just directories
  • Right pane optionally shows all objects or just files
  • If tree pane closed, right pane shows all objects
  • Selections can be dragged to / from either pane with equal effect
  • Right hand pane acts as much like a classic filer window as possible

• While dragging a selection (ie copy or move)
  • Feedback via dragged icon or mouse pointer as to copy or move
  • Pressing / releasing Shift at any time changes copy / move
    • The state of Shift when the selection is dropped dictates the action taken
    • Allow adjust click during drag to toggle copy / move ?
  • Hovering near the edge of a pane scrolls that pane
  • Hovering over directory icon shows visual feedback of impending copy/move
  • Pressing Alt while dragging
    • over a directory icon opens that directory
    • over an iconbar filing system icon opens root (this is not part of the Filer itself)
• Pressing Escape cancels the drag

• When a selection drag is released
  • Over the right hand pane, copy/move to that directory.
  • Over a directory icon (only in the tree?) copy/move to that directory.
    • and then open the destination directory.
  • Over iconbar FS icon, copy to root and open root (current behaviour)

• Previewing of file contents
  • Some sort of plug in protocol to allow file preview modules to be added
  • Where would the preview appear? In a pop up window? Another pane?

• Recycle bin hook
  • Delete operations are actually provided by Filer_Action
  • Perhaps if a recycler was registered with the filer, instead of calling Filer_Action to handle deletes, the messages would simply be sent to some other module.

• Improved search facility
  • Search by file type / date / size / contents
  • “Find” operations are actually provided by Filer_Action

Sounds a good specification.

* Recycle bin hook
* Delete operations are actually provided by Filer_Action
* Perhaps if a recycler was registered with the filer, instead of calling Filer_Action to handle deletes, the messages would simply be sent to some other module.

Would this still work for overwrites? I currently use Recycler, which is handy for trapping overwrites as well as deletes, but it’s not 32bit (and occasionally fatally unstable). Also, would this work for non-desktop filer operations such as *Delete etc.? (I know, the moon on a stick would be handy too!)

As always, the situation is slightly more complicated.

The Filer farms out delete / copy etc operations to Filer_Action, if the CMOS bit corresponding to “make Filer operations multitask” is set. If the bit isn’t set, I suspect the Filer itself issues *delete, *copy etc commands. It also falls back to this behaviour if Filer_Action fails to start for some reason.

A hook in the filer to send deletes to a recycler app wouldn’t trap overwrites, because those are the result of copy / move operations handled by Filer_Action. So to provide this feature, we’d have to add recycler hooks into Filer_Action as well. I don’t see why that shouldn’t be done though.

Whether trapping low level *delete commands is a good idea I suppose depends on what your idea of a “recycle bin” is. Is it an extension to the GUI or to the filing system? I’d say the former, which I think will be easier and safer to implement and probably provide what 99% of users expect from such an app.

I think trapping overwrites is essential, it’s all to easy to eg. save a file out of Draw, Edit etc. and overwrite a previous file (well, it is for me anyway!). Would this be covered by a hook in Filer_Action, or would it need something at a lower level?

eww, looks like Windows! :P But since you’ll include an option to turn off the tree pane I don’t really mind.

Shouldn’t it be an option to turn it on? The status quo being the default.

As a taster, here’s a screenshot of a UI prototype I’ve been working on. Now’s the chance to say “eww looks like Windows” :)

Heh, I’m not sure what to make of that. I certainly think it looks a bit too “heavy” with all the clutter in the treeview pane. The RISC OS filer has always been very lightweight.

It can be de-cluttered a bit by using triangles instead of those Windows style boxes, and by removing the lines in your mockup:

In fact, it’s pointless to have both the directory icon and the treeview furniture conveying the same information (i.e. whether the directory is open). So, since the treeview only shows directories and not files, we can just use the directory icon as treeview furniture. Here’s another modified version of your mockup showing that:

That looks cleaner now. It would be better to use the drive name for the root node, I think.

* Previewing of file contents

That either needs to cache the results or be optional, since it can be very slow.

How about:

• More efficient redraw

For example, when downloading a file, we don’t need to redraw entire filer window each time it updates. Just redraw the file size and time stamp areas for the updated file if in Full info display mode.

Also:

• Change Full info and Small icons display modes so that files are ordered into columns first, rather than rows.

@Andrew Conroy – trapping file overwrites when an application saves data can’t be done in either Filer or Filer_Action – they aren’t involved in the process at all.

@Michael Drake – thanks for the comments. The appearance of the tree can be changed (by the programmer I mean) simply by changing the gadget flags. Getting rid of the “expand icons” and the lines does look cleaner.

When I’ve had more time to work on this I’ll probably release a semi working prototype – ie a test bed for the UI rather than a functional Filer, so people can play and give feedback.

As we found with the Filer_Action redesign though – ask 10 people and you’ll get 10 opinions :)

trapping file overwrites when an application saves data can’t be done in either Filer or Filer_Action – they aren’t involved in the process at all.

Ah, I feared as much. It’s certainly one of the features of Recycler that I find most useful, although I guess new users won’t expect it as the Windows equivalent doesn’t trap overwrites. I wonder if it can be built-in to something at some point though. I guess Recycler must hook onto OS_File or something similar.

@Michael Drake — before you ask for the litle plus signs to be removed from the tree view and just relying on the directory icons, remember that we’ve also got to cope with image filing systems, so Zip files might appear in the tree view, I assume. There is currently no standard arrangement for specifying an icon for an image file which is “open” like there is for directories. So we’d have to think about whether it was important to be able to show this or not.

Obvious things missing from wish list:

• keyboard navigation
• “Delete” item on menu optionally to be shown in red

Basically need to look at QuickFiler, or whatever it is called (I don’t use it myself) and make sure all that functionaility is included, so the guy who looks after it doesn’t have to keep releasing new patches.

Previewing of file contents

• If a substantial number of the files are images, it would be good for the thumbnails to appear in the right pane, though whether any indication of file type would be useful (e.g. the small version of file icon superimposed) I don’t know. These thumbnails clearly need caching somewhere, as happens on RO Select I believe.
• Someone further up the thread suggested display of other info, like track length for audio files, and this could be extended to metadata from any filetype via plugins. There would have to be awfully good configuration available to turn it on/off so that users can choose exactly what they like displayed.

Improved search functionality
I think RO Select allows the search to be provided by third party apps, and this is what we should do here: Steve Fryatt’s Locate is ideal: no point rewriting it. If better hooks are needed to integrate it, I’m sure he’d be happy to provide you with a specification.

And the big one for me would be this. I usually view directories with Large icons. Sometimes I switch to full info, and then every directory you open after that (icluding Apps, of course), displays with full info. Can you change it so that there’s a global config for what the user prefers (in my case, Large) and that selecting a different style applies just to that directory and not to any others you open afterwards.

Not sure how this sits with use of treeview, though, which I’d undoubtedly turn off! I can see if you had tree view on, you might want the display type state to persist.

Select introduced a feature so that sorting files by name semi-intelligently dealt with numbers, so that you’d get File1, File2, File10. Nice idea, but I think this needs to be a seperate sort option (sort by .. number) as it gets very confusing trying to find a file which has hex numbers in the name.

If you do decide to implement a further pane to display file metadata, preview etc., then it would be good if it allowed setting access attributes (e.g. locked, public read/write) direct as these are fiddly to get at now.

I think I’d welcome a file pane more than a treeview pane, to be honest.

And if you do have treeview, can shift-right-click on the main close icon still open the parent: I would not be able to teach my fingers not to do that!