Where in the source code are filer windows implemented?

(I think the title says it all.)

It’s all here. There’s a lot of it! Were you looking for something particular?

It’s all here.

Thanks

There’s a lot of it! Were you looking for something particular?

Not really. I’m mainly (at least at this stage) curious as to how it works. Furthermore, am I correct in thinking that it performs file operations by issuing star commands, or are things more complicated than that?

You’re partly right: back when the operations were single-tasking it would issue star commands. But now that they are multi-tasking, it is more complicated than that. The operation gets sent to the Filer_Action module using a SWI instead. Here’s the code for doing a delete.

Filer_Action itself uses the SWI’s OS_File and OS_FSControl, rather than star commands. That all happens in this file.

I think I wrote the original Filer operations using star commands rather than SWI OS_FSControl so that someone (third party dev/a user) could implement a better *Copy etc. if they wished.

So am I right in thinking that:

The stuff in /RiscOS/Sources/Desktop/Filer/ implements the filer windows. These pass anything that needs doing to the Filer_Action module implemented by RiscOS/Sources/Desktop/FilerAct/, which generates progress windows (e.g. i.e. stuff like the copying progress window) and performs said actions?

And a couple more questions: Do all changes to the file system made by Filer go through FilerAct, or does it do some stuff directly? And is there any interaction with the file system that doesn’t go through OS_File or OS_FSControl?

As to the implementation, I notice that Filer is written in Assembler and FilerAct is written in C. Is this the state Acorn left it in, or has the latter been ported since?

The stuff in /RiscOS/Sources/Desktop/Filer/ implements the filer windows

and some of the desktop shortcut keys. Filer code is a participant in the WIMP spaghetti

and some of the desktop shortcut keys. Filer code is a participant in the WIMP spaghetti

Don’t those just call said code? Or are things so bad that the filer windows rely on the implementation of the shortcut keys?

The shortcuts sometimes rely on menu code, sometimes their own thing.
Keypresses are sometimes dealt with in Filer, sometimes in WindowManager and sometimes elsewhere, but no I don’t think the system relies on any of the shortcut code.
I found one chunk that made for a handy hook into the new directory creation – except Sprow cleaned it out as unused “cruft”

I can say that if you start looking deeply into the various elements of the WIMP spaghetti, you may find reality slipping away.
Keyboard management – “here be dragons”

Do all changes to the file system made by Filer go through FilerAct, or does it do some stuff directly?

I don’t know if there are any more, but I found directory creation at least is done directly.

And is there any interaction with the file system that doesn’t go through OS_File or OS_FSControl?

Reading directory contents uses OS_GBPB. If you drag from a save box into a filer window, it is up to the saving application how it does it; it could use the whole suite of FS SWI’s, or do something else entirely.

I notice that Filer is written in Assembler and FilerAct is written in C. Is this the state Acorn left it in, or has the latter been ported since?

It looks like it has always been in C. One less for us to worry about :-)

Even Acorn saw the light eventually.

Admittedly a little more might have been written in C back in the day had ROM-able PIC code generation been available in 1986/7.

And another question:

Are there any projects (in progress) to write a new version in C, analogous to Pinboard 2?

• An attempt was made to write the Filer in C++ under GPL. I never tried it, so I don’t know how accurate or complete it was, and the source links don’t work now (they did last year).

• A toolbox gadget was written to provide a filer-like view in applications, but not neccessarily for files. I didn’t try it out yet so I don’t know how complete it is. Also I can’t remember where it is. I thought I found it in the ROOL gitlab last year, but I’ve lost it. Can anyone remind me where it is?
  It had a comment in it about not being intended for use in the Filer itself…but I don’t know why, that would seem like a good thing to do with it?

• Paint must contain a partial Filer view implementation, with recent code added through the bounty.

(I think Steffen said he did a Filer view in Ada as well.)

So in essence, redoing the filer GUI¹ in C wouldn’t be pointlessly reinventing the wheel?

¹ I have no interest in the Lovecraftian horror that is file system itself.

