Apps Icon displays folders in filer window.

Do you know what would really help correct people’s perceptions? A presentation about it where you can explain the ideas and demonstrate the current progress, say at a user group :-)

+1 And I was looking forward to Paolo’s talk and seeing what enhancements were in the pipe line. Select/RO6 all had great debates about the changes they brought to the OS so nothing new on that score.

I am not a programmer but on the concept and general design as I see it then my thoughts are why not extend what is already there, for example:

Directory has different icon or user defined one – Can’t File attributes be extended and then say in “PowerFiler’s” application you have a number of built in extra icons like one with a Document type slant and you also have a built in custom directory in that application that you can drop/make your own.

These can be added to the Resource pool when switched on.
All switchable via the Boot>Configuration plug in.

That way everything is contained in one place not spread around and no hidden files spread around.

HTML rendering could use a similar principle with an attribute for system or local wide turning on?

If you don’t want the enhancements you just don’t turn them on.

If you want a PhotoFiler type view than again set an attribute.

If everything is self contained then if someone changes or enhances the spec then you don’t need to change every hidden file if you need to expand but merely the file/directory attributes.

So I may be talking bxxxxxxt, most likely as I said I am not a programmer and have been corrected here on many occasions :-),but I think there is a way to balance moving forward as I and others want whilst retaining things for those that do not without a seperate distribution that ends up in another cul de sac and it is important to get the design principles right first before embarking on the road so debate is good as long as it is done in a constructive way.

As to GPL then I am inclined to agree stick with Apache so it aligns with the rest of the OS.

Finally, thanks Paolo for trying to move things forward as we need to do something and those that don’t then they still have the OS they love and can use that and they lose nothing apart from access to the features they don’t want.

But slightly more on topic, what is it with a certain group of people represented in this thread that they’re so unwilling to even try something new?

“There is nothing new under the Sun”. Well, there is, but in more than 30 years of using RISC OS I have tried many, many things. Been there. Done that. Got the T-Shirt.

Here are some more random thoughts.

I do not object to hidden files in principle, but I am wary. I remember LongFiles, that used a hidden file to store long filenames before these were part of the OS. The files themselves had cryptic, coded filenames. This worked fine until long filenames were in the OS and I found that there was no simple ¹ way to transfer LongFiles files and I had several directories full of apparent gobbledygook.

¹ I think there was a utility, but you had to find it.

I used Filer+ for quite while, but I think it was then a patched version of the Filer and vulnerable to OS updates. One feature I think it had and I would still use was local directory formats, particularly size and position.

Apps without ‘!’ was very attractive, but I stopped when I realised that I could read a Filer window faster with the ‘!’.

Directory icons also look attractive, but in combination with missing ‘!’ was very confusing. I have just been looking at my Windows 10 User folder, where every sub-folder has a special icon. This is no help at all and I have to ignore the icons and concentrate on the names to make sense of it.

If you want the whole ‘Linux experience’ you will want Links. I have tried a few RO implementations, including with hidden files. The only one I stuck with for any length of time was Martin Würthner’s SoftLinks, but I do not think he supports this now. This does not use hidden files, but does modify how the Filer works. I stopped using it when I started to loose track of original and linked files and managed to delete some important originals – my fault, not SoftLinks.

A year or so ago I wrote Discobolus to show read and write activity. This was most interesting as a programming exercise, but having done it I kept is as part of my !Boot. For a while I though I was getting useful information, but actually it was just a pretty distraction, giving the impression of something useful. There is a lot of this about in ‘modern systems’. ;-)

Directory has different icon or user defined one – Can’t File attributes be extended and then say in “PowerFiler’s” application you have a number of built in extra icons like one with a Document type slant and you also have a built in custom directory in that application that you can drop/make your own.

These can be added to the Resource pool when switched on.

All switchable via the Boot>Configuration plug in.

That way everything is contained in one place not spread around and no hidden files spread around.

HTML rendering could use a similar principle with an attribute for system or local wide turning on?

If you don?t want the enhancements you just don’t turn them on.

I like this idea much better then the idea of hidden files, it seems more in line with the way RISC OS works but with an enhancement.

