Dark theme?

Has anyone come up with a dark theme for RISC OS?

I use a very dark theme for my Linux Mate desktops on my laptop and Pi 4B’s, and when I switch to RISC OS, particularly at night, I get blinded by the lightness.

I’ve got a dark pin board image, and could create dark window tools and backgrounds, but crucially RISC OS lacks the ability set default desktop text colour to white to make these usable. The contents of application windows wouldn’t be affected, but the most popular editors support white on black.

I’m after this for mainly cosmetic reasons, but as RISC OS users aren’t getting any younger, dark themes provide additional contrast which are helpful for those with degrading eyesight.

How well does RISC OS do at themes in general? It seems largely limited to fiddling the window furniture. But windows? Buttons? Backgrounds? Etc etc.

That being said, my phone does dark mode but it breaks loads of applications (that aren’t expecting it or have their own dark mode implementation). I’m not exactly sure how Android’s dark mode works, but it appears as if it simply hijacks and fiddles the foreground text colour and the background screen colour.

Perhaps some abuse of filters and events could do similar for RISC OS?

Has anyone come up with a dark theme for RISC OS?

Yes :) – but it’s not finished yet… (I demoed something on these lines a while ago at a ROUGOL meeting BTW)

How well does RISC OS do at themes in general?

RISC OS WIMP is “primitive” to say the least (and I hope this is not a rude comment!)

To do proper modern themeing the WIMP needs rewriting, there are a set of issues that span from difficulties on customising the borders look, to the way icons are managed, to the way colours palette worked on the Archimedes and more…

However, the biggest issue is the way people designing their icons. As usual the minimalistic effort is the root of evil, and IMHO, one way to solve (or reduce) this is maybe design a tool specifically made to design Application’s icons.

Let me explain, many icons are simply NOT designed to have a dark background (or any other background!), the assumption is just a greish one (full stop).

Other issues are like: menu appearance on the icon bar is set with a literal hight from the bottom of the screen, so, if we make the iconbar movable for instance (like move it on the left side of the screen in vertical mode) then weird things will happen with certain applications when clicking middle mouse button to open their iconbar menus.

This is the result of a primitive desktop that never got developed to handle more than the default appearance and structure.

It seems largely limited to fiddling the window furniture. But windows? Buttons? Backgrounds? Etc etc.

In my DME project I have wrote a full new tool for themeing that goes above and beyond what that atrocious tool we have now goes, it needs to be finished, but YES it handles Palettes¹ so YES it allows Dark Mode to be made. It also handles all old Richard Goodwin themes and some others as well (and the ROOL’s ones too).

A theme is expressed through a manifest file that controls every possible aspect (with the WIMP we have now obviously). Next I am adding some extra features to the windows (for instance to have thiker borders, required by some of the new themes) and other features.

It has been demoed in a very very early stage at a ROUGOL meeting.

That being said, my phone does dark mode but it breaks loads of applications (that aren’t expecting it or have their own dark mode implementation).

Same on RISC OS. However, ROOL came up with an idea that is good, an App can have iconsets based on the selected Theme, so the Iconsprite won’t mess icons on the screen, but, as usual, no one is using that feature in their apps (I haven’t seen one yet using that feature at least), so yes biggest problem are our Apps, followed by the primitive WIMP.

I’m not exactly sure how Android’s dark mode works, but it appears as if it simply hijacks and fiddles the foreground text colour and the background screen colour.

Dark modes should just be that, dark objects. Hijacking stuff will always have drawbacks. On macOS/iOS (where Apple did the dark mode right), if you have an old App that doesn’t support it , it will literaly appear as regular old macOS cocoa UI, so, while that specific App will look out of context, it will be usable and work fine, no funky stuff.

¹ Playing with the Palette is required because of the “high res” icons and tools in “Mode 22” which was 16 colours + Font blending over dark structures, so it’s almost an hack due to the weird way the WIMP handles these situations.

For the curious one, a quick sneak peek of where I am at with one of the dark themes (there are a few actually).

But you can quickly see some of the limitations mentioned above:

But you can quickly see some of the limitations mentioned above:

Apps that ignore the system themed colours exist on Windows too, so that’s not a “local” unique behaviour.

Apps that ignore the system themed colours exist on Windows too, so that’s not a “local” unique behaviour.

Sure, but it’s not as bad as on RISC OS believe me. Even RISC OS itself makes assumptions on the colour schemas! Try to focus a window in any dark theme…

