Replacement for iconbar Apps icon

It’s becoming clear that the iconbar Apps icon is no longer fit for purpose. It’s currently serving to provide several intersecting functions:

• Access to ResourceFS (Fonts, Sprites, Messages, etc)
• Access to ROM apps (Draw, Edit, etc)
• Access to apps found on disc

The last is the problem. AddToApps will do a non-recursive add of programs in Bootdisc::$.Apps (which I’ll call ‘$.Apps’ for this discussion), but not delve any deeper. Most users don’t have all their apps in the top level of $.Apps without any subdirectories, so this means that for many people the Apps icon doesn’t actually show them their apps. This is confusing for new users, and many RISC OS users have learnt to ignore the icon. In addition, these are not the real apps, even though they look like they are, but merely stubs.

Given the additional debates regarding packaging and ‘where things go’, it may be time to look at the bigger picture – not just what this icon should do, but how people find and run apps. So perhaps we might step back a bit and decide first if fixing this is the best way to solve the wider problem.

We could:

• Improve Resources:Apps. For example, recurse in AddToApps, giving either a flattened view of $.Apps in Resources:Apps, or create subdirectories in there to mirror the hierarchy.
• Remove the icon and let people just navigate the filesystem themselves
• Make the icon do something that doesn’t simply open a part of ResourceFS
• Just make it a Tinydir to $.Apps
• Do something new

All of these have pitfalls. Off the top of my head issues I can think of:

• What to do when we’ve booted without a disc available – still need access to ROM apps
• Need to retain access to the rest of ResourceFS – Fonts/Messages/etc
• What about apps that users want to hide (old versions, etc), but are left in $.Apps?
• What about other files that might be in $.Apps? It’s not so easy to make stubs of files as stubs of applications
• How this interacts with Filer_Booting of things in $.Apps (maybe some things don’t want filer booting)?
• If we have stubs in ResourceFS, how are these updated when $.Apps changes (eg programs removed)

And wider issues relating to this (thinking ‘blue sky’ for a moment):

• What the ‘default layout’ should be for disc images, package manager installs if the user says ‘just do it, I don’t care where you put it’, etc
• What about other places like $.Utilities and $.Diversions – do these need restructuring or somehow integrating into such a ‘launcher’?
• How should the distinction between things in ROM and things on disc be indicated?
• Do people want a ‘launcher’ that isn’t Filer-based? (Examples being the Windows Start menu, iPad/Android home screens, the Pinboard, Google’s search-as-you-type etc)

So, as they say, it’s over to you…

Is it hard ¹ to write a pseudo image filing system to look like the current Apps, only supporting directories, something like as follows:

*AddApp <src> [<dest>] – adds an app link to Apps; if a destination does not exist, it will go in $. Make this smart so if a user does “AddApp $.DTP.!OvnPro $.DTP.!OvnPro” then it will create the DTP folder if it doesn’t already exist. If the destination is not specified, it’ll stick the App into $ like the current incarnation.
*RemoveApp <src> – removes the named app; or faulting if the app doesn’t exist.
*MoveApp <src> <dest> – will move an already existing app, for instance “MoveApp $.!Paint $.Graphics.!Paint” will take !Paint from Apps root and stick in in a Graphics subdirectory.
*NewApp YES-DO-IT – will clear everything leaving Apps empty. The “YES-DO-IT” is something that must be typed to guard against this being done “by accident” (although deleting virtual files is hardly a crime against humanity! ;-) ).

When the filesystem is started, the new Apps will automatically AddApp the ROM stuff. The !Boot script(s) can then tweak this as desired.

¹ Ages ago, I tried to write an image FS for FileStore format floppies. It reliably crashed at the “check the disc to see if it is your format” test. Nothing I could do seemed to make it work; it wasn’t helped by the content of the registers being different to what the PRM said. Either the PRMs are wrong, the filesystem code is wrong, or my code is wrong, or any mixture of these options. Either way, it is safe to say that the experiment was a resolute failure. Meh.

Specific responses:

* Improve Resources:Apps. For example, recurse in AddToApps, giving either a flattened view of $.Apps in Resources:Apps, or create subdirectories in there to mirror the hierarchy.

