RISC OS DME Launchpad released

Hi Herbert,

are there any plans to offer a download without the need to use PackMan.

Yes, the link to download a “!Boot” image (aka no Packaman needed and everything is in one zip file) is on the top post (look in the section RISC OS 3.50/3.60/4.XY AND 6.XY), here I put it again for your convenience:

- Download this pre-configured !Boot image here:
https://riscoscommunity.org/zip/riscos/dme/DMELaunchpad_0.0.1.zip

All DME components detect the version of RISC OS they are running on, so the code is always the same for all the distributions :)

To install it, unzip and either copy it on top of your existing !Boot or use the installation facility in !Configure, whichever you prefer.

At the moment the only minor exception is the distribution for risc os 3.1x where the code is absolutely the same, but the default configuration is set to use less RAM.

Hope this helps!

[edit]
In case people are seeking for PackMan distribution and they land on this new page first, please look at the first post on the first page for all distributions and installation instructions, thank you.
[/edit]

ROOL’s RiscPkg repository should house anything that becomes common practise.

I believe ROOL do host 3rd party packages on the thirdparty URL. There’s probably a page about how to request it somewhere, which I can’t find at the minute and its not mentioned or linked on the Allocation page from a quick glance. Probably just email the allocation address I guess.

I seem to recall you provide ROOL with a URL to your package file and its then synced to the thirdparty repository, so it’s only ROOL hitting your own site.

Don’t forget, there’s also !Store as a place to offer software.

Hi Jame and welcome to this forum :)

Has this been set as the default approach by ROOL yet?

No. The specific DME component is in Alpha code quality state at the moment, I have made it publicly available for the sole purpose for who is interested to help me debugging it.

Will it be available to ROOL? The licensing of the entire suite allow this to happen yes, so, when stable it can be made available to ROOL.

Is ROOL interested in having it? No idea and I am not affiliated, nor I have private communications with ROOL.

If so, could we kindly make a statement and add the method to the ROOL repository rather than one of our own websites?

Surelly when in stable release I can setup a channel to allow ROOL to include it in their 3rd party list.

However, just to be clear, all my RISC OS code gets stored on github.com, not my “own website” and yes it is possible to use github.com also as a repository for RiscPkg packages and even distribute them just using github. I am contemplating doing this, I just had not enough time to do the required work.

As a clear statement:

I have nothing against ROOL distributing my packages when they are in a stable state, while I do not wish them to distribute my work when it’s not in a stable state.

I am not going to push my sources in the ROOL gitlab because I have seen what has happened with CObey and other modernised approaches. I am a strong believer that there is no point in doing work for free if then it’s not going to be used, hence the need for having my own distribution (which doesn’t preclude a future RISC OS fork if and only if it’s needed to pursue the project’s goals, just to be absolutely clear, given that somone seems to be “weighting” also my old statements).

This is not a complain against ROOL (which I thanks for all their work and effor ton RISC OS), again let’s be very clear, they have their process and goals and this is absolutely fine with me, but I have my own goals and process as well and don’t want to feel limited in what I’ll try to explore to obtain a modernised RISC OS (in whatever extent this might be possible technically). Also, I do not wish to push my source code directly in any “company” type organisation (aka the Ltds to be clear), that is because I don’t see the point of running RISC OS organisations as companies and because developers may have contractual limitations that could forbit them from collaborating with such type of entities. That doesn’t mean “my way it’s the only way”, I am just motivating my decisions with my own (and my own only) opinions.

Hope this helps,

Don’t forget, there’s also !Store as a place to offer software.

Just as a note: I am not forgetting !Store, the all inclusive !Boot structure is meant (when stable) to be distributed via !Store as well.

Also, before we get into a long discussion about distributing software, there is always also RISC OS 3.1x user-base for which my website should be more than enough, given there isn’t a central repository for them.

You guys do realise you’re replying to a spammer, right? (Look at the full stop after “practise”.)

Wow. A spam link in a full stop. That’s flying so far under the radar that it’s bordering on being utterly pointless.
(going by the URL, it appears to be pricing and times for a bus in Lahore, Pakistan; something I’m sure people here will find absolutely indispensable!)

You guys do realise you’re replying to a spammer, right?

That speacks loud about the nature of folk’s questions on this thread! ahahahaha XD

Well, sorry, I missed that one. I was suspicious of the domain, but the poster’s spam score was zero.

Gone now.

thanks Dave! :)

To everyone interested,
NEW Launchpad alpha release (0.0.2-1) available for testing.