Steve, in all honesty, and with all the love I have for RO, it’s really really really primitive, like it was primitive even in the mid 90s (Windows 98 had a ton of good themes, and Windows is notoriously a very ugly UI when it comes to themeing and customisation)

I mean, look, here I am fighting to allow the focus to be used, but even when using ditheirng it still messes up with a light font (that is RISC OS itself, not the App):

However, the biggest issue is the way people designing their icons. As usual the minimalistic effort is the root of evil, and IMHO, one way to solve (or reduce) this is maybe design a tool specifically made to design Application’s icons.

Let me explain, many icons are simply NOT designed to have a dark background (or any other background!), the assumption is just a greish one (full stop).

It’s worth noting that since 2013, RISC OS 5 supports loading sprites with alpha transparency from !SpritesA, !SpritesA2 and !SpritesA1. Admittedly, I’ve never seen any existing applications that use this feature, but the upside is that it should be possible to improve the existing situation with icons without having to change anything in RISC OS itself ( besides adding alpha icons to the relevant themes ).

Apps that ignore the system themed colours exist on Windows too, so that’s not a “local” unique behaviour.

Mac too. I’m aware of an open source app that sets the window background to white and the text to system default, giving black-on-white in light mode and a seemingly-blank white window in dark mode. The “owner” of the app apparently doesn’t like dark mode, to the point of rejecting code contributions that fix it! I don’t understand stubbornness sometimes…

Paolo, your second screenshot looks just what I’m after – good stuff!

Apps that ignore the system themed colours exist on Windows too, so that’s not a “local” unique behaviour.

Mac too

I’ve seen that, but I was just referencing the most commonly used, and I have no doubt people can provide examples on every GUI OS.

I don’t understand stubbornness sometimes…

But you use RISC OS :)

I don’t understand stubbornness sometimes…

The expression “my way or the highway”.

That being said, it is particularly obtuse to refuse code contributions to fix the issue.
I could sort of understand an unwillingness to want to fix an issue that the person never uses, but when others have done the work for them…

Admittedly, I’ve never seen any existing applications that use this feature

Exactly how much would an app icon itself change from one theme to the next? Yes, most people assume that the icon bar background will be textured light grey. For the past 30ish years this has been the case. Is there any actual method to specify that a theme is “dark”? Because it seems to me that themes just tweak the furniture and a few of the icons to differ depending on the machine. Not unlike, really, XP when it can run in Win98 style NT mode, or the colourful Fisher Price mode. Visually different, but the underlying behaviour is unchanged.

Dark mode turns all of that on its head.

it should be possible to improve the existing situation

You’ll have noticed that the window furniture icons use a crazy set of colours, which I guess get internally mapped to a greater selection of shades.
Well, where’s the editor to make these sorts of sprites? Surely it wasn’t done like that in Paint?

Admittedly, I’ve never seen any existing applications that use this feature

Likewise, does Paint even handle levels of transparency?
Maybe if the tools were available…..

By the way, the last time I used a font in an icon I mocked it up in Draw and grabbed part of the screen to create the sprite.
PhotoDesk isn’t suited to making sprites. Paint is kinda primitive. And…uh…

That being said, it is particularly obtuse to refuse code contributions to fix the issue.

Sometimes it depends on whether the author sees the differing element of behaviour as a fault that needs to be fixed.
Let’s see, two quick examples:
RPCEmu – use of keyboard menu with any modifier never does anything other than produce the mouse menu key behaviour. The “fix” is an easy modification.
RISC OS – the switcher icon behaviour when you right-click is no different to a left click. Various third party fixes utilities exist. Modification of the RO source has been offered and resoundingly rejected.

The “fix” is an easy modification.

That works on all targets?

has been offered and resoundingly rejected.

Which would certainly fit my definition of “particularly obtuse”.

Especially given recent changes that can allow !Boot to be hidden…making a not-terribly-obvious way to access the system configuration even more convoluted.

@ Druck

Paolo, your second screenshot looks just what I’m after – good stuff!

Thx, and perfect, first beta tester user ahah XD – I just need to finish my DME Theme Manager (aka make it alpha and add a !Configure front end plugin) and then I’ll make it available as another component of the DME suite on my !packman repos.

It’s taking time ’cause I want it to work from RISC OS 3.10 onwards. I know some people would disagree on here, but the reality is, for a person that work on a theme having a larger potential audience will give more motivations, so most of the DME suite is designed to work from RO 3.10 onwards (the end user can chose which components are loaded/executed, to save RAM and improve old system boots, while on RO 5 it works at the best of its possibilities and a user can use all the components at once)