An attempt was made to write the Filer in C++ under GPL. I never tried it, so I don’t know how accurate or complete it was, and the source links don’t work now (they did last year).

Could this be it? http://source.riscpkg.org/svnweb/Filer-Free/browse/trunk/filer

There’s an implementation detail which we should probably make sure any rewrite of the filer retains – the optimised item redraw order. This had a noticeable impact on the redraw speed on older machines (around 10-20% improvement – there’s some before and after stats, but they aren’t exact since there were some other optimisations made at the same time).

Other than that I’m not aware of anything particularly noteworthy about the current sources.

Have fun!

I have no interest in the Lovecraftian horror that is file system itself.

Wait ’til you see the keyboard handling.

(I think Steffen said he did a Filer view in Ada as well.)

CDBurn and CDVDBurn use a “pseudo filer” for its drag&drop ISO image creation. It mimics the filer really closely, but does not support the post-RO3.7 features like Alt-Click to rename.

I don’t have any free time at the moment, and the code is really ugly, but I could extract it and put it somewhere as an example of all the finer details of the filer visualization (and especially the selection-drag stuff) you can possibly get wrong.

Another question: Is there a distinct “put icon corresponding to a particular device on the icon bar” command, or is doing that part of the desktop spaghetti?

Another question: Is there a distinct “put icon corresponding to a particular device on the icon bar” command, or is doing that part of the desktop spaghetti?

That’s where things start to get a bit messy. The filesystem icon bar icons (& associated menus) are handled by the assorted “…Filer” modules. There’s an old thread that discusses the possibility of replacing the many (ROM-based) filer modules with just a single one: https://www.riscosopen.org/forum/forums/2/topics/815

ADFSFiler, SCSIFiler and SDFSFiler are all conditionally compiled from the same source code.

I’ve thought about using Toolbox for the XXXFilers, but it doesn’t let you reload your messages file after you’ve started which the current Filers do so that might be a problem. Also all the existing internationalisation is in messages files, and Toolbox does it in res files instead so it might be awkward to do¹. If Toolbox could be used though, it would cut down on some coding.

I should also say in response to the idea of all-filer-icons-in-one, I like the idea, and have thought about how it might work, but really there is a lot of code that is not in common between them – see CDFSFiler for instance.

One way (depending on being able to use Toolbox) might be to still have separate modules, and separate wimp tasks, but implement a generic filer icon as a Toolbox object. You’d then make MiscOp calls to that object to add any custom bits and bobs, e.g. please add a menu from my RES file as a submenu. The object can be configured in the usual way to either do a default action (e.g. left click opens whatever dir) or deliver custom event code.

re. The Filer, if it is possible to write it so that the directory view code can be used by other applications, that would be splendid.

¹ These problems apply to all the module tasks (Display manager, switcher…) though, so it would be worthwhile to do something here e.g. add a call to Toolbox.

re. The Filer, if it is possible to write it so that the directory view code can be used by other applications, that would be splendid.

By “directory view code” do you mean producing a graphical representation of what’s in a directory?

More or less – a lot of the filer is generic (i.e. you could show something other than the contents of a directory), and so was the Toolbox gadget I mentioned above (anybody know where it is??). Whether it’s possible to do this with Jeffrey’s optimised algorithm in place I don’t know.

Things that could be included in a generic viewer gadget

• Display a bunch of icons
• Have small/large/full with different texts
• Sort orders
• Renaming
• Menu depends on object
• Select multiple icons, with autoscroll
• Dragging objects out of the viewer
• Dragging objects into the viewer
• Per object interactive help

So in essence, redoing the filer GUI in C wouldn’t be pointlessly reinventing the wheel?

As long as existing code (Paint/CDBurn/Toolbox gadget/…) is used where possible.

I started writing a module viewer as an exercise last year which also does a fairly accurate filer-like display as far as it goes, with a view to turning it into a Toolbox gadget, but then I found the existing one and other jobs took priority so I haven’t done anything with it since then.