Replacement for iconbar Apps icon
Theo Markettos (89) 919 posts |
It’s becoming clear that the iconbar Apps icon is no longer fit for purpose. It’s currently serving to provide several intersecting functions:
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:
All of these have pitfalls. Off the top of my head issues I can think of:
And wider issues relating to this (thinking ‘blue sky’ for a moment):
So, as they say, it’s over to you… |
Rick Murray (539) 13806 posts |
Is it hard 1 to write a pseudo image filing system to look like the current Apps, only supporting directories, something like as follows:
When the filesystem is started, the new Apps will automatically AddApp the ROM stuff. The !Boot script(s) can then tweak this as desired. 1 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:
I’d go for this option, but I’m not sure if the current incarnation is flexible enough?
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).
Part of the above suggestion. Just because it looks like Apps doesn’t mean it has to be.
…and !Edit (etc) would be where?
Oooh, I know! Me Sir! Me Sir! <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).
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.
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
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.
For the first version, ignore them?
Stuff in $.Apps gets filer-booted. No exceptions2. The user ought to show restraint and put in the useful day-to-day applications, not everything imaginable. 2 Except for files and such where filer-booting them doesn’t make sense.
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?
If Apps can support folders, then the packages could contain location hints, like “$.Apps.Graphics.!WhizzyPixelEditor” which will appear in Apps as Graphics.!WhizzyPixelEditor.
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.
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.
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). 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? |
Frederick Bambrough (1372) 837 posts |
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. |
Robert Hampton (1923) 57 posts |
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.
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.
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.
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.
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. :-) |
Chris Evans (457) 1614 posts |
Interesting ideas lads!
Very unusual! I’ve seen hundreds of RISC OS users hard drives and 98%+ of the time $.Public is empty. |
Frank de Bruijn (160) 228 posts |
Same here.
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. |
Steve Pampling (1551) 8155 posts |
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. |
Steve Drain (222) 1620 posts |
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.
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. |
Chris Evans (457) 1614 posts |
Some parts of ResourceFS can cope with subdirectories: |
nemo (145) 2529 posts |
Steve wrote:
Chris replied:
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. |
nemo (145) 2529 posts |
My criticisms of the current Apps idiom are:
I propose a new filing system – Apps: – which presents a dynamic amalgamation of a number of sources including, by default, Resources:$.Apps.
The default configuration would be: *AddAppDir <Root$Dir>.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 |
Steve Pampling (1551) 8155 posts |
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 chosen1. 1 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. :-) |
Steve Drain (222) 1620 posts |
Which is precisely what I said. ;-)
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. |
Trevor Johnson (329) 1645 posts |
Can’t the static aspect be changed? I agree about the stubs/read-only presenting confusion. |
Steve Drain (222) 1620 posts |
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. |
nemo (145) 2529 posts |
That wouldn’t be fit for porpoise. |
Steve Pampling (1551) 8155 posts |
Get yer coat, it’s cold out an’ yer leavin’ |
David Gee (1833) 268 posts |
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). |
Jess Hampshire (158) 865 posts |
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. |
Bryan Hogan (339) 589 posts |
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. |