Which would certainly fit my definition of “particularly obtuse”.

There are reasons why I started my own DME project. Mostly not to cause troubles to folks that want to keep the OS at stone age era and that refuses any changes.

That is in perfect alignment with ROOL BTW, which mentioned many times: Fork it if you want it to work in a different way than we do. So, what I am doing is what I want and in perfect alignment with ROOL’s logic. Made a lot of people happy (so far), and did not cause any problem to the “let’s keep it Acorn” folks.

I think this is the best way to move forward TBH. I am trying to avoid having to replace OS pieces, but in some area I have reached already some “roadblocks” which need things to be replaced even deeper (or maybe on a side way, using vectors). Given I have a ton of components to complete and release, for now it is ok as it is, but at some point I’ll start looking on how to modify the inner behaviour of some portions of the OS. At that point, if vector’s claiming is enough, great, otherwise a fork will unavoidably happen.

I personally like RISC OS as it is (aka I don’t want to make it another Linux), however there are things that are totally unacceptable IMHO, and those will need to be addressed in time.

Forking is a good thing in Open Source, helps to figure out new ways and experiment improving things, so it may be that it will also help ROOL to change strategy a bit. It’s no secret they started to work harder on a new theme for the OS after I started the DME project, so, although if in a small form, it is indeed helping things to change and that is a very good thing.

And, besides, probably the most contadistinctive “essence” of RISC OS, it’s literaly the modularity of the system, which allows anyone to replace or improve most of the OS features, so it’s probably one of the most open design there is.

It’s worth noting that since 2013, RISC OS 5 supports loading sprites with alpha transparency from !SpritesA, !SpritesA2 and !SpritesA1. Admittedly, I’ve never seen any existing applications that use this feature

NetSurf has had alpha application sprites since at least as far back as 2004. They’re called ASprites, ASprites11, and ASprites22 .

I mean, look, here I am fighting to allow the focus to be used, but even when using ditheirng it still messes up with a light font (that is RISC OS itself, not the App)

I thought you could provide title bar sprites with a special focus prefix/suffix to avoid that. I could be wrong, but maybe check the RO5 theme that’s used on the Raspberry Pi?

That works on all targets?

Alteration to the open source for the emulator.
When I said easy modification, I meant it was easy enough for me to see what needed alteration to allow the emulator to generate something different depending on the key modifiers applied to the main “menu” key.
Recompiling after that – took me longer to set up the compiler environment than do the source mods, and as say regularly “I Am Not A Programmer”

Which would certainly fit my definition of “particularly obtuse”.

I do recall that you have a bit of a thing about that lack in Switcher.

with ROOL BTW, which mentioned many times

[Citation needed]

Fork it if you want it to work in a different way than we do.

Because that worked so well the last time…

that want to keep the OS at stone age era and that refuses any changes.

I don’t think they want to keep RISC OS in the Mesolithic. I think they’re just extremely adverse to change due to not quite being ready to draw a line under quarter-century old hardware.

I guess it doesn’t help that our only emulation is of said long-obsolete hardware. :-/

I am trying to avoid having to replace OS pieces

Don’t think you’re going to get too far before you have a “for <beep>’s sake” moment and want to tear out something awful and make a better one.

I’ve long felt like that about the awful mess that is Territory, but quickly realised that replacing it with something functional would be a major project (that I really don’t have time and possibly skills for). For starters, it would need to handle country defaults, changing those, language defaults (that can be completely independent of the country) along with fallbacks to alternative languages (with English as the last resort, not “the other”), time zone defaults (that can be independent again), and so on and so forth.
Alas, the problems run deeper than just Territory. Two Welsh countries/keyboards (in addition to UK), one Switzerland, and “countries” being abused to provide Dvorak (UK/USA) and Colemak (UK) layouts. What’s “MiddleEast” supposed to be? The countries there use languages that we don’t even have sane rendering support for! And “LatinAm”? FFS, there’s 20 countries and 14 territories, multiple languages, and multiple timezones (that are weird!).

But since that’s a major thing that few people would actually notice… I’ll just grumble quietly about how half-arsed the current method is. ;)

I personally like RISC OS as it is […], however there are things that are totally unacceptable IMHO

My personal bugbears are ones unlikely to ever be fixed for technical reasons.

For instance, I’d love to demote most module code to SYS mode rather than SVC mode. There’s an awful lot of crap that does not need to be running with kernel privs.
Hell, most of my MIDI module does, as that’s the default for a SWI call. But it doesn’t need to, and it probably shouldn’t.

