Apps Icon displays folders in filer window.

Whether we go down the route of an attribute or a filename prefix1, 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”.

+1, the OS should handle this as I have mentioned that before, it would be nice if ROD/ROOL would start defining some of these modern standards (not necessarily implemented them right on the minute), I am keeping an eye on this page (I am not aware of anywhere else to check for this, if someone has more info please help): https://www.riscosopen.org/wiki/documentation/show/Extended%20Attributes%20API%20Specification#TOC1.1

However, still nothing in regards of hidden files.

Backing up a step, what’s the goal here? One of the things I like about RISC OS is that it’s not annoying. It’s not full of background tasks, it doesn’t pop up alerts at unexpected times, and it doesn’t stop you from doing what you want to do. However, with hidden files, that’s getting close to the ‘annoying’ end of the scale. If I tell Filer to show me all the files in a directory, then I’d expect to see all the files in that directory.

As Andrew pointed out above, things like configuration files should be in Choices, and temporary files should be in Scrap, which are both ‘naturally’ hidden due to being inside Boot. What other kinds of files are being considered here?

Hopefully this doesn’t kick off too much of a debate :)

What are the chances that RISC OS 5 will get the feature?

Presumably it could be implemented? The protocol is fully documented, so it’s “just” a case of someone adding it to the Filer…

However, my point was more that it’s already possible to trigger searches via messages: the new Apps folder or Pinboard 2, or whatever else, could also use the protocol to trigger search operations. Creating a new way to do it seems daft when one already exists and is implemented.

The only issue, as I noted, is requesting the “search for apps” operation. If the existing protocol could be extended to make this possible, that would be ideal; otherwise, it may be necessary to create a new set of user messages to do this (but it would be a shame if they were Locate-specific).

If I tell Filer to show me all the files in a directory, then I’d expect to see all the files in that directory.

If there’s a tag saying something is hidden, you can treat it differently. In a “show ALL files” instance that would logically be to show all files, but with the normally hidden files faded or something like that.
Normal circumstances would have the files totally hidden.

Then you have to ask the question whether the directories should have a similar feature.

May I please put in a vote against having hidden files?

There is no reasonable use case that I can see.

RISC OS, by default, does a pretty good job of hiding complexity from end users. Applications are treated as a file, all the resources live inside. Ditto the whole !Boot thing for system setup and configuration; which along with tools to update System and install Fonts mean that a non-technical user doesn’t need to go rummaging around things that they could break.

A technical user, s/he who understands what is inside applications and Boot and so on, can just as easily turn on “show hidden files”.

I can understand the point of hidden files on a badly designed filesystem where a lot of random setup junk gets dumped into the middle of user files (Linux, all those ‘.’ prefix files), or a system where important resources are not intended to be visible to the end user (Windows does this). But RISC OS has a different method of working that doesn’t require polluting user data, and already semi-hides things as a factor of how it works.

Thus, I can only see hiding files as a way of trying to sneak crap past the user (a trick also used for nefarious purposes in DOS/Windows; especially DOS’s propensity to run a .COM in preference to a .EXE of the same name, especially if the .COM in question was hidden).

May I please put in a vote against having hidden files?

Can I join you? It would make tech support much more difficult if users have some (random!) files being hidden. They’re guaranteed to ‘accidentally’ hide files and then swear blind that the file “just vanished”.

Also not a great fan of being able to assign custom icons to folders that aren’t applications. Currently it’s easy to distinguish between a folder and an application, at a glance. Once everything has a different icon, telling what’s a folder and what’s an application won’t be so obvious.

@ Rick

May I please put in a vote against having hidden files?

Of course, every opinion matters :)

RISC OS, by default, does a pretty good job of hiding complexity from end users. Applications are treated as a file, all the resources live inside. Ditto the whole !Boot thing for system setup and configuration; which along with tools to update System and install Fonts mean that a non-technical user doesn’t need to go rummaging around things that they could break.

A) It depends what you mean with the term “Resources”. Let’s me clarify my statement, System contains modules that might be required by an app, !Boot.Choices may contain its configuration and (with the introduction of shared libraries for ELF) !Boot contains the SO loader and the libraries that effectively are portions of an App, so I do not think we could safely state that ALL the resources required by an app lives inside the app directory. Sorry for being pedantic here, but this are changing. Also, IIRC, you are one of the people that advocate to make !Boot just a boot and so if Choices, !System and !SharedLibraries have to be moved somewhere else then the statement will be even less correct.