Thank you so very much to all the many users who have tested and reported ideas and problems with previous alpha code, sorry for the delay of this build, but there were other RISC OS tasks to complete and also got. alot of feedback to go through, so there has been some work! :)

What’s new?

Changelog for release 0.0.2-1:

- Fix: Return/Enter key not running app displayed on the top left when no others are selected (like macOS can do)

- Fix: a bug that was causing issues when selecting the first icon on the top left of the Object Filer and then selecting a different one (the icon at the top left would not get unselected visually).

- Fix: a bug when clicking with mouse Menu button on an icon in the Objects Filer and no icons are selected already then select that icon before opening the menu

- Fix: now you can visually add objects to favorites (drag’n’drop them on favorite tab) and also combine this with the selected category (or tags set)

- Fix: a minor bug in that (randomly) was causing caps lock to shift while user was typing a search keyword without requesting for the caret first

- Added support for underscored category names (as per a user request)

- Increased menu memory poll size to have more categories (as per a user request)

- “Shrunk” the default space between icons as per requests of some user who wanted it to look more like the traditional Filer layout (as per a user request)

- Enabled ObjectFilerLIHSpace and ObjectFilerSIHSpace settings to set horizontal space between icons on the same row

- Enabled ObjectFilerLIVSpace and ObjectFilerSIVSpace settings to set vertical space between icons on the same column

- Enabled ObjectFilerBottomSpace to set an arbitrary amount of pixel to be left at the bottom of the ObjectFiler Window

- Added Hourglass when launching an App, to help with old/slower machines

- Added that if a user requests a refresh when they Main Window is opened, then it will be re-opened automatically when the refresh is completed

- Added initial support for Shift + Select (or Adjust) to open an Object (as on the regular Filer) (as per request of a user)

- Improved overall performance (both start up and icons redraw performance)

Tested on:

• Acorn Archimedes 310, A3010, A3020, A5000
• Acorn A3000 on MiSTer FPGA
• Acorn A7000+ and RiscPC, RPC SA, Kinetic RPC
• Castle Iyonix and A7000+ (54Mhz)
• Raspberry Pi 1, 2, 3, 4 and 400, Rpi 0
• Pandaboard ES
• Beagleboard
• PineBook, PineBook Pro
• RISCOSbits FAST and Quadro
• RPCEmu
• Virtual Acorn SA
• Arculator
• ArchiEmu
• ArchEm

RISC OS releases:

• RISC OS 3.10, 3.11, 3.20
• RISC OS 3.50, 3.71
• RISC OS 4.02, 4.03, 4.39 and 6.10
• RISC OS 5.28 and 5.29

Enjoy and keep the feedback coming, thank you!

P.S. download links updated on top post on page 1 of this thread here: https://www.riscosopen.org/forum/forums/1/topics/17696#posts-138095

for !PackMan users, just run an update :)

[edit1]
Added “Improved performance” to the CHangelog list
[/edit1]

[edit2]
Added list of systems I tested it on and releases of RISC OS ’cause people keep asking if it runs on old RO, yes it does up to RISC OS 3.10 on ARM250 and ARM3! The assembler portions of it are written to run everywhere.

A lot of the things in the DME project run from RISC OS 3.10 on ARM250/ARM3, the only limitation on these old systems is memory, hence the specific release for the old Systems (which is identical in terms of code to every other release, except I am trying to squeeze as much memory as I can).

When the !Configure plugin for the DME will be available, users will be able to enable which components they want, to save memory or to have their own custom configuration for the whole system.
[/edit2]

I’ve tried this out on RPCEmu/RO 5.28 and I’m quite impressed with it. I have some suggestions, however — it may be in some cases that these features are already present, but since there doesn’t seem to be any specific documentation that I can find, I can’t be sure.

Launchers on other OSs can usually be triggered by a key or keys— the Windows or “super” key (Windows itself, and several Linux distros including Ubuntu, Zorin, Mint), Windows+space (Elementary OS), Command+space (MacOS).This would need to be configurable by the user, for example the Pinebook Pro has a “Pine” key but this is used as an equivalent of a Menu click.

However it’s triggered it would be nice if once the window is shown I could start typing into the search box straight away (if this is possible on RISC OS). As it is it seems I have to click in the window (or in the box itself) first.

There are — IMHO — far too many categories available, which makes it harder to select one from the list. I’d suggest restricting it to the categories in the XDG standard used on Linux,,provided the user is able to add to these as necessary.

