Filer enhancement

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.

True, I’d forgotten that. Since Zip files have an icon similar to a directory they could maybe have an open icon version too.

However, with all the treeview furniture clutter removed it is very clear, just from the indentation, when a node is open anyway. Also, with those Windows style node boxes, there’s only 4 pixels differently coloured to show the difference between “open” and “closed”, and all the clutter makes the indentation less obvious.

I can’t see how to quote things in this forum, but WRT the recycle bin, it would seem sane to have a consistent API across RISC OS versions (ROL and ROOL) unless there’s a good reason not to. So:

http://select.riscos.com/prm/desktop/fileraction.html

(this is what Recyclone uses)

it would seem sane to have a consistent API across RISC OS versions

It would be very dumb not to. (Anyone rememebr what happened when IBM decided not to make OS/2 completely compatible with win32?)

Especially since were there a significant success with RO 5 on the Pi, ROL might finally decide to make all their good work available to purchase for RO 5 users as an enhancement pack.

And I meant to say, that I second the idea of having the Filer offering an API to applications which want to use a Filer-like metaphor for non-filing system stuff.

We’ve already had the example of CD Burn, where the programmer’s time could have been saved rather than reimplementing the interface. Paint is another application which springs to mind with individual sprites within a sprite file. WinEd, the tenplate editor, offers a filer-like view of the windows in the template file. There must be many other applications which could use a filer-like interface. It would really speed development of this sort of software having the Filer do it for you.

Of course, there would have to be a comprehensive API, so that the application can indicate which types of operation can be supported, whether “sub-directories” even exist, what metadata are available. As such it may not be sensible to put this facility into the first release of a replacement Filer, but if it were designed with this idea in mind, it might save effort when it comes to adding it later.

And I meant to say, that I second the idea of having the Filer offering an API to applications which want to use a Filer-like metaphor for non-filing system stuff.

To be honest, that’s what the TreeView gadget offers, to a great extent. There hasn’t been a great deal of application code required so far to produce the example I posted. Both panes in that example are TreeView gadgets.

It would be great to be able to use standard filer windows in other situations. (Things like FTP and Zip programs, even the packager.)

A few more things that might be worth considering (forgive me if they’ve been mentioned already):

- RO Select-style in-place renaming, using a writable icon in the Filer window itself.
- Nicer filetype menu for “Set type >” menu option, listing common file types.
- Style Guide compliant “Copy >” and “Rename >” dialogues, with draggable icons.
- Allow dragging of “Rename >” file/selection to move a file/selection to a different directory (would allow moving of files without keyboard interaction).

As mentioned earlier, having the Display options on a per-window or per-directory basis would be great. There was an app that did this (I forget its name). You could even specify wildcarded paths to create lists of rules for how directories were displayed. (e.g. Directories called just “c” always came up with “Full info” selected.) But that probably doesn’t need to be in-built into the Filer, as long as the necessary hooks/service calls are there to let a helper app do the job without hackery.

- RO Select-style in-place renaming, using a writable icon in the Filer window itself.

We already have that, Alt-click on a filename and you can rename it in-situ!

We already have that, Alt-click on a filename and you can rename it in-situ!

Okay, sorry – didn’t realise. In Select (I think it’s a Select-only feature, but I’m not sure), you can rename a file by clicking on its name (not the icon) once the file in question is already selected. A sort of “long double-click” on the text of the filename if you like. Would be good to mimic that, too, for consistency. (Assuming we don’t already have that as well. If so, apologies for the noise!)

bq. And I meant to say, that I second the idea of having the Filer offering an API to applications which want to use a Filer-like metaphor for non-filing system stuff.

To be honest, that’s what the TreeView gadget offers, to a great extent. There hasn’t been a great deal of application code required so far to produce the example I posted. Both panes in that example are TreeView gadgets.

It’s not the TreeView aspect that I’m interested in! (After all, eww looks like Windows!) There’s plenty enough work in reimplementing what we currently know as the Filer, and it would be good to have that style of interface available as standard for other applications to take advantage of.

(How do you get bq inside bq, by the way?)

In Select (I think it’s a Select-only feature, but I’m not sure), you can rename a file by clicking on its name (not the icon) once the file in question is already selected. A sort of “long double-click” on the text of the filename if you like. Would be good to mimic that, too, for consistency.

I find this very irritating in Windows, as I often seem to get it by mistake. It would need to be very well implemented! And I can never manage to make it happen in Windows when I actually want it to.

I find this very irritating in Windows, as I often seem to get it by mistake.