B) Users install software from the internet and a lot of the (90s style) websites report instructions on “where” to install such software and in quite a few cases (for very popular tools) such instructions have been to install things in PreDesk and Tasks…

Just my understanding of the situation vs what you’ve stated, I am not trying to argue or anything, please correct me if I am wrong.

@ Andrew

Can I join you? It would make tech support much more difficult if users have some (random!) files being hidden. They’re guaranteed to ‘accidentally’ hide files and then swear blind that the file “just vanished”.

Normally an “hidden” file is not truly hidden, it’s just “hidden from a desktop view”, for instance in a Unix system that consider files with a name starting with a “.” hidden, just by running an

ls -al

But, I get your point, so probably it’s best that in my particular case I stick with using a special character that for both the regular filer and for the CLI is not a special character.

Also not a great fan of being able to assign custom icons to folders that aren’t applications. Currently it’s easy to distinguish between a folder and an application, at a glance. Once everything has a different icon, telling what’s a folder and what’s an application won’t be so obvious.

Thanks for the feedback on that, I would like to remind that everything I am doing is NOT part of Vanilla RISC OS and so the way this actually will work is that, if a user decides to use !PowerFiler then yes a directory will be fully customisable, but if the user open the same view in the old Filer then a directory will appear exactly how it has appeared in the last 30 years.

However, if my tools may appear so scary for a slice of the user base (I also saw Chris M. comment), another option can be that I simply create a new RISC OS distribution that will include such tools and avoid all together to distribute them as an optional set of features installable where one wants. At that point such tools will only be supported on the new distribution and the slice of the community that wants to keep RISC OS as it has always been will continue to be happy :)

At that point if one wants to play with a “modded” RISC OS he/she knows he/she will only be able to ask for support from me and so there should be no issues to other people.

Normally an “hidden” file is not truly hidden, it’s just “hidden from a desktop view”

Don’t forget that for the average RISC OS user, “desktop view” is all they know. Most don’t even know that the command prompt exists!

I would like to remind that everything I am doing is NOT part of Vanilla RISC OS and so the way this actually will work is that, if a user decides to use !PowerFiler then yes a directory will be fully customisable, but if the user open the same view in the old Filer then a directory will appear exactly how it has appeared in the last 30 years.

Fair enough, I thought the idea was that this could become incorporated into RISC OS at some point down the line. I think !Filer+ (!FilerPro?) allowed similar things in its day too. Once you’ve worked out that a customer is running the filer add-on (despite them claiming not to be) then things make more sense.

Once you’ve worked out that a customer is running the filer add-on (despite them claiming not to be) then things make more sense.

Which is why I am thinking it’s time for a new (where new means actually new) distribution, called something completely different than RISC OS and in the credits mention “based on RISC OS”, so there will be no way for misunderstandings and whoever wants to use a modernised approach (still maintaining compatibility with his/her old apps on ROS) will be able to do so, while whoever is afraid the ancestral RISC OS may become more modern can sleep safe lol nothing will happen to the old OS.

So, no worries no more posts about the modernisation project, I’ll cancel the talk with ROUGOL too, so no misunderstandings.

What is the consensus on hidden files? Useful idea or unnecessary complication?

People on here, by and large, are techies. Asking us may not yield an answer helpful to the general user population.

That having been said, you asked, so…

I don’t really see how they help. Non-technical users are, I suspect, not likely to go looking where those files would be, so I can’t imagine making them hidden as making much difference. To me, hidden files are just a nuisance – if I need to see them (which I sometimes do), I have to defeat the protection mechanism.

So my contribution to the consensus is that I’d rather they didn’t exist.

@Paolo. Another distribution, just the excuse I need to purchase another RPi4 ;-)).

I upgrade at the moment, my Titanium (ROOL), ARMX6 (RComp), Ubuntu (21.4), Rpi4 (Raspberry OS) RPi4 (ROOL) and my sister-in-laws Windows 10 machine. With the exception of the Windows machine keeping the OS’s and software up to date is not an onerous task.

Levity aside I look forwards to your distribution, though I would prefer that the, I am sure, useful improvements were incorporated into the main (ROOL) OS.

Regards Ron.