If you want a PhotoFiler type view than again set an attribute.

If everything is self contained then if someone changes or enhances the spec then you don’t need to change every hidden file if you need to expand but merely the file/directory attributes.

Again I think this would be a better way of doing it, less hassle and more easily understood by ‘end users’. In fact IIRC RISC OS 6 (I know a dirty word for some) already had a good thumbnail display for Photos as part of the OS and was configable.

I am always happy to see improvements to the OS we use, like Pinboard 2, which I have been helping testing.

I also know we can not always please everyone all the time.

Paolo, I am not sure about your idea for system wide notifications, if they come anything like the ones in Windows they will annoy me. I see the idea but wonder what practical use they will be to an ‘end user’ again. You mentioned Messenger Pro in an example for there use, to let the user know an email has come in for a user, It already provides two options at least for this already, one is make a noise when new mail is received and you can get it to show which folder/mailbox it has arrived in (new arrivals option).

The important thing in all this is to talk and discuss ideas, so your talk would be a good idea to get a broader feel for your ideas/plans.

Thanks everyone for your comments and feedback.

In particular, thanks to Peter for this:

“we” are not anti-gpl, there’s plenty of opinions here.

To the others against GPL, if you do not like GPL, you probably do not like me either. In my life I was able to achieve all I did also thanks to the GPL. And today you ALL are able to have some much from computers also thanks to the GPL. So by being against it makes you just unaware of the world surrounding you, but I guess that’s a choice, ha! another thing that comes from freedom (thanks also to the GPL for this too!)

@ All the ones in favour of centralising a directory metadata in a single place:

Here is some insight of RISC OS design to keep in mind when answering (we all know them, but for some reason I can’t understand, people seems to keep forgetting about them on a per topic base):

- RISC OS is a heavily Drag’N’Drop based Desktop (please keep this in mind).
- RISC OS does NOT have a background centralised API to support Virtualised Drag’N’Drop operations. In other words to efficiently and successfully Drag’N’Drop an entity in RISC OS, such entity (especially in regards of the FileSystem) has to be self-contained

So, adding extra information of a directory (metadata) into a centralised place (let’s say !Boot.Choices) will force me to:

• Add more code to handle the correlation between such entity and what’s in !Boot.Chocies
• Intercept the Drag’N’Drop of such directory also with the regular Filer, in order to ensure there is a transitional copy of the metadata done on the fly and in that directory, why? because, of course, I need to understand SO MUCH CONTEXT about that drag’n’drop to, for example,:
  • pre-install such metadata in another !boot
  • or WHERE the user is copying such directory
  • or if WHERE is another RISC OS system or if it’s the same RISC OS System just a different path or disk
  • And more. If I don’t do this then the directory will be copied without its metadata and so the user may simply stop all together using the new filer, why bother? It doesn’t keep the configuration he/she has made previously!

Can you see how mad is the choice of centralising the metadata? No? Then keep reading

If I centralise the metadata then I need to have a place and a way to do such, let’s assume !boot or an equivalent unique point in the file system (for instance like we have !Packages I can add !PFCStore):

• I’ll need a DB-like structure that needs to be accessed every time a user open a directory to check if any of the subdirectories has metadata, this is going to be fun when this structure grows in size
• I’ll need to add means and ways to keep that structure up-to-date (and intercept even more vectors from the FileSystem , because a user may rename a bloody subdirectory using CLI for instance)
• What if that DB-Like structure gets corrupted? Oh don’t even get me started on the posts here of people losing their configured directory icon and or size etc…

So, yes, people who are in favour of the centralised data-point did not do a deep technical analysis of that, it’s probably because they have perceptions blinding their view (and sorry for being so direct, and maybe rude, but if anyone want to “mask” his opinion as a tech-analysis at least please have the decency of doing a tech analysis, tech-analysis are based on facts AFAIR).

But, I want to assume I am wrong, so let’s see the advantages of storing metadata on a per-directory base:

• Code and logic simplification, all I need to do is check if a subdirectory contains +DirCfg, yup that’s all it’s needed!
• Opening +DirCfg and using it, no need for seeking correlations
• When a user copy such directory, no matter how (even using 3rd party tools), metadata gets copied and the user does NOT lose the configuration
• If a user renames such directory, metadata do not lose any correlation
• If the user copies the directory via !OmniClient to a Linux/Windows/BSD machine no problem
• If the user zip the directory and send it in an email to his gran-mother, again no problem
• If a directory gets corrupted and so its metadata, the rest of all the other directories stays fine and so their metadata!
• If something gets corrupted one can rely on the usual tools checkfs, !DiskKnight and others
• Performance only degrade if a user has created MANY subdirectories all with metadata, this happens anyway on RISC OS if a directory contains a lot of objects (so would happen even in a centralised approach, however centralised approach performance degrade also if a user has created some directory with metadata)

Determine your conclusions, I did and so, no, I am not going to waste my time following some mad theory about centralising metadata, sorry. As pointed out well from Bryan, if you do not like it, don’t use it.

On the hidden files vs no hidden files

I already have explained the advantages of “hidden files”, so I am not going to repeat that. This message is mostly in answer to Bryan:

Do you know what would really help correct people’s perceptions? A presentation about it where you can explain the ideas and demonstrate the current progress, say at a user group :-)

Can you see? explaining the advantages has not changed anything, so I don’t think a talk would help. I think the only thing that may help is to complete the effort and share it as a distro for people to see how things would work and clean their view from the perceptions I am seeing.

Apologies for mentioning the term perceptions so constantly, but until someone can provide a reasons to avoid hiding these two files in my !PowrFiler:

+DirCfg
+DirIdx

from the user to avoid him to delete them indadvertedly via a Select all or via a quick manual selection, I can’t understand what technical reason there is behind the refuse of hidden files in my !PowerFiler. I also mentioned that if one uses the original Filer they will see them.

So, I think, it’s either my bad English (in which case a presentation won’t help) OR is people not paying attention (in which case the same would happen during a presentation).

So, again, I think, just having a “RISC OS Bleeding Edge” distro would be worth a thousands words, and make me happy because I would not have to re-explain the same concepts like 20 times :)

I think that seeing this actually working and having its benefits demonstrated may change perceptions of a few folk to having a couple of extra files present.

How would you avoid polluting certain directories with the config and index files? I have scripts which for instance happily use libfile to add *.o to a library.

+DirCfg, +DirIdx

I already have dirs like /subversion littering my system, would it make sense to adopt the same prefix?

@ All the ones in favour of centralising a directory metadata in a single place:

REGISTRY!!!

I would like to avoid hidden files on RISC OS, as we already have ways of storing config elsewhere, but we (especially developers) do run headlong in to compatibility with other systems, a specific example being GIT, which it is essential we integrate in to RISC OS. GIT relies on a hidden .git repository at the top of the repo directory structure and also other hideen config files such as .gitignore (/git and /gitignore in RISC OS parlance).

We could change this in the RISC OS port, but the further it gets away from the standard implementation, the more difficulty it will be to port it, and the more difficult it will be for users familiar with .git on other systems to use it.

Hiding these files in the filer would make development directories tidier, and also help prevent content searches including the .git directory which will generate lots of unwanted hits from the object files.

@ Rick

I said badly designed, not badly written. I’m not a fan of having everything hang off of / with a mishmash in /bin and /sbin and /usr/bin and /usr/sbin and so on.

Badly designed? That’s not what you meant, you meant “having a bad directory organisation” eventually. The design of the Linux VFS is outstanding IMHO. Linux can run reliable from an IoT device up to a Satellite, passing through PCs, smart phones and HPC data Centers. It’s incredible what Linux has achieved an dit’s FileSystem is just awesome.

And I’m really not a fan of a system where myfile.txt, MYFILE.TXT and MyFile.txt are three different things.

While I do respect this, I also need to point out that this is just an opinion, not a design fact. We have a similar situation in BBC BASIC don’t we? PRINT vs print ;)

They probably has less to do with the filesystem and more to do with the stability of the kernel. Linux was intended to be solid from the outset. Windows…not so much.