I’d go for this option, but I’m not sure if the current incarnation is flexible enough?

* Remove the icon and let people just navigate the filesystem themselves

I may be alone here, but I quite like Apps. It has many limitations, but I can often do in two clicks what would take a lot longer. I am especially partial to Apps because everything in it has been “booted”. If I navigate the filesystem and open folders and forget to hold the right key, loads of unwanted stuff will be “seen” by the filer. Some apps have a tendency to steal filetype associations (eg claim them in Boot without checking if there is already a RunType set for that sort of file).

* Make the icon do something that doesn’t simply open a part of ResourceFS

Part of the above suggestion. Just because it looks like Apps doesn’t mean it has to be.

* Just make it a Tinydir to $.Apps

…and !Edit (etc) would be where?

* Do something new

Oooh, I know! Me Sir! Me Sir!
Why don’t we…

<dramatic pause>

…have a “START” menu on the screen that opens up an unholy list of everything all jumbled together with no easy way to alter this without delving around special parts of the filesystem (split across several locations just to ensure you’re paying attention).

* What to do when we’ve booted without a disc available – still need access to ROM apps

My suggestion has the Apps filing system self-initialise to look and feel like the original. This can be altered via commands, but should suffice if booting without a disc available.

* Need to retain access to the rest of ResourceFS – Fonts/Messages/etc

Not really. Well, yes we’d need this, but it doesn’t have to be available from the iconbar. A user that wants to go here could Filer_OpenDir Resources:$ or somesuch.

* What about apps that users want to hide (old versions, etc), but are left in $.Apps?

A protocol will need to be decided, like a folder called “_old” or something that is skipped. That said, it’s the user’s outlook if they clutter up $.Apps with rubbish.

* What about other files that might be in $.Apps? It’s not so easy to make stubs of files as stubs of applications

For the first version, ignore them?
For the second version, as we will be working with virtual objects we could just invoke Filer_Run on the original when the user chooses the object.

* How this interacts with Filer_Booting of things in $.Apps (maybe some things don’t want filer booting)?

Stuff in $.Apps gets filer-booted. No exceptions². The user ought to show restraint and put in the useful day-to-day applications, not everything imaginable.

² Except for files and such where filer-booting them doesn’t make sense.

* If we have stubs in ResourceFS, how are these updated when $.Apps changes (eg programs removed)

A new filesystem could cater for this by remembering the canonicalised paths to things, and keeping an eye on the filesystem calls. Isn’t there an upcall or such for when a file is deleted?

* What the ‘default layout’ should be for disc images, package manager installs if the user says ‘just do it, I don’t care where you put it’, etc

If Apps can support folders, then the packages could contain location hints, like “$.Apps.Graphics.!WhizzyPixelEditor” which will appear in Apps as Graphics.!WhizzyPixelEditor.

* What about other places like $.Utilities and $.Diversions – do these need restructuring or somehow integrating into such a ‘launcher’?

These could be integrated into the system Apps:$.Utilities etc by the !Boot script; plus serving as an example of how to do it. It should not be an automated scan – it is good having !ChangeFSI easily available. It is not good having !HForm easily available.

* How should the distinction between things in ROM and things on disc be indicated?

Why would they need to be? An App is an App. If I want to run !Edit, I don’t care if it is in ROM, harddisc, a share, or downloaded from ftp.acorn.co.uk (hic!) on the fly… so long as I double-click it and it appears.

* Do people want a ‘launcher’ that isn’t Filer-based? (Examples being the Windows Start menu, iPad/Android home screens, the Pinboard, Google’s search-as-you-type etc)

Windows Start menu is a good idea but it is clumsy and doesn’t scale well.

Can’t speak for iThingy, but the Android home screen is basically a smart pinboard. The actual dialogue for picking apps (those not on hme screens) is messy.

Pinboard. Funny thing. My RISC OS pinboard doesn’t have much on it. It is more an evolutionary thing (if I start up to do some programming, then a bunch of relevant things are pinned).
Under Windows, I have a lot of stuff stuck to the backdrop; possibly because the Start menu is useful/annoying in equal measure; and Windows really doesn’t encourage you to go near the filing system any more than absolutely necessary.