I applaud your efforts, Paolo, and I will be pleased to look at what you produce, but I have a very strong feeling of déja-déja vu.

I do not think I have seen anything in what you have told us you are developing for the filer that I have not seen before in one form or another and many more than once. Some would not work now, but many will.

Whatever I have tried in the way of enhancements in the past I have stopped using after a month or two, except for the Pinboard, which was originally independent, before it was incorporated into the OS.

Carry on working on PowerFiler for its own sake and if it really clicks it, too, may be incorporated in the OS. ;-)

@ Steve Drain (and others)

I fully understand and yes there isn’t much improvements over the past attempts beside making the whole components set cohesive and as integrated as possible. However, the problem seems to be just the usual subset of users that want RISC OS to be stuck in the past, which I respect and that it’s totally fine by me now that RISC OS is finally open source and everyone can create their own distro.

So, I think a new distribution under a separate name should solve the issue once and for all, if nothing because I would not have to constantly respond that the changes are optional and not invasive in the system¹.

I am also thinking that with a new distro, it will also allow me to release all the new tools under GPL, instead of Apache 2.0, which I think (from a code maintenance point of view) is better, because everyone who will apply improvements and bug fixing will be requested to submit them back, creating so a process of improvements that will benefit the new distro even more (on the long term).

The reason for asking the cancellation of the talk is to avoid spreading even more fears among the ones that want to keep RISC OS old school.

¹ Which alone is a big time saving, so a very good thing.

@Poalo

I fully understand and yes there isn?t much improvements over the past attempts beside making the whole components set cohesive and as integrated as possible. However, the problem seems to be just the usual subset of users that want RISC OS to be stuck in the past, which I respect and that it?s totally fine by me now that RISC OS is finally open source and everyone can create their own distro.

As an end user, rather then a ‘techie’, I think you are misunderstanding, some of the concerns being raised, its not we want RISC OS to be stuck in the past. But concerns about changes for changes sake, like Microsoft does .

Updates and real improvement as nearly always welcome. But why would an ‘end user’ want hidden files for instance, what benefit/improvement do they bring, as an end user I can’t see any practical benefit.

No one has suggested you should not make available various enhancements you feel would benefit us, and I do note they will be optional which is a good idea.

I would not be interested in any new distro, and certainly not one in the restrictive GPL. Please Paolo do not go down that road. Enhancements to the standard RISC OS is good as we have lots of gaps to fill, but I suspect not everyone wants RISC OS to look like or necessary have some of the features Windows has.

Your talk of cancelling your talk, is to use a British expression, “taking your bat and ball home” because you worry others might not agree with your ideas/proposals. I honestly think its better to talk about it but accept some may have a different view on the way to enhance the OS to make it more modern

Apologies in advance to everyone for the extremely long answer below!

@ Chris Hughes

Thanks for your feedback, I truly appreciate it (as well as the feedback of everyone else), also thanks for noting that every component is optional! :)

To your points:

But why would an ‘end user’ want hidden files for instance,

In my experience a large number of users (this doesn’t mean all) do not like to see certain files appearing in their own directories. For instance you have just created:

“Chris Docs” directory for your own documents

My filer can add in it (as the syntax protocol is right now on some modelling code):

+DirIdx
+DirCfg

These two files, because of the sign at the beginning, will appear in front of yours (but I could fix this with adding a ~ instead of a +, for example), and will be visible in your directory and in every other directory you open using !PowerFiler.

What these two files do is simple:

• +DirCfg it’s something similar to mcOS “.DS_Store”, it contains a configuration for the directory, for instance:
  • Which icon you would like to assign to it
  • Where in the file browser tab position your would like your “Chris Docs” to appear if you have selected to NOT use the standard RISC OS filer “icons grid” organisation (this is pretty much what macOS and AmigaOS can do)
  • The directory sprite size (like AmigaOS can do)
  • If you want the directory content to be rendered as an HTML page (this is a future feature, by including NetSurf rendering to the !PowerFiler, but the option is there), This is something that macOS can do and can be extremely useful when creating installation media, where one wants to present the end user literally the instructions to install instead of a bunch of files and figure out what to do)
  • Future extension, this is important, the config file is extensible and no longer limited to 32 bit flag-sets and retro computing stuff like we have now.
  • The file format right now is INI, so can also host multiple sections and it’s very important to not that it can NOT run anything so it’s way more secure than a !Boot file would be (again for the end user)
