Apps Icon displays folders in filer window.

A very small didactic point about the RiscLua program. Note the added comment here:

g = act[ftype] ---<< note square brackets

if g then g (obj, level + 1) end -- if

ensures that filetypes not occurring in the act table cause no difficulties. This is a common trope in Lua and leads to more efficient code.

I quite understand that memory was expensive in the old days so that every bit had to pull its weight. But later filing systems (elsewhere) had all kinds of bells and whistles that could be used for making searches quicker: user-defined attributes, hidden files, linkages, etc. What is the consensus on hidden files? Useful idea or unnecessary complication?

RISC OS already has hidden files in a way, everything inside an application is usually hidden from the user.

RISC OS already has hidden files in a way, everything inside an application is usually hidden from the user.

That also includes !Boot. I’m not opposed to the concept. It depends on the purpose; Linux uses it to conceal configuration information for applications (amongst other things); we have !Boot, and the Apps folder concept for those scenarios. How else could it be utilised?

But later filing systems (elsewhere) had all kinds of bells and whistles that could be used for making searches quicker: user-defined attributes, hidden files, linkages, etc. What is the consensus on hidden files? Useful idea or unnecessary complication?

I am totally ok with it, as long as it’s standardised. One of the Desktop extensions I am working on in my usual little spare time, is called !PowerFiler and basically it’s a Filer replacement that uses “Unix Like” hidden files (files starting with a special character, right now I am just using a “+” symbol for debugging purposes).

The hidden files are used to store:

• Directory icon (yes a user will be able to customise also general directory icons)
• Directory Index
• Icon position on the !PowerFiler filer window, so finally (after 35 years lol) I’ll be able to position icons outside of a grid only structure in a filer window :)

Obviously, the filer replacement also will use tabs and tree-view as well as supporting drag and drop of files as the regular filer does and, if a file is dropped on top of a directory, it will be copied inside that directory.

As always, at some point, also !PowerFiler will be available for free and open sourced, no one is requested to use it or anything, so please no comments like “if one wants a Windows PC he/she can buy a Windows PC” thx. The reason I am mentioning this is also in answer to Andrew’s comment “how else it could be used”.

The thing that would be nice to have from ROOL/ROD, would be to declare a character as “special” for hidden files (or at least reserved), so that I do not go on my own way and then someone may have issues because they decided to call their file with that (non standardised) special character in front.

One thing I have tried experimenting with was to store all the info in a special DB used by one of the !PowerFiler prototypes, but it ended up to be convoluted and obviously one loses a directory metadata when the directory is copied on a different RISC OS system, so I abandoned this idea pretty quickly.

Bit 6 of the file attribute is/was allocated to Filer+ (Now FilerPro). Why not just use that attribute bit instead of a special character?

Bit 6 of the file attribute is/was allocated to Filer+ (Now FilerPro). Why not just use that attribute bit instead of a special character?

Great point Richard! I completely forgot about Filer+/FilerPro, thanks a lot :)

FilerPro has led to Dave Thomas’s PhotoFiler, which is up to date and well worth a look.

The thing that would be nice to have from ROOL/ROD, would be to declare a character as “special” for hidden files (or at least reserved)

For obvious reasons I have always used a backslash (/) prefix for this.

if a file is dropped on top of a directory, it will be copied inside that directory.

I don’t recommend this unless the directory is automatically opened to signify success. There is a fundamental principle that every action in a GUI should give a visual confirmation of success or failure. This is also why drag & drop is superior to cut & paste. Cut & paste is fine if you are used to controlling the computer with the keyboard, but that is not what RISC OS is about. Not for me, anyway.

I don’t recommend this unless the directory is automatically opened to signify success. There is a fundamental principle that every action in a GUI should give a visual confirmation of success or failure.

I think I can have the directory opened, it’s just a bit more code to add when I’ll have time, the issue will be having a solid approach to understand when the user has “stopped by that specific icon” which means I’ll need to add a time consideration (because obviously there won’t be any specific action except the mouse pointer, in a drag/drop state stopped by a certain icon for xy ns, to identify I have to open the corresponded directory window if that icon is indeed a directory icon).

FilerPro has led to Dave Thomas’s PhotoFiler, which is up to date and well worth a look

Indeed, another source of ideas/concepts¹ to incorporate into something I feel sure Paolo intends to submit for merging into the base OS

¹ I’m pretty sure Nemo wouldn’t mind the idea behind ColourFiler being borrowed either. Obviously the code is a different thing, but then ask nice and that might be available.

I feel sure Paolo intends to submit for merging into the base OS

Steve, all my work is or will be released as Open Source and on github.com only, with licenses compatible with RISC OS sources and ROOL policies and directions. But, if any of my work will be incorporated in to the main OS is solely ROOL/ROD decision and on their own will. The same for everyone else that intend to use and/or incorporate my code in their own projects.