You obviously know that a FileSystem is part of the kernel and an actual VERY IMPORTANT part of each kernel, right? And the FileSystem reliability is as important if not more important than other kernel’s parts right?

they’re so unwilling to even try something new?

As you might have noticed from this thread and the numerous references to elsewhere, there’s a lot of sentiment around what is perceived as failings in other systems.

What Peter meant probably is try the approach instead of being against it “a priori” (by default if you want)

What is “failing on other operating systems”???? What you have described is YOUR OWN OPINION on what for YOU is failing on other operating systems, not an objective truth or a fact.

But anyway, this is the confirmation that there isn’t much to talk here or in a presentation.

Hiding these files in the filer would make development directories tidier, and also help prevent content searches including the .git directory which will generate lots of unwanted hits from the object files.

I would be happy to update !Find (i.e. the underlying tool) to optionally skip such RCS dirs. It would improve my life somewhat, especially as our current out-of-date svn port pollutes every subdir with /svn.

Can you see how mad is the choice of centralising the metadata?

I’ve not been following this part of the discussion… but no, just no.
The idea of centralised metadata was done, demonstrated, and provided by Windows’ much maligned Registry.
It got progressively better, but the Win32 versions were awful and the system would happily trash itself at random intervals.

So I completely agree, centralised data is a bit nuts when one considers it’ll be involved in every single file operation.

Better to keep metadata alongside the data. And, suddenly, we might have a valid use for hidden files.

if you do not like GPL, you probably do not like me either.

Whoa, that’s some world class troll bait right there. ;-)

So by being against it makes you just unaware of the world surrounding you

I’m not against the principle. I’m against the specific implementation. It is a licence that involves as much politics as technical content. It is heavily based around how Linux operates, meaning that that contentious things like the while “linkage” issue end up as undefined gibberish when it comes to something non-Linux (such as RISC OS). And of course there’s the issue of “if you use this with other code, that other code must be GPL”. This is a political argument.

I would like to ask you to look at the EUPL, especially the “interoperability clause” (section 5, IIRC). That is what a free and open licence should look like.

That is an absurd statement.

Indeed. It’s not that we’re “don’t touch or precious UI” or “no ideas not invented here”.
It’s more like we have experience with other systems, and can see how good ideas can be subverted.

@ Stuart

I think that seeing this actually working and having its benefits demonstrated may change perceptions of a few folk to having a couple of extra files present.

I agree, which is why I think complete the work and package everything is the best approach.

How would you avoid polluting certain directories with the config and index files? I have scripts which for instance happily use libfile to add *.o to a library.

It’s a user choice, it’s not automatic. In other words +DirCfg is added only when a user decide to customise a directory while +DirIdx is added if a user decides to use directory indexing (so this one is semi-automatic).

No directory indexing = no +DirIdx
No directory customisation = no +DirIdx

I already have dirs like /subversion littering my system, would it make sense to adopt the same prefix?

Yup that works totally fine for me :)

No directory indexing = no +DirIdx

Would it be possible to have something to define a pattern set in PowerFiler config ’Don’t descend into these directories’ for indexing? A bit like TortoiseSVN’s automatic exclusion list.

To the others against GPL, if you do not like GPL, you probably do not like me either.

Its nothing to do with you personally, just a lot of ‘techies’ do not want GPL in the main OS source tree, the Apache licence was chosen specificly for this reason. But your addons/features could be in GPL without affecting the OS source I believe (no doubt someone will tell me I am wrong!)

I don’t know if you were aware but RISC OS 6 has some directory specific settings already without AFAIK no hidden files needed.

It would be a pity not to hear your presentation on your ideas. All everyone seems to be doing is pointing out potential issues you might not thought of, and you did ask for feedback.

We do already have GPL components in the source tree, but need to keep GPL components out of the ROM.

For information, and not to push for one way over another wrt hidden files, there is some precedent for a centralised place for storing per-directory state:

• Tony Houghton’s SmartOpenDir
• Nemo’s ColourFiler

Perhaps the best way is to abstract the per-directory state setting/retrieving code into a module (that possibly other apps could use too), so if people really don’t like hidden files, an alternative database-like implementation could be written and it would just plug in to your code, Paolo. More up-front work to design it, but possibly a good thing to do in terms of modularisation of your code anyway…