• +DirIdx is a file that is generated only if a user wants a “fast directory browsing” (so it’s optional)
  • It’s used to generate an index and so instead of exploring a directory, !PowerFiler, reads the file when a user opens that directory
  • All File System operation vectors are captured and if a user adds a file or deletes a file from a directory that index is updated
  • This is useful with slow media like SD cards, and its generally not needed on faster media, hence it will be optional.

However the comments were not just about hidden files, for example Chris Mahoney expressed dislike for background processes.

Now, in all honesty (and with big respect for Chris M.), most of the work in a cooperative multitasking system is kinda done in “background” (via a NULL event, for example, most applications should do the “long processing” instead of doing it within a mouse click event, which can result in the WIMP increasing latency or even freezing for a while in some cases). But, let’s assume people have a different perception of how to achieve efficient cooperative multitasking, so here is the problem I have with that statement:

I am also working on a framework to introduce OS notifications, which, when ready, will work (guess what) as a background task (in the form of a Module + a TaskModule) that is the back-end (sorry technical term that means like an “invisible process” that handles the notifications and the notification routing) and a front-end (a WIMP App) that can display the notification to the user IF the user configured it to display such type of notification and if the front-end is loaded.

The notification framework back-end receives notifications from WIMP applications as WIMP messages and such WIMP messages have their own protocol to ensure an app can send a meaningful message together with a link associated or a button definition with an action associated.

The notification back-end also supports configuration files that a user can create via a GUI to tell the back-end what he/she wants to do with every specified type of notifications, for instance one could:

• Display notification type X (this will result in sending the notification from the back-end to the front-end and the front-end showing the user a bubble or something with the notification and the button or link etc.)
• Route to SysLog notification type Y (this will route the notification to a SysLog server that can be local or remote and so help controlling a network of RISC OS systems and/or debugging)
• Log locally (this is obvious, store the notification on a specified file)
• Ignore (well this one is easy :) )

But the back-end can also do time/event based notifications. This is like !Alarm (in some ways), but a bit more articulated:

• For instance stop all display-notifications after 21:00
• Notify me if my raspberry pi is getting too hot
• Lower the clock if the RPi is getting too hot
• if GPIO pin X signal is UP do Z (you probably can see here why part of the back end is a traditional Module, so it can work also when no desktop is active).

The reasons for a back-end is to allow every application to be able to send notifications to a user (according to the user wish), so a future release of Messenger could display notifications on the screen for an email received (for instance just emails from work and not from everyone). Now, someone may comment with something like “why do I need your stuff? We can add this to Messenger!”. Sure, and then add the same to another 20 applications and drive a user crazy because:

a) he may not customise the behaviour of all these apps
b) Even if he can, then he has to do this for all the 20 apps lol and for all his RISC OS systems.

While having a framework that handles the notifications and allows a user to decide what to do with them, and using “portable conf files” for this, means you configure once and using the same UI and then can sync all your systems if you need.