hey David,

I’ve tried this out on RPCEmu/RO 5.28 and I’m quite impressed with it.

Thanks, I am now fixing one minor bug found on the last build and then will proceed to enable more features, which are not enabled yet to make sure there would be just a small amount of reports for bugs (‘cause unfortunately I don’t have much time for RISC OS work and have already plenty of other things going on).

Launchers on other OSs can usually be triggered by a key or keys— the Windows or “super” key (Windows itself, and several Linux distros including Ubuntu, Zorin, Mint), Windows+space (Elementary OS), Command+space (MacOS).This would need to be configurable by the user, for example the Pinebook Pro has a “Pine” key but this is used as an equivalent of a Menu click.

Indeed.

Right now, I just made it use the Win key to open the Apps browser window, the reason for this is that I am also developing a Global Shortcuts handler Module (which is the correct way these things should be handled). When this new DME component will be available then yes you’ll be able to configure whatever key combination you want to open the Apps browser window :)

(hope this answer in part to your question)

However it’s triggered it would be nice if once the window is shown I could start typing into the search box straight away (if this is possible on RISC OS). As it is it seems I have to click in the window (or in the box itself) first.

You can do this already. And yes, also this feature (like the Apps main windows automatic opening) works on ALL RISC OS releases included 3.10! However, there is a catch, given that RISC OS itself can’t do this correctly, I had to add a “compromise” to avoid the feature to cause trouble to other Apps. The “compromise” is that the “autocaret” (the name for this feature) works only if the mouse pointer is ON the Apps browser window and if the Apps browser window is in the foreground (top level).

I could just consider if the window is in the foreground and add a check to see if something else has the caret, but that feels a bit like a “hack”, ‘cause I have to investigate the desktop instead of relying solely on the user behaviour (which seems a cleaner way to implement the feature). So, I put this to vote: If anyone would prefer less limitations to the “autocaret” feature to just be able to start typing even without the mouse being over the window let me know, and I’ll add it :)

There are — IMHO — far too many categories available, which makes it harder to select one from the list. I’d suggest restricting it to the categories in the XDG standard used on Linux,,provided the user is able to add to these as necessary.

The categories are something that is under your complete control. You have no limitations, you can reduce them or increase them, you can replace them entirely or even remove them and not use them at all.

You should be able to edit your category using the Edit option at the top of the menu. The categories file is just a text file with help comments that tells you how to structure your own categories.

Don’t worry, when you update, nothing of your configuration will be overwritten, and you can also update !Launchpad without saving your configuration, it will be saved (automatically) during the update process (If you use !PackMan) and before things are changed. So, your data should always be preserved. (I say “should”, because it’s still in alpha code quality, although if no one has reported issues with data consistency, so I guess that part seems already very stable)

Hope this helps and thank you very much for all your useful feedback! (stay tuned for the next release!) :)

Quick note for everyone who asked about adding Application Installation via !Launchpad:

Short answer:

YES, it’s totally doable and I started some experiment. Hopefully I’ll have something for people to test in the next few months.

Long answer:

Dragging a new App out of a zip file into a directory to install it is nice; probably one of the most iconic feature of RISC OS, that ended up being copied by macOS X! However, it presents the limitation that makes it really hard to track updates for such App (and for all the apps installed in such a way!). To solve that problem people have been working and gave us !PackMan which I love, but that has not drag and drop an App and be done with it.

So, while I recommend to learn how to use !PackMan (and maybe I can have a chat with Allan and ask if he wish to add some feature to automatically link an installed App to! Launchpad), here is how installing Apps via !Launchpad would work (early experiments, needs feedback!)

Questions that are in need of the userbase’s feedback:

How to distinguish if it’s an installation action vs just linking an already installed App to !Launchpad?
The first issue with installing an App using !Launchpad that we need to consider is: Is this action an installation OR is it a linkage of an already installed App?

To solve this, I added a new icon on the top bar and all a user will need to do is drag the App to be installed on that icon instead of on the App browser window and the App will be installed and also catalogued!

Do you think this would be good enough? Intuitive Enough? (Please let me know, even by email/twitter/facebook is ok, I know many of you prefer to use other “channels”!)

Where should the App be installed?
The next issue to consider is: Where should the App being installed? Sure, in Apps (specifically Boot:^.Apps), but WHERE in Apps?

To solve this, I have decided to use the Selected Category name (it will be transformed into a directory name which has no spaces and uses “_” instead of spaces)