That’s my 0,02c worth. ;-)

Got Nobuta wo Produce to watch, so I’m not going to do anything useful like spellcheck this. Sorry. There isn’t enough day in my day these days. Is this a sign of getting older?

Oh, do people actually keep their applications in !Apps? I just use it for a few quick access utils like SparkFS or XChars & whatever came ready installed in it such as ‘Acorn’ stuff.

I thought it usual to store all else in $.Public.Whatever.

I think this is a useful debate to have, especially with the Pi and other systems bringing in new users who do not have any preconceived ideas about how RISC OS is “supposed” to be, we can maybe shake things up a little.

Most users don’t have all their apps in the top level of $.Apps without any subdirectories

How many users have all their apps in Apps full stop? I can only speak for myself of course, but on my previous RISC OS machines, I never had anything in there other than the “default” apps (!Maestro, !Squash etc). Indeed, I was a bit disconcerted on the Pi to see PackMan putting stuff in there.

What the ‘default layout’ should be for disc images, package manager installs if the user says ‘just do it, I don’t care where you put it’, etc

This is a difficult one. Historically, RISC OS (certainly up to version 3.1) was never particularly prescriptive about how the disc is organised. With the advent of the RiscPC that changed slightly, with Apps, Diversions and Utilities preloaded along with !Boot. Again, though, there was no guidance from Acorn or anyone else about where to put any additional apps so I imagine most users came up with their own schemes.

My typical way of working was to create new directories in $ as necessary. So I had, for example, $.EasiWriter in which !EasiWrite and its various support files and tutorials lived; $.Text which contained !StrongED and !Zap (yes I had both, I was fickle!), $.Networking which had !Netsurf, !FTPc, !Messenger etc. The exceptions were games (which I put in Diversions) and utilities which went in… well you can probably work it out. For the apps I used frequently, I used “Add to Apps” in Configure so I had easy access to them from the icon bar.

That was my scheme and it worked for me. Having said all that, maybe now is the time to start recommending (without being dogmatic) that users install stuff in specific places.

Personally, I would like to continue using the Apps icon as my “frequently-used” app launcher so I would not be keen on changing it to show all apps (either as a directory hierarchy or a “flat” structure).

Why not use <Root$Dir>.Apps (and subdirectories within) as the default install location (except for stuff more appropriately classified under Diversions or Utilities), and also drop the “everything in $.Apps gets AddApp’d at Boot” feature? Users could then choose for themselves which apps appeared in the “ROM apps” window, using Add to Apps in Configure, or via a PackMan option at install time. For stuff not in Resources:$.Apps, they are just two or three double-clicks away from the app using the Filer.

How should the distinction between things in ROM and things on disc be indicated?

Do we actually need to have apps in ROM these days? OK, it’s good that !Edit is in ROM, so there is a text editor available even if some catastrophe renders the filing system unreadable. But do Draw, Paint, Alarm, etc need to be there? It seems a bit of a throwback to the days of floppy-only systems, when having these programs instantly available all the time was an advantage.

Do people want a ‘launcher’ that isn’t Filer-based? (Examples being the Windows Start menu, iPad/Android home screens, the Pinboard, Google’s search-as-you-type etc)

I use a heavily-customised !Director which provides access via a menu to all the apps on the disc. I guess you could call that a Start menu-type system. There have been many other menu-based launchers over the years (!Menon, !StrongMen etc) which seems to suggest that a certain section of the community finds this style of launcher useful.

While an iOS style launcher works well on iPad/iPhone, I’m not a fan of the equivalent Launchpad on Mac OS X – it doesn’t translate well from touchscreen to a keyboard/mouse set up, in my opinion. And I think we can all agree that Windows 8’s Start Screen is not the way to go. :-)

Interesting ideas lads!

I thought it usual to store all else in $.Public.

Very unusual! I’ve seen hundreds of RISC OS users hard drives and 98%+ of the time $.Public is empty.
IIRC Acorn reserved it for writeable access on locked machines that is also visibly across ShareFS when the ‘Share’ is ‘protected’