BTW keep in mind I am just scratching the surface here, in reality there is more. It’s just that this answer is already so long :(

Others have expressed opinions against this type of new features and also fear what, the people who are in favour would like to get these features on the mainstream OS. In the end you are mentioning this as well.

I do not want to be in the middle on a new war between the “old schools” and the ones that want a more modern RISC OS. All my effort is – just for fun and for free -, so really not worth getting into that type of discussions. So, one way that could ease things out could be to approach this in a practical way: “create these things and when we have them working we can decide what is useful and what is not, with actual use cases and the real user using them”. While, the reason for asking feedback is mostly from a user-point-of-view, in case someone may have some useful ideas to add improvements that others would love to have as well.

The other benefit of this effort/project is that there will be a “library” of quite useful WIMP code that (even if not used as is), for who is interested, can represent a source of inspiration to create new ideas that covers other missing things from the OS (this is especially true when developing in components and reusable libraries as I am trying to do).

So, I think, an experimental distro is the best approach to avoid people to complain without data at hand and, at the same time, allow who wants to try out the new stuff to try it without stressing the ones that fears for the vanilla RISC OS to become something they do not like.

Hope this is received as a good thing, not a bad one.

Your talk of cancelling your talk, is to use a British expression, “taking your bat and ball home” because you worry others might not agree with your ideas/proposals. I honestly think its better to talk about it but accept some may have a different view on the way to enhance the OS to make it more modern

In a sense you are right, but in my experience the reality is this: Life is short and nothing is worth wasting time, unless you love what you’re doing. What I like is coding, not dealing with people (yes my big limitation in life I know), this is one of the reasons why I have not really joined much conversations until recently.

I honestly think its better to talk about it but accept some may have a different view on the way to enhance the OS to make it more modern

I accept other’s views, I am not stopping them to do things their own way (although if I haven’t seen alternative proposals TBH) and I am not stopping doing anything on my side.

Here some examples (please guys do not take this personal):

I can understand the point of hidden files on a badly designed filesystem where a lot of random setup junk gets dumped into the middle of user files (Linux, all those ‘.’ prefix files), or a system where important resources are not intended to be visible to the end user (Windows does this). But RISC OS has a different method of working that doesn’t require polluting user data, and already semi-hides things as a factor of how it works.

Badly written FileSystem = Linux? Really? So, just to be clear: everything, literally everything anyone here does rely on Linux FileSystem and you’d be surprised to know how many vital apps rely on it.

Where RISC OS has a better FileSystem than Linux? Where RISC OS has a “different way of working”? the !Boot? read later for the fun with putting all the stuff in !Boot (which btw Rick himself have disagreed with in other posts).

Just To be clear, I always enjoy Rick’s responses, so please lets not start a personal thing here, this is just “in this particular case!”

Also not a great fan of being able to assign custom icons to folders that aren’t applications.

Unfortunately if RISC OS doesn’t overcome the problem of the font DPI (read many Druck comments on the matter), with the increase of screen resolutions, the only “short cut” to make people find things quickly IS to customise a directory icon (don’t forget that people are also asking for having the Filer background colour to be customisable). Why? because, at least, one can locate an important directory quickly (by the colour, the shape, the icon) within many. But this one may be a problem that only I have, so ok let’s say this one is ok.

I don’t really see how they help. Non-technical users are, I suspect, not likely to go looking where those files would be, so I can’t imagine making them hidden as making much difference. To me, hidden files are just a nuisance – if I need to see them (which I sometimes do), I have to defeat the protection mechanism.

Not sure I understand this one. Dave is basically saying “I don’t think they help”. So, the local file in the directory indeed helps, either hidden or not, I explained it why (below). Hidden could probably be seen more as preference of a user that just wants to see his own files and not the OS “management files” (read below for more important info on this). But again the local files do help.

If the file is in front of a user eyes like in the case I have explained, the user will see them if they are not hidden, so the user can also select and delete them (ouch!). Yup that’s why they are “hidden” on linux, not hidden as a malware, just “out of the way”, so you can use your “Select All” safely, you can drag and drop away with no need to keep an eye on the “OS management files”, but anyway never mind.

BTW, it’s not just about the comments on here (which again have been polite, so nothing wrong, only a “superficial technical analysis”), there have been also other chats where the constant “voice” of changing things on the mainstream OS or people commenting “if someone wants macOS then they can buy macOS” or similar have made me come to this conclusion.

Again, I am just having fun, RISC OS to me it’s in no position to pose a serious alternative to macOS, Linux or Windows. All I am trying to achieve is making my RISC OS look and feel as modern as I can without changing the core OS, it’s simple :) (well kinda! lol) and I am sharing the process, so others can provide some constructive feedback to overcome problems and get to the target.

I think the majority wants a modern RISC OS (I have seen the stats around the pages and the videos sharing of my updates, the twitter etc. the attention to a more modern OS is surprisingly large). The issue seems to be mostly related to “perceptions” (yes this is normal in life), so the only way to re-balance this is probably to work on a model that people can test and, eventually, change their original perceptions.

Here is another example of “superficial technical analysis”, if one may say: The RISC OS way is to centralise those files somewhere in !Boot instead of having them hidden in a local directory, that would be a potential huge mistake, because:

a) would make synchronisation across multiple machines complicated
b) loads of files in a single directory is not a good choice for FileCore performance together with an SD card, but this one may pass
c) naming conventions becoming more complicated (how do I associate a config file with your directory “Chris Docs”? you may have a Chris Docs in multiple sub-paths for example, and there is more)

Am I making sense?

I would not be interested in any new distro, and certainly not one in the restrictive GPL. Please Paolo do not go down that road.

Then you can wait until the “testing new distro” has done is effect and people may have changed their opinions maybe?