Would this be good enough for you? (Remember: you can completely control the categories!)

Some F.A.Q

What happens if a remove an App?
- If you have configured !Launchpad to check automatically, then next !Launchpad run, System run or after a refresh, the removed App will disappear from !Launchpad automatically.
- If you have configured !Launchpad NOT to check then you’ll have to remove the link manually, by selecting the removed app icon on launchpad, open the menu, go to Selection and then click on Remove.

What happens if I install an App via the procedure above and then I want to add it to more categories?
- That is not a problem, once installed you can add it to all the categories (or tags) you want. If you wish to know where the App is installed, then select the App icon, open the menu, go to Selection and then click on Show in the Filer and it will show you where the physical App is installed.

Can !Launchpad make me a coffee/Tea?
- No, sorry, BUT, using !Launchpad’s macros system, you can control your Raspberry Pi GPIO via !Launchpad and from there control your coffee machine! ;)

makes it really hard to track updates for such App

I’m surprised there was never a mechanism defined for apps to check for updates themselves . . . as is commonly done elsewhere.

My Manga, and some of my stuff for Windows, would connect to my server and fetch a tiny control file that tells what the latest available version is. If later, the user would be notified.

Perhaps a update option on the programs Icon bar information menu.

I’m surprised there was never a mechanism defined for apps to check for updates themselves . . . as is commonly done elsewhere.

Same thoughts, never understood why Acorn or who followed never really defined a “standardized” way to have an easy way to update Apps beside having to scan the entire internet XD

And if we won’t add more code to write to a developer, all it required was adding a new text file in each App, even in INI format stating:

[app]
url=<where-is-located>
name=<zip-file-name>
release=<installed-release-number>
md5=<md5>

Where md5 is optional.

We could have called it !Info and add it insde the !App directory. Either the App itself OR an OS based tool could have used it to check for updates.

There are (obviously) other ways too, but this one is uber easy (and we already have INI file libs for BBC BASIC, C etc. and if a language is missing it, it’s trivial to implement).

Sometimes (Darth Vader Meme): “I find RISC OS lack of pragmatism, disturbing!” XD

However, in RISC OS’s defence, actually Mac OS X (until Apple Store) had the exact same problem and people had to develop 3rd party tools to solve it (such tools where using the App metadata, hence they did add something like the above to macOS Apps).

We could have called it !Info and add it insde the !App directory.

Creating a set of such files to drop onto existing applications is, perhaps, something that a non-coder could do

Either the App itself OR an OS based tool could have used it to check for updates.

IIRC there’s a tool out there that scans a directory /disk checking for Help files in applications/tools which should give a clue or two how the check could be done if no one comes up with a better idea.

Edit: After a quick dig, I’m conflating two items – HelpScan (which doesn’t check files/directories, but rather checks variables) and DateSpy which checks directories, and subdirectories, for modules and reads their date info.

Edit2: “VerInfo” is probably a less likely clash with existing files

Scanning a disk can take a long time. This little skeleton program, for example

-- Scan current disk for a file
local target = "!info" -- nb. lower case
local herepat, join = "^[^$]*%$", "%s.%s"
local root = (arg[0]):match (herepat)
local dir in require "riscos"
local clock in os
local N = 0
local found = { }
local search
search = \ (d)
  for leaf, ft in dir (d) do
    local this = join:format (d, leaf)
    N + = 1
    if ft == 0x1000 or ft == 0x2000 then
      search (this)
    elseif leaf:lower ( ) == target then
      found[1 + #found] = this
    end -- if
  end -- for
end -- function
-- main
print ("searching ", root)
local now = clock ( )
search (root)
print (#found, " items out of ", N, " in ",
       clock ( ) - now, " seconds")
print "------- finished"

searching       SCSI::HardDisc4.$
80       items out of   240983   in     117.94   seconds
------- finished

“VerInfo” is probably a less likely clash with existing files

Another way would be, fo reach app exposing the file to create an `App$Info` variable, which would also speed up the scanning (scan vars instead of the entire disc and only check those that have the App$Info variable set).

Same thoughts, never understood why Acorn or who followed never really defined a “standardized” way to have an easy way to update Apps beside having to scan the entire internet

To be fair, “the internet” as a concept was quite new in the Acorn days. If you recall, there was precious little support for it in Windows 95, and Acorn gave up the ghost in 1998 in the height of the madness of The Browser Wars. Hell, back in those days one could still use ArcWeb and Webite to browse the various websites.

Following Acorn’s demise was a brief shocked hiccup, followed by… some unpleasantness.

Besides, there were sources like Poppy’s site, the Acorn Cybervillage, Drobe, and various others that I’ve forgotten. Oh, and anything of use I’d have dropped on Arcade. ;)

