Any Low Hanging Fruit Left?

Hi Guys, I’m aware of the RISC OS Roadmap wiki page: https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20Roadmap and there’s plenty of things that need looking at for sure.
But I’m wondering if there are any relatively easy stuff (the low hanging fruit) that can be worked on by other developers?

Ever since Jeffrey first ported RISC OS to the Cortex-A8 back in 2008 or so, he’s been very busy fixing/extending/upgrading RISC OS. Just want to know what are the things that could be worked on by other developers who are perhaps not wanting to delve too deep into the mysteries of RISC OS.

BTW, Jeffrey, if your’re reading this, RISC OS is far more stable than it has ever been. I’m on the latest night builds and I can’t believe how much better it is than just 12 months ago. Awesome work.

Something that isn’t a ‘core OS’ thing is packaging of disc components, to make upgrades easy. We have some infrastructure for doing in-place Raspberry Pi ROM upgrades, but it hasn’t had as much attention as I would like. Ideally the build system would output components with PackMan metadata, which would mean PackMan is able to upgrade them automatically. The main thing is to make sure it can be done repeatably (ie generated from the makefiles and CVS information, rather than by hand) so it doesn’t require a human to go in and do it for every build.

Automatic upgrades of ROMs is also feasible, but a bit trickier (more dangerous if it goes wrong).

Perhaps some of the higher-level things? For example, Style Guide compliance and Clipboard functionality into Draw and Paint etc.?

Specifically on the Pi, perhaps a Configure plugin which provides a simple UI for managing all the fluff for config.txt in the boot partition? Could include things like an ‘X-power-up’ to reset back to a ‘safe’ default.

A curve ball: investigate what is needed to support the cheapo USB wifi dongles (like the official Pi one).

BTW, Jeffrey, if your’re reading this, RISC OS is far more stable than it has ever been. I’m on the latest night builds and I can’t believe how much better it is than just 12 months ago.

Excellent – it’s good to hear that things are heading in the right direction. It’s often hard for me to tell how unstable things are myself, because most of my time is spent writing/debugging code rather than using a system like an ordinary user.

Awesome work.

Thanks!

In terms of low-hanging fruit, I’d say it’s worth considering the Paint and filer bounties. The Paint one is a bit meaty, but you don’t really need any knowledge of the internals of the OS to work on it – just C, wimp, and sprites.

Other things I can think of:

• Changing the Debugger module to use the BKPT instruction for breakpoints – to allow us to get rid of the page of memory that it currently uses (with zero page relocation). Good for experienced assembler programmers. However there might be a bit of kernel work required to make sure the kernel calls the debugger on a BKPT instead of the standard prefetch abort handler.
• Getting rid of the zero page workspace used by FPEmulator – another good one for experienced assembler programmers. At the moment FPEmulator is the only component (other than the kernel) which needs to know at compile time whether zero page is down low or up high, so it would be good to get that fixed. It will require you to stare at the source code for a while to make sure that all the control paths pass through whatever register is being used to store the workspace pointer. When I had a quick look at this a few weeks ago I reckoned that the structure it builds containing the ARM register dump (pointed to by r11 or r12, I think) could easily be expanded to store the workspace pointer (it’s already been expanded to store the PSR in 32bit builds of the module, so it’s not a structure layout that’s set in stone)
• New OS_SpriteOp to read the details of a hypothetical sprite – Should be easy to implement, although it looks like we haven’t yet reached a decision on the best place to implement the code (i.e. kernel or SpriteExtend)

In terms of low-hanging fruit, I’d say it’s worth considering the Paint and filer bounties.

Lower hanging¹ fruit than that – keyboard shortcuts².
Done a few already³, trying to create a three finger salute at present.

¹ Root vegetables?
² Where the RO6 stuff seems sensible I’m using those, if not then I’m following QuickFiler.
³ Mostly a case of finding a way to link in pre-existing code and not cause zero page errors.