The reason for the GPL, is something that I have been thinking about for a while. And I also want to use GPL based libraries and code and so will be forced to “inherit” it , at least for some components. However if this is truly a problem for the RISC OS community I will see what I can do on the matter, but not so sure it will be possible to avoid it entirely without having to write certain libs from scratch. We’ll see.

If you have read everything till here you are my hero! Again sorry for the extremely long comment.

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

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? RISC OSs UI stopped in 1998, with the only changes being in Pinboard2 and the Select branch, none of which has reached a rool build yet. Is everyone so insular to think that nothing that has happened on any other OS in 20 years could possibly be useful here?

I’m in two minds about notifications myself. The problem I’ve seen with Windows and MacOS is that once a system-wide notification facility exists, every developer seems to think it’s their duty to fill it with as many notifications as possible. Hopefully RISC OS developers are a little more discerning :)

Edit: Come to think of it, isn’t “a background task and a front-end” just Reporter with a different name on the tin? (Granted you’d want a filter to only show ‘end user’ messages).

So I vote against such additions.

You don’t need to vote against them, just don’t run Paolo’s addons if you don’t want them!

The issue seems to be mostly related to “perceptions”

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 :-)

so unwilling to even try something new

Who said they were unwilling to try it? People just offered opinions about what they like/dislike, which is the whole point of this thread.

Badly written FileSystem = Linux? Really?

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.
And I’m really not a fan of a system where myfile.txt, MYFILE.TXT and MyFile.txt are three different things.

and you’d be surprised to know how many vital apps rely on it.

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.

Also, Linux is ubiquitous. Pick a processor. Any processor. If it’s capable enough (has an MMU and decent clock speed), there will be a build of Linux for it. No other major OS has the degree of coverage of Linux.

And I also want to use GPL based libraries and code and so will be forced to “inherit” it , at least for some components.

This is why we are anti GPL when it comes to the RISC OS codebase. Don’t get us wrong, there are numerous useful GPL projects for RISC OS. But for the OS source code, it’s a GPL free zone exactly because of the viral nature of the licence.

I, personally, won’t touch it with a bargepole as any licence that has an explanation saying “the courts will decide” is not fit for purpose; I’m a programmer dammit, not a lawyer. But it’s a personal choice. If you wish to use GPL, then go ahead. But be aware that doing so will prohibit the inclusion into the OS itself in the future.

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.

Take notifications, for instance. A good notification can be useful. But it’s not you who decides what the useful notifications are, it’s the programmers. And if you’re not careful, it ends up basically spamming the user with so much junk that anything useful is lost amid the noise, ultimately leading the user to turn the feature off entirely (if they can).

If there’s an update, tell me about it. If I dismiss that message, don’t pop it up again every bloody time you check.
If I’m copying a group of files, notify me when it is done (if there’s no other on-screen status). Don’t tell me when every single file has been copied.
Especially if the notification has a pop-to-top behaviour.
And never ever use it for advertising.

That’s not to say a system wide notification would be a good thing, it just needs some care in how it is implemented.
Might I suggest an “importance” value? The user can set a level of importance (everything, warnings, task completions, problems…) and less important notifications will be dropped.

Is everyone so insular

That is an absurd statement. How many RISC OS users have used Windows? Probably all of them. How many Windows users have used RISC OS? Almost none of them. So who’s being insular here?

If some Windows developers had used RISC OS 30 years ago maybe they wouldn’t have got, and continue to get, so many basic UI things wrong!

I do not think I have seen anything in what you have told us you are developing for the filer that I have not seen before in one form or another and many more than once. Some would not work now, but many will

A few. To get more than one or two useful features you need many.
All in one and working on current hardware is useful.

I am also thinking that with a new distro, it will also allow me to release all the new tools under GPL, instead of Apache 2.0, which I think

Please, please, please, no.

For applications with no impact on the core OS, GPL away.
Core OS, and allied modifications – Apache

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? RISC OSs UI stopped in 1998, with the only changes being in Pinboard2 and the Select branch, none of which has reached a rool build yet. Is everyone so insular to think that nothing that has happened on any other OS in 20 years could possibly be useful here?

Something Peter and I can agree on.
There are good things elsewhere, even in MS land. Take the blinkers off folks. We don’t need their code, just the ideas and a talented programmer (OK, we’re short of those)