The only sensible way to do this is to introduce a flag where the OS will drop itself to SYS mode on entry. But would anybody make use of this?

I’d also like to introduce a shadow RMA, and all those billions of RMA claims would go there, rather than having code and data intermingled as it currently is.

I’d also like to section off the RMA so user apps can’t go messing with it. Unfortunately a fair number of things (including some of my own modules!) are predicated on the idea of simply handing over addresses to data held within the RMA.

Really, while the OS is ancient, so too are most of our coding practices, so it’s a bit chicken-and-egg.

Forking is a good thing in Open Source

Depends upon the user base. For something like Linux, there are millions upon millions of users, so forking can help those who want something like Windows, as well as those who firmly believe that “real programmers” are happy with nothing more than a VT220.

For RISC OS? Forking runs the risk of creating dead ends. For a great example, take a look at the functional working IPv6 stack that is… not being offered as a part of the OS because somebody else is doing something else.
If you are a somebody else doing something else, are you going to commit to continually syncing your fork with the main version (plus fixing whatever changes might be necessary along the way) for however long people are using it for? Because if the answer is no (or even “forever is a long time”), then you might want to look to see if there’s an alternative to forking that takes less effort.

it will also help ROOL to change strategy a bit.

I won’t hold my breath… I’m still waiting to see if Julie’s Obey-in-C ever turns up.

it’s literaly the modularity of the system, which allows anyone to replace or improve most of the OS features

Yes. R-Comp has a drop-in-and-run installer for their new network stack. Acorn made similar so everybody could have the nested Wimp. We all know CLib can be updated, and that updating it twice makes it blow up. ;-)
With the exception of the kernel, most modules (I think?) can be replaced as long as it is done before stuff starts using them.

By the way, what’s with “Module is currently active” if one tries to kill off UtilityModule? If the snowflakes got upset over the original “Deleting the utility module is foolish”, then good… because deleting the utility module is foolish.

with ROOL BTW, which mentioned many times

[Citation needed]

Re-watch one of the last discussion between ROD and ROOL recorded on a meeting (it’s on YouTube and, IIRC, should be a MUG meeting, but I could remember wrong). Steve Revill clearly mention this to Andrew R., in a phrase in relation to the new ROD Network Stack. If they want things on the ROOL gitlab they need to follow ROOL’s policies otherwise they are free to fork and create their own repo.

Rick, sorry you’re not going to win this, forking is ok. If you don’t like it, I respect your opinion, but it’s just your opinion.

Fork it if you want it to work in a different way than we do.

Because that worked so well the last time…

Please let’s NOT mix things up. The “last time” (as you call it) it wasn’t an Open Source fork, where both branch developments are in clear sight and ideas can be merged back. The “last time” was some sort of ridiculous “battle” between two companies that had not much of a clue of what they were doing. Thanks God ROOL managed to make one branch Open Source!

Depends upon the user base.

???? My work is for ME as user base, and then I am very happy to share it with whoever wants to use it.¹ I am not sure how many times I have to repeat this…¹ Yes, turns out there are a lot of people that like what I am doing, which is great, but not a must have and (again) I am totally happy to share my work with whoever likes it (that include ROOL, ROD etc.)¹

For RISC OS? Forking runs the risk of creating dead ends.

Isn’t this the benefit of forking? Explore ways and prove or disprove concepts? And sorry for the sarcasm, but you’re really tempting me lol: Do you mean there is a more dead end than RISC OS is in???? XD Which major project world wide has been developed on RISC OS lately that I am not aware of sorry? XD

I don’t think they want to keep RISC OS in the Mesolithic. I think they’re just extremely adverse to change due to not quite being ready to draw a line under quarter-century old hardware.

You do realise that my work works from RO 3.10 with ARM3 all the way up to the latest RO 5 on latest boards right? Are you also aware I test my work on most of the RO releases (I still own a rack, yes a full, very tall rack, full of Acorn systems used for testing. On top of that I also test on all available emulators too, included proprietary ones.

ROOL’s has policies about what work has to be done and how, then they have a misterious code acceptance criteria and process (misterious to me, of course). So, instead of wasting my time working on things that may endup like C-Obey, I just started my own thing and people are using the work so far. Yes, it’s “slower progresses” this way, but who cares, RO is not my daily driver, so my most valuable user base is ok with that :)

I won’t hold my breath… I’m still waiting to see if Julie’s Obey-in-C ever turns up.

