Apps Icon displays folders in filer window.

How easy would it be to modify the Apps applet on the iconbar to display everything in the Apps folder and not just (!) applications… Or at least allow the user to configure what else is displayed?

What else would you like to display there Gareth?

Perhaps the ‘Apps’ icon could be renamed if it is to include stuff other than Apps. How about ‘Apps and lots of other stuff’.

Sounds like Gareth wants a fast access directory sitting on the iconbar and containing a mix of files, applications and directories.
I think Gareth’s requirement could be fulfilled by a combination of creating the directory he wants and then TinyDir-ing it to the iconbar (see below) – yes Gareth?

ctrl-F12 to get a task window and in that

CDir $.Stuff
AddTinyDir $.Stuff

That should give him the iconbar visibility he’s looking for – with the caveat that the AddTinyDir $.Stuff needs to be repeated at every boot by putting it into an Obey file and dropping that into the boot sequence.

I’m sure there’s a nice simple way of creating the directory and the obey file programmatically so novices can just click the “create-iconbar-dir” utility, give a directory name and it all happens.

I’m sure there’s a nice simple way of creating the directory and the obey file programmatically so novices can just click the “create-iconbar-dir” utility, give a directory name and it all happens.

The Obeyfile bit is sorted – save the Pinboard.

allow the user to configure what else is displayed?

You could try my AppUtils which was rewritten in response to a similar topic back in March.

Edit: For just adding directories and files you might use my RFSFiles module, which is included in the download.

The Obeyfile bit is sorted – save the Pinboard.

Doh!
I completely overlooked the fact that AddTinyDir is actually provided by the Pinboard module…

Probably even easier with Pinboard2.
What would be nice for the user is something like right-mouse-button drag to the bar to do that in one action in the GUI and a pinboard save in CLI – unless the latter is another item I’ve forgotten/overlooked.

Or at least allow the user to configure what else is displayed?

There’s always MkResApps — which probably still works on modern systems.

There’s always MkResApps — which probably still works on modern systems.

You could always ask the author to check and update if required :)

Not quite what I meant… If you look in the Apps folder in the root directory of a Raspberry Pi SD card, there are directories inside. If you’ve installed the Acorn DDE in the suggested manner (by copying the contents of the zipfile into the root directory using the supplied directory structure) you’ll find all the tools in such a directory inside Apps. The Apps icon on the iconbar will display a filer window containing the (!) applications in $.Apps, but not the subdirectories. So one has to trawl manually though the filing system instead…

Same goes for some of the stuff installed by !Packman… Network related stuff finds it’s way into Apps.Network for example.

Not quite what I meant… If you look in the Apps folder in the root directory of a Raspberry Pi SD card, there are directories inside

Sounds to me like the effect of AddToApps

Double click !Boot (or use the Configure option in the Switcher menu) click Boot click “AddToApps” and drag any application you want to see in Apps from wherever it is (e.g. the directory in Apps you referred to) and drop it on the panel of the AddToApps window. Click the “Set” buttons to close out.

That adds some lines to the Desktop and Predesk files in !Boot so you need to reboot to run them.

Note: Unless you keep the additions down you end up with a lot of clutter in the Apps window.

Note2: Certain purists at ROOL don’t like the idea of a right click on Switcher to open Configure but if you go to !Boot.ROHook500.Res and do that drag drop into AddToApps then !Configure is in a more obvious-to-the-user location (clicking !Boot isn’t intuitive – TBH neither is a middle mouse click on Switcher or a right click on Switcher)

You could always ask the author to check and update if required

Since the author hasn’t used the software since pensioning off the RiscPC in the early noughties¹, he tells me that the standard Open Source approach of “you can always submit fixes” applies. :)

¹ He has some other way of launching applications now, apparently.

Not quite what I meant… If you look in the Apps folder in the root directory of a Raspberry Pi SD card, there are directories inside.

These are carefully hidden in the ‘Apps’ display from the icon bar. I use such subdirectories to hold downloads of various versions of the apps. Very useful facility to hide stuff in this way. Don’t tinker with this!!!

Must admit that ResourceFS Apps (and its icon) vs the $.Apps directory is a bit of a UI trainwreck that started looking silly in 1994, with the Risc PC boot sequence.