Me too. IMHO that would be a very bad way to implement renaming in RISC OS.

I find this very irritating in Windows, as I often seem to get it by mistake. It would need to be very well implemented! And I can never manage to make it happen in Windows when I actually want it to.

Me too. IMHO that would be a very bad way to implement renaming in RISC OS.

Can I ask why? Is it just that you sometimes get it by mistake, or more? I don’t see any particular negatives to it myself. Have either of you actually experienced it in RO Adjust/Select? I only ask because I’ve never found it irritating in any way. I have on occasion found the Windows equivalent annoying, but I think that might be because there’s quite a delay in Windows from when you click over the name to when the writable icon appears. In RO Select, it’s instant.

Anyway, I’m not particularly bothered either way. I’m quite happy to use alt-Select now that I know about it ;) I just wanted to point it out since it makes sense to unify functionality with that offered by Select. But only when it’s good functionality – and in this case there seems to be some disagreement!

EDIT: Looks like it’s configurable under Select anyway. Perhaps that’s the way to go…

bad way to implement renaming

Again, user-configurable would be ideal.

actually experienced it in RO Adjust/Select?

I don’t recall using it, so will try it out some time.

Windows equivalent […] quite a delay

That sounds right. [Edit: appears to be 50-100cs.] Personally, I use F2 in Windows.

makes sense to unify functionality with that offered by Select

That makes sense to me too.

There’s an old list of desired filer enhancements here that could be worth considering.

WRT local filer display options, it’s Tony Houghton’s SmartOpenDir I was thinking of before. I also have a feeling RISC OS 6 implements local display options, I think using a hidden file. Tony’s utility doesn’t put any data in the directory itself AFAIR; it has a single global pattern file that matches full paths or wildcarded paths to determine how each newly opened directory should be displayed. Personally, I dislike the idea of hidden files, but I can see there are advantages to that approach. This is an example of where work on a new Filer would tie in heavily with the filing system bounties that Sprow worked on.

Another one, which hasn’t been brought up yet as far as I can see, is of Unicode filenames. IMHO, it would be short-sighted not to think about this at this time if the Filer’s going to be reworked anyway. The new Filer should allow for display of UTF-8 filenames. At the very least, it should be coded not to assume bytes==chars and to have hooks in place to transcode filenames between character sets, even if it doesn’t actually go the distance and implement everything from the first version, which might be a bit daunting!

I find the Select style file rename very irritating. I was in Select, and also have a languishing A9. I use small icon and full info filer displays a lot (also SmartOpenDir to do a lot automatically). I found it most irritation when selecting some objects and then dragging. The filename is the most obvious bit to click on, and then you find the drag hasn’t happened – instead the file (name) you used to start the drag is sitting there waiting to be renamed.
It may be fine if that is all you have been used to, but the alt-click of RISC OS 5 is more ‘intentional’.

@ Matthew Phillips

It’s not the TreeView aspect that I’m interested in! (After all, eww looks like Windows!) There’s plenty enough work in reimplementing what we currently know as the Filer, and it would be good to have that style of interface available as standard for other applications to take advantage of.

That was my point – the TreeView gadget, despite its name, provides both a tree style view and a Filer-like view.

I shall peruse the points make and update the provisional spec accordingly, thanks all :)

@ Rik Griffin

Ah, I get the point. I suppose I’d have to use the Toolbox to be able to use the gadget though!

@WPB

Interesting to see the suggestions on acornusers.org cover most of the things suggested here. A few caught my eye:

• plugin system to allow extra menu items
• a new menu with directory and zip file on (this could of course be extended to act like Windows with applications offering a means of creating empty files of other types, e.g. empty text file, empty EasiWriter document. Perhaps a command line option would have to be used, like for printing, as the app may not be running.)
• commas in the file size on the Info submenu, or even show both the size in bytes and size in K, M, G etc.

And one problem I sometimes have was articulated, but no real solution suggested, which is the problem when you’ve carefully selected a load of individual files to move them to anotehr directory, and then realise you forgot to open the destination directory window, and lose the selection in the process of doing the clicks to open the directory. Don’t know how you fix that in a RISC OSsy way. Copy/paste would be one way, I suppose. Or having the selection remembered for every open Filer window and reactivated when it got input focus back? Not sure.

It’s going to be a long wishlist!

It would be a good idea to check Thomas Olsson’s FilerPro for more filer ideas. I know I tested it back in the 90s, and it was great. Can’t remember any details unfortunately ;-)

Ah, I get the point. I suppose I’d have to use the Toolbox to be able to use the gadget though!