Oh, and I wouldn’t cancel your presentation if I were you. Actually demonstrating something is a good way to win people over! ;) Keep up the good work!

Would it be possible to have something to define a pattern set in PowerFiler config ’Don’t descend into these directories’ for indexing? A bit like TortoiseSVN’s automatic exclusion list.

Yup definitely, need to add the code and test to see how things work out. something like:

[pseudo-code]

if DirIdx != present then

   use SWI to read directory content

else

   use DirIdx to read directory content

endif

I haven’t started yet to code the final prototype, so need to run few tests/models and see if it may need that in multiple places or not.

Its nothing to do with you personally,

While I understand what you mean, what I meant is that i profoundly believe in the GPL and, in more general terms, in Open Source software. That said, I am not an advocate, aka at work I am not somebody who pushes for it, there are other things there that matters as well. But in my free time I definitely embrace it as a philosophy as well.

So, I may become feeling the pressure of a community that doesn’t like the GPL, in which case, given the unpaid work, I would definitely prefer to produce my own distro without having all these limitations.

Hope this makes sense.

Oh, and I wouldn’t cancel your presentation if I were you. Actually demonstrating something is a good way to win people over! ;) Keep up the good work!

I can simply share pieces of what is already working via my YouTube channel, makes things easier for me, a presentation (especially at this stage) would probably trigger more issues than solving problems.

Also a presentation is just for a portion of the users that will attend it and maybe the ones that may watch a recorded video later.

The majority won’t be there or may not even follow my train of thoughts (definitely struggle to read a lot of details here), so I truly think that the best way is “keep it quiet until you have it working enough for a distracted user to understand what it is and how it works”.
And then release it as NOT a must to use and build your own distro to have entry thing installed and testable for yourself as first user and for others that might be interested.

@Paolo, Just go for it and as you say those that don’t want to use it needn’t. As for me I keenly await the results of your labours.

Regards.

@ Rick

So I completely agree, centralised data is a bit nuts when one considers it’ll be involved in every single file operation.

Thanks! I have got back the Rick I like, and thanks for evaluating all my details :)

@ Ron

@Paolo, Just go for it and as you say those that don’t want to use it needn’t. As for me I keenly await the results of your labours.

Thanks and agreed, I think it’s best to get it done first, then share it and then collect some feedback only from whom has used it. So I guess I’ll have to go with some mailing list or something, I don’t know, just to filter feedback from people that are actually using it and so finding real issues and real problems.

The only issue with that is the “refactoring” that will be triggered, but I guess it’s still the best approach.

Again thanks everyone for your feedback and no hard feelings, it was a useful experience to understand how to interact on here in a better way.

We do already have GPL components in the source tree, but need to keep GPL components out of the ROM.

Actually, we could just argue that the ROM is a mere distribution medium, and take advantage of GPL’s ill-defined “mere aggregation”, “volume of a storage” and “distribution medium”. Notice how they failed to make those things any clearer in GPL V3.

Any license that needs an FAQ to explain its finer details, which at the same time says that ultimately the courts will decide those details, is ill-defined and should be avoided. Because the courts may not decide the way you intended the license to be interpreted.

I have happily contributed to many Open Source projects, but I would never even think of contributing to a GPL-only project.

But of course those who produce the code and hold the copyright choose the license.

Coming back to the topic of “hidden files”, I am not sure I see the problem. For something like !PowerFiler it is straightforward to have a specific file or multiple of those containing information for PowerFiler to do its work and to provide its features. Anyone who uses PowerFiler throughout – especially those that would never even dream of using the command line – will never notice those “hidden files”. The power users could just go to the CLI or the standard filer to discover those “hidden files” if they like. They can even change them to make them unusable for !PowerFiler, so if I did the !PowerFiler implementation, I would sign those control files to make sure that the user does not fumble around with them. Sell this as a feature to disable !PowerFiler operation on a dir-by-dir case!

Having a mere naming convention for those files has the immediate benefit that it will transparently work on any foreign FS, which the idea of storing it inside Filecore extended attributes does not.