And if we won’t add more code to write to a developer,

More stuff in the RMA running in SVC mode, whee!

even in INI format stating:

My method did require some additional code (well, I lie, I wrote the code once and I just include it when it’s required ¹). It fires off a fetch to some-url-here/path/appname/update.txt and it gets a file that contains a file version number, the reference to the update file, and a textual information string saying what’s changed. Here’s an example: https://heyrick.eu/software/verodes/update.txt

The program would check its version with that in the file, and if the file is newer, prompt if the user wants to update using the description as a reason why they might want to.

There was no MD5, but the file paths were always treated as relative, the system just won’t allow a reference to a file on another website (the Windows incarnation was stricter and wouldn’t allow outside of where the update.txt file was fetched from; this was relaxed within RISC OS because it was a load of code I couldn’t be bothered writing ;) ).
Plus, if the update file can be tampered with, so to can the MD5 in the description, so it didn’t seem to be worth bothering with. MD5 is only useful if it comes from a different source to the file (which makes sense if you download something via torrent or a third party mirror).

an OS based tool could have used it to check for updates.

The problem with that is that it requires the user to manually check. Wouldn’t it be better if the app itself could take a quick check when it starts, and notify you if there’s an update?

The other problem is that it can’t really work as a SWI call or *command because of the async nature of fetching stuff. So it really needs programmer involvement. That being said, no reason most of it can’t be stuffed into a library…

Scanning a disk can take a long time.

Yup. And it looks like your skeleton doesn’t actually open any files it finds either, which will take longer.

That sort of thing probably ought to be pushed to the background. Look at a couple of files, poll, look at a few more, poll, repeat until done.

¹ Except Manga, that was written anew because, well, it wasn’t Windows and it had some customisations due to being an optional beta-user thing. If you’re at all interested, it’s check_for_updates() towards the end of c.wrapper.

Scanning a disk can take a long time. This little skeleton program, for example

True, but don’t forget that for update checks, that takes even more time (you need to query a webserver that may be down or disapeared and wait for a time out), or you may not have internet set or a very slow one.

Beside the above, one way !Launchpad can scan for things is “in background” (aka during a NULL event), so that will be completely transparet to a user, but again, users can disable it and scanning for variables is still better.

However, scanning for variables has the side effect that, if something hasn’t been seen by the filer yet, it won’t be checked.

So, as usual it’s a question of what would be the best approach.

Given this topic is moving away from the feedback I asked for !launchpad, can we please open a new thread for this discussion which I believe it’s useful :)

Right now, I just made it use the Win key to open the Apps browser window, the reason for this is that I am also developing a Global Shortcuts handler Module (which is the correct way these things should be handled). When this new DME component will be available then yes you’ll be able to configure whatever key combination you want to open the Apps browser window :)

Do you mean that the current available version uses the Windows key to open the browser window? If that’s the case I would need to look at changing the default of the “Pine” key to provide a menu (middle button) click before trying to use Launchpad; I might do that anyway, as the menu key on PCs (where I’m using Virtual Acorn) is on the right (if it even has one) so it seems a little odd using a key on the left instead.

scanning for variables is still better

It is certainly more efficient than scanning the disk. Another possibility (did I miss it or has it been buried under a shower of aspersions?) is a registry of some sort, that is updated at installation. But that knocks on the head the ease of moving applications around afforded by the Obey$Dir mechanism – a central, feature of RISC OS, currently insecure (though Paolo may have a remedy for that). Registries fit when there is a distinction between the installer and the user of an application, a social division alien to the spirit of RISC OS, IMHO.

Do you mean that the current available version uses the Windows key to open the browser window? If that’s the case I would need to look at changing the default of the “Pine” key to provide a menu (middle button) click before trying to use Launchpad; I might do that anyway, as the menu key on PCs (where I’m using Virtual Acorn) is on the right (if it even has one) so it seems a little odd using a key on the left instead.

Yes, right now !Launchpad uses the Win key to open the Apps browser windows, but I would NOT try to change the Pine key setup on the Pinebook Pro (my experience with many RISC OS utilities is that many aren;t designed to handle well different configurations). If you can wait for the Global Shotcuts Module, it will allow you to set whatever key combination you want for !Launchpad. Just my 0.5c