IMHO, if you’re not using the Toolbox, at least for new applications, you’re making a whole lot of work for yourself. It really is much easier than using the Wimp directly. And if you need to do something out of the ordinary you can always call the Wimp anyway.

I’ve read all the suggestions here and on the acornusers.org page, and updated the provisional spec accordingly. Some of the ideas would actually need work on other components, mainly Filer_Action. I haven’t added everything to the spec, it’s not a brainstorming list, it’s a list of what I/we feel would be reasonable to implement at this stage. And I’ve marked the more speculative suggestions with a ‘?’.

• 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

• Display settings can be saved on a per directory basis
  • Display settings (for directories whose settings are not saved) are inherited from the parent Filer window?
  • Have a “Make global” option in the display settings menu?
  • Possibly saved in some central location (Boot:Choices.Filer)
• Hotkeys
• File information – nicely formatted size
• Filer_OpenDir extended to select object[s] and make them visible in the viewer? For better ‘View’ option on Filer_Action’s Find.
• Better “Set type” menu (via plug in?)
• Share directory from Filer menu

• 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? Thumbnails?

• Support for Unicode filenames

• Recycle bin hook
  • Delete operations are actually provided by Filer_Action
  • Copy the Select Filer_Action extension scheme?

• Improved search facility
  • Search by file type / date / size / contents
  • “Find” operations are actually provided by Filer_Action
  • Copy the Select Filer_Action extension scheme?

• configurable file associations?
  • ie when a file double clicked, send the DataLoad message to a certain application (if running) before broadcasting it…?

A few thoughts:

It is worth looking at ROX for ideas.

Configurable filerbooting would be nice. (e.g. limit it to specified drives or filesystems or folders)

If it turns out to be much larger, could it be split into an optional part (loaded from boot) and a core part?

Will it be softloadable for 3.x and 4.0x?

@Rik,

You’ve done a stirling job there of combining all the wishes and ideas – good work. Bet you wish you hadn’t started the thread now, don’t you? ;)

Someone mentioned FilerPro above. There’s a list of features here.

Configurable filerbooting would be nice. (e.g. limit it to specified drives or filesystems or folders)

Is this to avoid excessive filer booting on slow drives? Or a security concern? Perhaps the Filer could just provide hooks to give 3rd party apps the opportunity to halt filer booting? A service call, for example. Something like the BackBoot utility could be extended to make use of that. I’m all for keeping the Filer itself fairly lightweight, but thinking through the possibilities now so that legitimate hooks can be put in place to allow extensions by 3rd parties.

Another thing: Perhaps shortcuts and how to handle them need to be considered as part of this Filer revamp? There’s an old thread here about package managers and how they have to put things in a particular known location that’s quite interesting.

Can I ask why? Is it just that you sometimes get it by mistake, or more?

I frequently get it by mistake in Windows – all the more because I tend to configure filer windows to show all the details, so the icon is tiny, and the file name is much larger; despite all the years I’ve used it like that, I still have it happen several times a day.

I maintain that any multiple-click mechanism to rename a file is a Bad Idea. A click with a keyboard modifier is fine. Adjust-click is fine. That’s because these actions are not normal actions, or slight re-timing of normal actions, so they can’t be invoked accidentally.

I frequently get it by mistake in Windows – all the more because I tend to configure filer windows to show all the details

Dave, thanks for the feedback. I’ve been playing around with this, and can confirm it is very irritating if you make heavy use of the full info display settings! Now I know about it, Alt+Select is much friendlier. (I see it’s been around for a while; can’t believe I’ve missed it all these years!) So if others did want this particular bit of Select functionality in there, I’d agree that it should be turn-offable!

>Configurable filerbooting would be nice. (e.g. limit it to specified drives or filesystems or folders)
Is this to avoid excessive filer booting on slow drives? Or a security concern? Perhaps the Filer could just provide hooks to give 3rd party apps the opportunity to halt filer booting? A service call, for example. Something like the BackBoot utility could be extended to make use of that. I’m all for keeping the Filer itself fairly lightweight, but thinking through the possibilities now so that legitimate hooks can be put in place to allow extensions by 3rd parties.

I was thinking of when you are trawling through a backup drive, for example as a current issue, and security as a potential major issue, if RISC OS on Pi is a success (for example).

I envisage a simple wildcard system in configure, with a few sensible presets. (e.g. apps, local drive(s), optical drives, removable drives, network, image, all) But maybe that should be replaceable, by hooks with a more comprehensive system.