How many users have all their apps in Apps full stop? I can only speak for myself of course, but on my previous RISC OS machines, I never had anything in there other than the ‘default’ apps

Same here.

I use a heavily-customised !Director which provides access via a menu to all the apps on the disc. I guess you could call that a Start menu-type system.

I use something similar. I’ve been a StrongMenu user for many years (tried Director once, but didn’t like it). Until about five years ago I used to manually create menu structures for StrongMenu for all the applications I wanted easy access to. Then I added automatic menu creation and that works for me.

Why don’t we…

…have a “START” menu on the screen that opens up an unholy list of everything all jumbled together with no easy way to alter this without delving around special parts of the filesystem (split across several locations just to ensure you’re paying attention).

Nice, but it would absolutely have to have the feature that re-arranged the list at random intervals. Oh, and removing an application should also leave behind a non-functional link for some items.

Mind you programming an extra keyboard key to open Apps, with keyboard navigation of the viewed items IS a decent idea. I wonder if Nemo has an opinion on that one? Possibly even a specific module and config already.

It’s becoming clear that the iconbar Apps icon is no longer fit for purpose.

Is it? It is not perfect, but this feels like deja-vu all over again, going back 20 years or more.

Way back I wrote my RFSFiles module to make adding and removing Resources files easier than writing a special module. I also wrote RFSApps, which allowed for adding and removing things in Apps dynamically, including the rom apps. I never made this 32-bit and I never finished a feature that allowed sub-directories.

Before anyone gets carried away with ideas, it might be well to have an idea of what ResourcesFS is and some of the implications.

• It is based on the original BBC Micro ROMFS, which was also available on some podules. It is not a filing system as we otherwise know it; there are no directories. Files in Resources just have a name, up to 63 characters, which can be pretty well anything. It is the ResourcesFiler that interprets the name as representing a path.

• My supposition is that it was originally intended to make system resources in the rom simpler to work with as files, rather than blocks of data. Resources files that are in rom take no other memory, but added files take memory from the RMA, which may not be desirable, although a dynamic area might be used, I think.

• Files are on a linked list. The rom files are on one continuous list, which make access fairly rapid. When ram files are added they increase the access time, which has speed implications. This was noticeable in the original RO 3.1 machines, but might not be much concern now. Messages files make up a large proportion of Resources files and I think it is implicated in the speed issue, too.

One reason I stopped working on further Resources features was that I realised that making it a full-blown access point had memory and performance penalties. It is good for the rom apps and a few often used disc apps, but I really think that StrongMenu, Director and many other quick access programs are a better bet. Myself, I use the the Pinboard mostly.

Some parts of ResourceFS can cope with subdirectories:
Resources:$.Fonts.Homerton.Medium.Oblique.Outlines0

Steve wrote:

It is not a filing system as we otherwise know it; there are no directories

Chris replied:

Some parts of ResourceFS can cope with subdirectories

To clear up the confusion, Steve was saying that (much like a ZIP file) there is no representation of a directory object and hence no such thing as an empty directory in ResourceFS.

There are simply files with pathnames which are presented as though there are directories.

My criticisms of the current Apps idiom are:

• It is read-only, so users can’t drag things in there. Consequently it is configured by side-effect.
• It is static, so something dragged into $.Apps doesn’t appear in Apps until a reboot or command-line magic.
• It is full of stubs, which use up memory unnecessarily and which can confuse the user (Hold shift and double click on !Example and then edit the Config file – no, not that !Example, the other one).

I propose a new filing system – Apps: – which presents a dynamic amalgamation of a number of sources including, by default, Resources:$.Apps.

• Clicking on the Apps icon does a Filer_OpenDir Apps:$
• AddApp is extended to support an optional destination path
• AddAppDir introduced for efficiency

The default configuration would be:

*AddAppDir <Root$Dir>.Apps

*AddAppDir Resources:$.Apps

This would automatically show all the contents of $.Apps in Apps: – and would also instantly reflect any changes to $.Apps.