How on earth do you explain to a new user that some things are in both, but other things are only in one?! Madness.

I understood the point in RISC OS 3.1 where it basically gave you access to the ROM applications. But then it got a bit sticky.

These are carefully hidden in the ‘Apps’ display from the icon bar. I use such subdirectories to hold downloads of various versions of the apps. Very useful facility to hide stuff in this way. Don’t tinker with this!!!

I am in total agreement!

The AddTinyDir route is the way to go!

Provide an additional directory to the iconbar!

It is more probably. With the next update, they will surely fix it, and you won’t have this issue anymore. With such unpopular apps are always such kinds of problems. For example, I am using an anonymous messenger from okaapps.com, and it needs a password every time you open the app. Once I inserted the right password several times in a row, but it didn’t work. After some time, I tried again, and I inserted the same password, and it didn’t work again. Only after reinstalling the app everything started to work normally
____________________
https://okaapps.com/product/1476136371

The icon bar Apps icon has in the past been much (and jolly interestingly) discussed in this Forum: for example in
2013,
2018-19, and
2020 (this very thread).

Improvements to how apps are managed and accessed were aired, but searching was rarely mentioned, even though Windows users, for example, often use their Start menu’s search box for this purpose.

ROUGOL’s Zoom meeting this month addressed the challenge of how to help a user new to RISC OS (or indeed an old hand ¹ ) to search as directly as possible for an app on their system. This is especially in the context of newcomers using the various distros of RISC OS that bundle their apps in a variety of directories.

I’d like to propose three approaches for comment.

(1) The principal suggestion at ROUGOL was to put a search app in Boot:^.Apps so that it would appear in Resources:$.Apps, one practical issue being that Filer opens Resources:$.Apps in not exactly predictable places. So it would be good if it opened, say, always immediately above the Apps icon, and its search string writable icon should also appear close to where the mouse pointer is.

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

(3) Perhaps an entirely non-ROOL method could be to add this kind of search to the main menu of R-Comp’s Pinboard2 ² . That would avoid the positioning issue in the Apps icon methods.

By ‘suitable search app’ I mean one that has in its Choices a short list of disc and network high level directories to be searched so that its use can be tailored to different approaches to the storage of the apps themselves. The Choices could also specify a sensible directory depth limit to avoid matches among the many subsidiary apps that appear inside the likes of ArtWorks (and others).

It’s worth noting that such a search facility need not be confined to pling directories. For those who store apps by Topic (Section in PackMan, Category in Store) such a search could find relevant matches. Also, none of this implies that the apps booted and appearing in Resources:$.Apps need be any more in number than the ROM apps plus the user’s choice of their most favoured ones.

¹ Old hands have way too many apps collected over the decades and may not be able remember the name of the one vitally needed today, so searching by part-name and/or topic could really help.

² Looking forward to Pinboard2 and MoreDesk working happily together.

Some good thoughts there. My preference is something based around 2, or perhaps put it on the unused right-click on Apps, though it might be nice to have search-as-you-type and/or list with icons.

In terms of ‘suitable search app’, I’d like to suggest another approach. To list applications available, you can effectively do *Show *$Dir, and then filter for those that are application directories (so you don’t pick up StrongHelpRes$Dir for instance), and pick up the icons from the Wimp pool. This would mean that rather than having a separate Choices file to say where apps are, it follows from the already existing list of directories in Boot > Look At etc. Additionally, if the Filer sees any other applications through the day (e.g. you insert a floppy disk download an archive and open it) then they appear automatically in the list.

I’ve been thinking about installation and update of applications etc. and this would dove-tail with that, e.g. you could put a menu option on the apps in the list to call the hypothetical update command.

@ Julie

To list applications available, you can effectively do *Show *$Dir, and then filter for those that are application directories (so you don’t pick up StrongHelpRes$Dir for instance)…

I see some potential issues here, for example:

1) when copying or moving an App to Apps I don’t think the Filer re-run !Boot in the app.

2) When installing using !PackMan it seems that the “look at the App” depends on how the RiscPkg package has been configured, so it doesn’t happens always.

3) !Packman installs apps in subdirectories and not all of them as “scanned at boot”, so not all apps in Apps are actually seen by the Filer.

So one solution that should fix all the points above is:

• Create an “indexing” script that runs at boot time and that ensure to scan all subdirectories in Apps (regardless their names because apparently some people even rename categroies and re-arrange apps)
• Add a simple module that intercepts some vectors and when something is being installed/copied/moved in Apps then run a scan for !Boot of that object/directory.

If ROOL is going to add this, thats cool, otherwise I am already working on a prototype to do this for the DME.

The inseparable partner of finding applications is hiding applications. When I create or download an application I automatically put it inside a new directory with no other applications in it, so that it does not get filer_booted accidentally when I am roving the filing system, and so polluting the system variables. Probably lots of other people do this too. This is a consequence of Acorn making system variables global rather than local in some way; after all, the importance of information-hiding and namespace control was not so urgent at the time. Apologies for plonking the obvious.

In fact I very rarely find myself using the Filer’s Find option on filer_object menus. Searching millions of files and directories for a name, or for some other attribute or combination of attributes, presents a serious programming problem if it is to be accomplished without lengthy delays. Cacheing the information found in previous queries is an obvious way to speed things up, especially when time is expensive and space is cheap – the reverse of the situation in Acorn’s days.

That does then require the enviable background process scanning the disk and keeping the cached index up to date, and does it look at removable drives and other kettles of fish.

I opt for a hierarchy of sensibly named sub folders under Apps, so I can both easily find an application based on category even if I’ve forgotten its exact name, and also not very application is booted by the filer. The apps I want to pick up file types automatically are put in Configure→Boot→LookAt.

Below is a quick and dirty RiscLua program to scan the current filing system and print out all the application names. I have just run it in a taskwindow and it reported 3892 items in 196.14 seconds (on a Rpi3). I was amazed at the cruft that I seem to have accumulated and I will use the program to investigate. The leaf names must start with a pling ( pattern “^!” , line 2) but you can edit this to impose a more restrictive condition.

#!lua
local app_name = "^!" -- << edit this to suit
-----------------------------------------------
local dir in require "riscos"
local clock in os
local root = (arg[0]):match "^[^%$]+%$"
local j, n, dirt, appt = "%s.%s", 0, 0x1000, 0x2000
blank = " "
local f
f = \ (src, level)
    local act = { [dirt] = f; [appt] = f; }
    for leaf, ftype in dir (src) do
      local obj = j:format (src, leaf)
      if leaf:match (app_name) and ftype == appt then
        print (blank:rep (level), leaf)
        n += 1
      end -- if
      g = act[ftype] --<< note square brackets
      if g then g (obj, level + 1) end -- if
    end -- for
    end
local t0 = clock ( )
f (root, 0)
local t1 = clock ( )
print ("----------", n, "items in ", t1 - t0, "secs")

NB. I tried searching for some of the items thrown up by this program using the filer’s Find option. It gave up and complained that it had run out of free memory! So maybe there is a case for garbage collection being built into the OS at a low level. Lua is often used in bare metal scenarios. I would like to see it as a common resource. But this hobby horse is maybe a distraction at this point.

And BASIC can do this, of course, with perhaps less elegance. ;-)

Time%=TIME
PROCFindApps("SDFS::System.$",Items%)
PRINT;Items%;" items in ";(TIME-Time%)/100;" secs"
QUIT
DEFPROCFindApps(path$,RETURN items%)
 LOCAL next%,read%,file$
 REPEAT
  IF read% THEN
   IF !&8210=2 THEN
    file$=path$+"."+FNString(&8214)
    IF ?&8214=ASC"!" THEN PRINT file$:items%+=1 ELSE PROCFindApps(file$,items%)
   ENDIF
  ENDIF
  SYS"OS_GBPB",10,path$,&8200,1,next%,&100,0 TO ,,,read%,next%
 UNTIL next%=-1
ENDPROC
DEFFNString(addr%)
 SYS"XOS_GenerateError",addr% TO $END
=$END

This did 4817 items in 46.33 secs in a task window on my mini.m.

There is a question about searching image filing systems. This does not, and repeated entry into images can clog things up a bit.

I would also refer back to my AppUtils which can be used to make many of these thing happen.

Try changing “System” to “0” (zero) on line-the-second!

Less problematic than renaming your SD card!

It’s a general recursive procedure. Call it with any path you like. ;-)