Filer plug-ins

Something I’ve wanted to see for ages is a new Filer menu option, for example it might be “Extensions” and lead to a submenu listing a number of extensions. If you don’t have any, then the “Extensions” option would be shaded.

Each extension will be a program or script (e.g. Obey file) living within some allocated location (such as, !Boot.Choices.Filer.Extensions or something). When selected, the extension is executed (*Run) with a command line such as:

  -s <obj> <obj> [<obj>] - selected objects if multiple items are selected in window
  -f <file>              - file if only single file is selected in the window
  -d <dir>               - selected directory if it's only thing selected in window
  -d <dir>               - directory over which filer window was opened (nothing selected)

There are loads of possible things an extension could do:

• Open a task window with the appropriate directory set to the CSD
• Run an MD5 checksum of a specified file
• Open an email with the selected object(s) as an attachment
• etc, etc

You might even arrange the ‘Extensions’ directory with subdirectories so that extensions can be sorted into classes, e.g. compression, encryption, graphics, utilities, etc. These would appear as further submenus in the Filer’s Extensions submenu.

I’m sure the purists will complain about how RISC OS is drag-and-drop so you should load applications and drop selections onto them, etc. I say there are a endless times I would want to do things the above way and I can’t stop thinking of useful extensions.

I agree – this is a great idea and I can think of lots of uses for it. It sounds similar to Mac OS X Services menu – only far better, as this would be contextual under the mouse pointer, as opposed to having to move the mouse all the way to the top left hand corner of the screen and access the application’s menu, then the Services submenu, then the actual Service required. (This ultimately means that I never use(d) it).

Yum.

Would there be any capability for the extensions to be context-sensitive? i.e. to be able to specify that certain extensions only need to be shown/enabled when you’ve got files of a certain type selected.

Unfortunately I can’t think of any situations where I’d want/need to use extensions – I guess I’m more of a drag-and-drop man – but I’m certainly not opposed to the idea of adding it to the filer.

Also I feel that I should point out that an “open task window here” extension would at best only be marginally faster than choosing “Set directory” and hitting Ctrl-F12 ;)

Mac OS X Services menu

Leopard supported Automator plugins (thereby giving access to anything driven by AppleScript or any other arbitrary scripting language of choice via the Unix shell) for the Finder, accessed from the context menu. Snow Leopard has a similar thing but promotes these all to the services concept – services relevant to files are thus available from both the Finder’s global service menu and the context menu. They’re actually “first class citizens” in Snow Leopard, appearing in the context menu root rather than in a submenu. It’s all much more accessible.

You can find an example in the screenshots of Add Folder Icons at:

http://pond.org.uk/osx/add_folder_icons/

Look for the section “The context menu”. So – although I don’t think Steve’s idea is quite the same as the system text services on Mac OS, it certainly does remind me very strongly of the Finder plug-in mechanism to which you also refer. I think it would be rather useful all in all; I also don’t see any reason why plugins shouldn’t be arbitrary runnable things, e.g. complete applications. Could come in handy (and might mean that some users simply use the plug-in mechanism as a quick launcher for frequently used applications).

On a related note, folder actions might work quite well on RISC OS since the operating system has upcalls for notifications when files or folders change. Folder actions on OS X are often a bit clunky despite the similar mechanism present ever since Time Machine was introduced. Perhaps those might be useful at some point too. For those who aren’t familiar with them, folder actions can be enabled on specific folders and cause some bit of code to run when the contents of the folder change. Common cited uses are for an Automator action which creates thumbnails of images as soon as an image is copied into the folder, actions which file things dropped into the Downloads folder into some more organised arrangement based on type (e.g. images into the user Pictures folder, music into Music and so-on) or a folder used for automatically creating e-mail messages with an added file as an attachment.

For those who aren’t familiar with them, folder actions can be enabled on specific folders and cause some bit of code to run when the contents of the folder change.

Now that would be something useful. Although really it would have to be done at the FileSwitch level rather than at the WIMP Filer level (so it works properly outside the desktop), and we’d need proper preemptive multitasking/threading support so the computer doesn’t freeze for short periods of time whenever your activity causes one of the actions to trigger.

Snow Leopard has a similar thing but promotes these all to the services concept – services relevant to files are thus available from both the Finder’s global service menu and the context menu. They’re actually “first class citizens” in Snow Leopard, appearing in the context menu root rather than in a submenu.

Mac OS X has had services since the 10.0 beta (and Nextstep before that) but my main gripe with them has always been that they’re just a pain to use so no-one bothers. Snow Leopard made them a bit better as they’re more contextual as you said – but the main benefit of implementing something similar in RISC OS would be their availability from the Menu button as opposed to navigating all the way across the screen and selecting from the Menu bar at the top of the screen (on a 27 inch iMac it becomes increasingly painful to move across all that screen estate).

You’re right though, Folder Actions is a far better analogy and something I used now and then but again I think it would be more useful on RISC OS - I don’t think they were done very well on the Mac.

Not exactly the kind of filer extension that Steve describes, but we need a way for image filing systems (and other non-FileCore filing systems) to be able to add/customise menu entries. An image filing system for an archive file format should show you the compressed size & compression type of each file, NFS mounts and other Unixy filing systems should allow you to see & edit the underlying unix file/folder permissions, allow you to see if a file/directory is a symlink, etc. Going slightly further afield it would also make sense to allow the extra metadata to be displayed in the filer window itself (i.e. with the ‘details’ display option) – although for something as in-depth as that we’d probably want to implement something similar to Thomas Milius’ Extended Attributes system so that the metadata is exposed to the rest of the OS through a consistent API instead of just being restricted to the desktop filer and filesystem-specific APIs (even if the metadata itself is likely to be filesystem-specific)