Any attempt to write to Apps: would be redirected to the topmost writeable directory. Hence, in a multi-user configuration (does anyone use them?) users could have their own Apps directories.

AddApp       <afsp> [<destination path>]
AddAppDir    <afsp> [<destination path>] [-readonly] [-nosubdirs]
RemoveApp    <afsp>
RemoveAppDir <afsp>

Obviously one could AddAppDir <Root$Dir>.Utilities Utilities if one wished.

I propose a new filing system – Apps: – which presents a dynamic amalgamation of a number of sources including, by default, Resources:$.Apps.
Clicking on the Apps icon does a Filer_OpenDir Apps:$
AddApp is extended to support an optional destination path
AddAppDir introduced for efficiency

Sounds like that sort of links in with peoples comments about what !PackMan ought to do in that PackMan (by some comments) ought to just add a pointer to the real location which the user has chosen¹.

¹ To be awkward of course, because users never really know where anything should be and need to be told by the people wot wrote the package. :-)
edit – miss one sodding space and textile does naff things to your footnote

To clear up the confusion

Which is precisely what I said. ;-)

I propose a new filing system – Apps:

Which is roughly where I stopped, for the reasons I gave. You seem to be propoising a form of linking. The existing linking programs are not well integrated and not updated. I would be delighted to see an ‘offical’ linking system in the os. Then your proposal would be quite straightforward.

• It is read-only, so users can’t drag things in there. Consequently it is configured by side-effect.
• It is static, so something dragged into $.Apps doesn’t appear in Apps until a reboot or command-line magic.
• It is full of stubs, which use up memory unnecessarily and which can confuse the user (Hold shift and double click on !Example and then edit the Config file – no, not that !Example, the other one).

Can’t the static aspect be changed? I agree about the stubs/read-only presenting confusion.

Can’t the static aspect be changed?

You can use *AddApp from the command line. My RFSApps module gave you *RemApp. The filer I was working on allowed you to drag-and-drop and sub-directories, but I do not think this is the way to go with Resources.

You seem to be propoising a form of linking.

That wouldn’t be fit for porpoise.

That wouldn’t be fit for porpoise.

Get yer coat, it’s cold out an’ yer leavin’

It might be worth looking at other systems to see what they do. In many ways, Mac OSX is the closest to RISC OS—not least in that applications are directories (with a hidden ‘.app’ extension rather than the ‘!’ at the front).

Normally, applications just go in the Applications folder; it can be added to the dock and opened like a list if you want. But you can have subdirectories too. In parallel with this system, there’s Launchpad; one or more full screens of links to applications. This works like iOS in that you can create “folders” of applications by dragging one app’s icon on top of another. This has no significance other than within Launchpad, however.

On Linux, GUI-based applications normally install a .desktop file in a standard location (/usr/share/applications) and it is often added to a menu if the D.E. in use supports one. There is often a menu editor, too (e.g. Alacarte in GNOME). The desktop file indicates the icon to be used, what the executable is, and also (often) under what menu heading the item should appear. There is a standard set of headings.

The “traditional” Windows approach is to have both system and user Start Menu folders; in these further folders (directories) can be added if desired. Applications normally like to create their own start menu folders.

Some version of the Mac approach seems more likely to fit with RISC OS—in any case it isn’t as much of a problem as on other systems, as there simply isn’t the number of applications… :-(

Note: ‘icon’ in the foregoing means the usual, non-RISC OS, meaning of a small picture in the file manager/desktop representing an object in the file system somewhere; RISC OS ‘icons’ are generally called “controls” (Windows/Mac) or “widgets” (X).

Nemo’s suggestion sounds good. But I would like to see the following:

A configure option, that has the option to set directories to scan, and the option of subdirectories. Also an option to turn off individual ROM apps. The default should be like current RISC OS.

The adjust button should be used for something, such as displaying all the packaged programs (I would see this as being used by add-ons to the standard RISC OS image.

FYI over on the Pi forum, under the Wakefield show thread, there’s a discussion with a RISC OS newcomer about the Apps icon:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=55&t=41226

It rather confirms Theo’s original statement that the current behaviour is confusing to new users.