+1

By the way, what’s with “Module is currently active” if one tries to kill off UtilityModule?

A good reason to add checking which modules are being RMkilled? Or maybe not, it’s open, it’s a user’s responsability not to do the wrong thing, right?

¹ The usual notes for the distracter forum user: read the sentence with a full stop at the end. that’s it and that’s all no extra “meanings” to what has been written! lol Aka don’t try to read between the lines. I don’t mean what I don’t say! :)

@ Michael Drake

I thought you could provide title bar sprites with a special focus prefix/suffix to avoid that. I could be wrong, but maybe check the RO5 theme that’s used on the Raspberry Pi?

Thanks, I have been checking for this one, but (clearly) I couldn’t find it. Maybe I need to have another look or have a look at the WIMP code that handles the focus colouring and figure out what is exactly doing there, oh well andother fun weekend it seems XD

Re-watch one of the last discussion between

Thanks for the pointer. I’ve not really been paying much attention to the videos, as I read a hell of a lot faster than people speak… Sorry, but I find most unscripted videos to be a bit boring (side effect of attention deficit, no doubt).

it wasn’t an Open Source fork

Whether or not it was open isn’t relevant. Users ended up with two versions that behaved in different ways.
That’s the nature of forking.

That the source is open, means that everybody who disagrees can fork. I could, you could, ROD could, and to a small degree R-Comp already do.
Oh joy.

two companies that had not much of a clue of what they were doing.

I think they both knew what they wanted to achieve, they just didn’t know how to interact with each other for the betterment of the system as a whole.
<glances aside at the two network stacks>

???? My work is for ME as user base

I meant, as I explained, that the more users there are, the more a specific fork will be used.

There is no problem whatsoever with you creating the software for yourself. None at all. That’s how most stuff gets done around here. ;)

The thing is, if you write it for yourself and there are only a few users, what impetus do others (who are not users) have to support anything that it does differently to the base OS?

Think of it as a numbers game. Users means strength, and strength means power.

Do you mean there is a more dead end than RISC OS is in????

Well, I could point you to various bare-metal operating systems in x86 that sort of started and then died out, but GIYF…

Oh, there’s a lot of dead ends and zombies; if you know where to find them
You know, there’s a lot of dead ends and zombies; if there aren’t, you can make them (make or break them)
bq. You do realise that my work works from

Well done for supporting all of those systems.

As you are no doubt aware, my “official” policy is: it is written for RISC OS 5, if it works on earlier systems then that’s good too but it’s not a supported configuration.

I don’t go out of my way to be incompatible, but if there’s an easier way of doing something on RISC OS 5 (case in point being stuff like TaskManager_StartTask), then I’ll use that and too bad for machines prior to when it was introduced in RISC OS 3.80.

One can’t exactly bemoan the fact that RISC OS is stuck in the Mesolithic whilst also actively supporting the ancient systems that are the noose around our necks…

Yes, it’s “slower progresses” this way

Oh, I dunno. Langishing in a lonely corner of GitLab seems like a much slower death, almost a silent torture.

You could, for instance, drop a work in progress archive on your site today, tomorrow, next week, as you please. No third party hoops to jump through, nobody else to satisfy or appease, you set the schedule.

A good reason to add checking

Uh, I was actually complaining that the message was sanitised to the point of being stupidly boring.

Try *RMKill UtilityModule on older machines. It won’t work on any of them (the module refuses to die), but the response it used to give was much better, in my opinion.
Now it’s a bland “won’t cause any offence” thing. Pffft.

I don’t mean what I don’t say! :)

Me neither. And some times I don’t mean what I do say. It all depends upon how much tea is in me. :)

Which reminds me. Time to go put the kettle on……

The thing is, if you write it for yourself and there are only a few users, what impetus do others (who are not users) have to support anything that it does differently to the base OS?

There aren’t enough users as a whole… That train has passed many, many, many years ago and then another opportunity arised with the early Raspberry Pi and RISC OS was not ready for it, so also that train has now passed.

I am sorry, I really don’t want to sound too cinical or anything, but honestly there is no point, it’s a waste of time even considering “numbers” of any sort and form and (even by absurdity, and wanting to consider those “numbers” after having been drinking quite a few beers) surelly those “numbers” won’t play nice with the side of the OS that is stagnating the most among multiple forks, so, IMHO, even the logic is a bit funny (if I can use these words).

Which reminds me. Time to go put the kettle on……

Enjoy your tea! I just had burgers and chips, I am a happy man :D