My changes to my RISC OS are mostly for myself to improve my own experience on it (the way I’d like to use it). Obviously, I am sharing the process and the sources with the community in case my work may be useful to others that are interested in it and may or may not have the technical skills to do it, but that would like to share their ideas on how to improve it and make it a bit more modern.

I am not part or collaborating on any effort that is directly used by ROOL/ROD or any other company. All my code is solely stored and shared on the RISC OS Open Source community on github.com. Whoever wants to use it is free to use it as long as they respect the terms of use and distribution licenses.

Apologies. Assumptions on my part, Paolo, and we all know the problem with assuming.

As you say, with the licence on the code, ROOL are free to incorporate all or part just as they could with any other block of similarly licenced code.

no problem at all Steve, just wanted to clarify my position, all good sir! :)

I don’t recommend this unless the directory is automatically opened to signify success.

I totally agree. When people at work complain that a file or a whole folder has vanished from the shared drive, and request it to be restored from backup it is almost always because someone else started dragging it, realised they had got the wrong one, and then inadvertently let go when it happened to be over another folder.

When people at work complain that a file or a whole folder has vanished from the shared drive, and request it to be restored from backup it is almost always because someone else started dragging it, realised they had got the wrong one, and then inadvertently let go when it happened to be over another folder.

You talking about my dad? Every time I’d visit I’d have to rationalise the file system structure as ‘files had disappeared’.

I can’t recall, has anyone been daft enough to replicate the Windows model of “the desktop is just another folder in the file system”?
Which is a nasty, nasty thing when you have user profiles replicating across networks.¹
Now if it automatically put the file into a network server location with a link to the file

¹ I always considered the labelling of the RO4.xx stream to be wrong on the multi-users setup. “Disabled”?? sigh. “All_User” or “Generic” please. “Disabled” conjures up visions of a location no can or does use.

I always considered the labelling of the RO4.xx stream to be wrong on the multi-users setup. “Disabled”?? sigh. “All_User” or “Generic” please. “Disabled” conjures up visions of a location no can or does use.

I did say that on the very first day I saw it, and it created an enormous amount of support enquires from people who didn’t think files used by the active boot sequence would be inside Disabled, or worse still deleted the contents thinking it wasn’t needed.

or worse still deleted the contents thinking it wasn’t needed.

Well, yes, that’s exactly what it implies. Stuff that might have been required but is not utilised in the current configuration (and by extension, could be removed if not necessary). Like Windows allows one to disable a driver.

If what I’m reading here is correct, that “Disabled” is a synonym for “Everybody”, then someone needs their head smacked repeatedly with the nearest dictionary…

Now, I don’t claim to be perfect with words, but that one is an error on par with saying “click the green icon” and then offering up two orange ones.

For obvious reasons I have always used a backslash (/) prefix for this.

That’s a forward slash.

A leading forward slash character is already used on RISC OS by tools like svn in lieu of a dot prefix, i.e. for hidden files, so we do have a precedent at least.

But what constitutes hidden? Hidden from the Filer, or from OS_GBPB without magic incantations?

I have some apps which do things to all the files in a directory except those whose names begin with /. !Infuse is an example. It is basically the mailmerge concept. Keep some things as variables (in this case strings beginning and ending with $) and then evaluate the variables with a content file specifying what they mean.

But what constitutes hidden? Hidden from the Filer, or from OS_GBPB without magic incantations?

Whether we go down the route of an attribute or a filename prefix¹, it should be the OS (Fileswitch?) which does the interpreting and apps should just read the info back from the returned lists of files. Just as we don’t identify apps by looking to see if the first character of the name is “!” (or not unless it really can’t be avoided), I don’t think software should be parsing the “/” and concluding “hidden”.

SWIs like OS_GBPB should return everything (at least by default), and leave it up to the caller to filter that down. Thus the filer can have a “show hidden files” option, search tools can choose whether or not to find hidden files, and so on.

¹ How do you do a hidden application, though?

A neater solution would be to give the Apps icon a writable icon via its own menu, above Open ‘$’, and pass the search string to a predefined search app that displays a clickable list of matched directories (pling or not) after the fashion of Steve Fryatt’s Locate (but without its many other options).

This sounds remarkably close to what Locate already does if you send it a search request over the FilerAction Plugin protocol and it has “Open search window” off in its choices…

The only thing missing is the ability to set the “Applications” constraint in the search, but it may be possible to use the flag word in the user message to extend the information passed across.

FilerAction Plugin protocol

@Steve
I knew that you had used this so that a RISC OS Select user can search directly from Filer’s menu. What are the chances that RISC OS 5 will get the feature?