Try reading through this? https://www.riscosopen.org/forum/forums/5/topics/3389

I think it boils down to:

• Some filer improvements
• Less crashy Toolbox (re.https://www.riscosopen.org/forum/forums/5/topics/3389?page=2#posts-44157)

There is a lot more that was done to the other branch, but is lower level stuff that doesn’t tend to feature on “things we’d like” lists; though if you’re interested, here is a list that Chris Evans posted: https://www.riscosopen.org/forum/forums/5/topics/3389?page=3#posts-44183

Try reading through this? https://www.riscosopen.org/forum/forums/5/topics/3389

I think it boils down to:

Some filer improvements Less crashy Toolbox (re.https://www.riscosopen.org/forum/forums/5/topics/3389?page=2#posts-44157)

There is a lot more that was done to the other branch, but is lower level stuff that doesn’t tend to feature on “things we’d like” lists;

I think the saddest item is the Toolbox, which I don’t think has a public release for the most recent version. Sad because it’s lack of cross branch adoption meant developers were best advised not to use it to avoid wasted effort or duplicated development streams. If only.

I was reminded of some of the items by the link to Chris’s list and noted “Adjust click on switcher opens Configure.”
Now wouldn’t that be an extremely low hanging item?
All we have to do is beat up any objectors…

trying to create a three finger salute at present.

So, if you were wondering where that TaskManager_Shutdown for a reboot gets called from then insert

   TEQ     r2, #&3B           ; Ctrl-Shift-End

   BEQ     key_reboot         ; Key combination for shutdown and reboot

   SUB     r2, r0, #&180

I was reminded of some of the items by the link to Chris’s list and noted “Adjust click on switcher opens Configure.”
Now wouldn’t that be an extremely low hanging item?

Extremely, provided one is proficient in both ARM code and wasting their time.
http://www.heyrick.co.uk/blog/index.php?diary=20141101 (item #3)

Also discussed here: https://www.riscosopen.org/forum/forums/2/topics/2763

All we have to do is beat up any objectors…

We wouldn’t need to periodically consider reinventing this wheel if it was just added to the OS like it seems the majority of us want (majority defined as “several who desire it and (as far as I can tell) only a theoretical objection”). ;-)

All we have to do is beat up any objectors…

oh no!

I’d prefer select to open configure and adjust to open the task manager. I think the use of configure is much more common than the use of the task manager so picking the task manager off the menu or using adjust is no big deal.

I look at TaskManager all the time. RISC OS, hundreds of megabytes of free memory… I feel like soon I’ll wake up and it’ll be Windows95 all over again.
Okay, I’d be twenty years younger, but dealing with W95 again would put years on me. That was the era of “went wrong? just reformat your harddisc and start again!” (something I note that Apple seems to think is the ultimate way to cure bugs in iOS).

I think some of the best “low hanging fruit” would be to look at improving the bundled apps, and perhaps their UI etc.

As a reference point, looking at the functionality of the RISCOS Ltd versions gives some possible ideas. For example, !Paint’s JPEG and PNG handling facilities would be very welcome (ability to load/save JPG/PNG images eg. when taking screenshots or saving indvidual sprites). The fact that !Paint can’t easily output (haven’t tested recently, must admit) cross-platform formats is a big limitation. This is esp important for things like screenshots, as users really don’t want to be emailing 1080p+ spritefiles in 32bpp!

Another useful improvement would be cut’n’paste in icons although the implementation of this will likely cause much debate. Again, this was done in Adjust, and for a large part is a worthwhile improvement.

The filer could do with thumbnail mode like PhotoFiler, and the ability to remember / auto-detect folders to which such settings are applied. Thus one could open a folder of photos and see thumbnails quickly. Caching them in !Scrap or somewhere would also be a nice touch.

Also, having just been working at 4k on ARMX6, and discussing the ups and downs with Sprow, some method for configuring EX0 EY0 screen modes would be good. Additionally, I had to write a separate app to auto-correct for modes >2:1 ratio. The OS could do with changes to support 2.35:1 resolution monitors without assuming they are non-square pixels. Also, when permanently (ie. via !Configure) to E0 modes, the theme needs refreshing (and ideally some way for apps to be re-iconsprited) to Sprites11 etc.

This is esp important for things like screenshots, as users really don’t want to be emailing 1080p+ spritefiles in 32bpp!

You could always use !Snapper, of course. Much more versatile at screen shots than Paint, and I added PNG and JPEG support some time ago now.

http://www.chris-johnson.org.uk/software/snap.html

I think the use of configure is much more common than the use of the task manager

This certainly does not apply to me. I very rarely use configure – why does one need to keep changing the basic machine configuration? However, I use the task manager display frequently.

• Checking the DA usage for Netsurf to try and forestall it crashing when its DA reaches 128MiB
• Checking whether a third party app is actually still running after it has exited abruptly, and the author sets a sys$var in !Run which is not reset when the app exits
• Checking whether my own apps are giving back memory correctly as I intended!
• Etc, etc

I would not like to see opening the task manager display become more than a simple single click.

“Adjust click on switcher opens Configure.”

Why not make both Select and Adjust click configurable. A default of:
Select Click: Task manager
Adjust Click: !Configure
would I think satisfy the vast majority. Possibly even ROOL!

I’m happy enough for adjust to be configure it just seems to me that a novice would be using configure and the use of the task manager is more advanced stuff. No point in making it configurable as you need to get into configure to configure it and once you have figured out how to do that you don’t need to change it.

I believe the stated ROOL objection to the switcher change (which has already been done, but not accepted) was that adjust-click might be used for something else in future. Since !Configure can already be accessed by the menu or via !Boot, it was vetoed.

I don’t want to open a debate on this (as I rather like adjust-!Configure too) but merely state that the work for that has already been done and rejected.

Thanks to Chris for the Snapper tip. There’s always (worthwhile) debate as to the value of bundled apps vs pd/freeware alternatives. When I was at RISCOS Ltd, I felt that the lack of free “page-based” text software (ie. word processor) was a significant omission with the default disc build (!Edit isn’t a word processor). This lead to !Writer which was designed to fill the gap between !Edit, !Draw and !Paint. In one way, I’d still like the bundled apps to include this, but with Fireworkz available for free, it seemed foolish to recommend re-creating something that can already be obtained for free.

However, with !Paint, the functions are already present, so my suggestion was to expand the “baked in” functionality that already exists to make it more useful. You could (acceptably) argue that adding JPEG/PNG stuff to Paint is unnecessary because !ChangeFSI can be used to convert to/from JPEGs and convert PNGs. However, I would argue that !Paint would be usefully improved by integrating the functionality, even if initially it merely utilised ChangeFSI.

Note that PNG support would be particularly useful in !Paint due to the newer masking support. AFAIK PNG is the most logical “platform independant” format that would losslessly retain the data in the sprites.

I’m now wondering if SpriteExtend could usefully be extended to cover PNG files…

I’d prefer select to open configure and adjust to open the task manager. I think the use of configure is much more common than the use of the task manager so picking the task manager off the menu or using adjust is no big deal.

You’re probably right about the commonest function (strange people that look in task manager aside) but I was working on the basis of adding a function on an “unused” click.
However, since adjust-click currently opens task manager as well, then making select-click the open configure option is actually a minimal change – in fact exactly the same as changing adjust-click to open configure.

The left click is of course more natural to new users coming from winders or penguinos and, well pretty much any other OS.

The filer could do with thumbnail mode like PhotoFiler

I’d personally like to see another PhotoFiler feature; an option to hide the ! character from applications. In my opinion this makes the system look a bit more modern and less scary for new users. I tried to investigate doing this once but got scared off by all the assembler :)

Of course, the easier solution is “just use PhotoFiler”!