RISC OS Desktop Modernisation project

Not really a bug in the sense of broken

Template, 12. Program, 16. That’s a bug.

My guess is that the 12 is a FileCore filename plus terminator byte, rounded up to a multiple of words.

As for the 16? Maybe somebody realised that a DOSFS filename is 12 characters (8+slash+3), plus terminator, rounded up to word multiple…and the template never got fixed because either it worked (didn’t overwrite anything obviously important) or it didn’t get noticed?

There may be more to this, there could be a valid reason for setting 16. Or not.

Well, you have something to start with – ThemeNamLen. Search the search for where that occurs, and see what variables it applies to. Then check those to ensure they’re all large enough for the desired size (they ought to be defined relating to ThemeNameLen…).

If you add folders with longer names it simply refuse to work.

Given the “longer names” available in RISC OS these days, I’d suggest trying 256 bytes (FileCore can support much longer, but bits underlying the desktop environment cannot as a lot depends upon the Wimp message size, so maxes out at around 236 bytes for an entire path.

The name should be truncated for display and/or menus. Something like 24 characters (long enough to be useful, short enough not to completely mess up display). And that it gives up upon seeing something too big is a bug – such a thing should simply be skipped over (with other smaller entries working).

bug report moved

Found a reminder that Theme names are allocated, so there might be rules.

Having allocated names is useful to avoid clashes between a good-looking theme and a truly awful one of the same name.

Having allocated names that can only be 12 characters is somewhat limiting, especially if you want to be descriptive. Not that (m)any of the current names are particularly so.

Guys,
I know this discussion about the limitations in !ThemeDef has been started by Stefan and on this thread, but if it has to become a !ThemeDef debug session and how to solve limitations of !ThemeDef (and ThemeDef only), isn’t it probably better to move it in bugs?

Again, the DME engine (which is the topic) has not such limitations.

On a side note: the pre-allocated names for a theme is a bad design idea, every decent OS does not need pre-allocated theme names. So, this probably sounds more like another reason to move away from !ThemeDef?

!ThemeDef presents a “protocol” that is very prone to misunderstanding, together with fragmented configuration aspects that are hard to control and to integrate in a Theme Editor, here is an example (from the original documentation):

!WindSetup
-———-
This is the most confused of the plugins. Its new role might be described as “behavioural aspects of the desktop” whereas the theme setup might be described as “visual aspects of the desktop”.

First of “Behavioural aspects of the [Desktop]” vs “Behavioural aspects of [the Windows]”: Modern Desktops present more complex patterns than just which window flags should be enabled or disabled. The name is confusing at least call it !DesktoSetup if it’s for the desktop or explain it as “Behavioural aspects of the Windows”. But if it’s for the “desktop” then where are the “Task Switching behavioural configuration actions?”, where are the “configure the switch between multiple desktop actions?” and there is more.

In general the Theme concept in !ThemeDef sounds very old, where basically a Theme express only some of the aesthetic aspects of a Desktop and that is not very much suitable for a “modernised” use of Themes.

I could go on, but honestly I do not want to sound like criticising the work that has been done there. (And I apologies for the previous statements if they sound too harsh).

So, given that (if you start digging like I did on !ThemeDef) there may be many aspects that you may want to discuss/debug, probably worth starting a conversation in General or in Bugs? The project that I am building is not related to !ThemeDef (except for the parts that needs to be integrated to ensure RISC OS 5 is happy with the DME).

A Theme, in the DME, is expressed via a Manifest file that is Theme Editors friendly and that can be extended over time. It’s path and name agnostic and is in “INI format” (that has already been used somewhat in multiple old theme managers).

The Theme Engine in DME does follows the ThemeDef requirements for RISC OS 5 (and thankfully only for RO 5) and other requirements on different releases of RO, so that it can work on multiple releases of RO (not just RO 5). So it can be seen as a standardisation on Theming across all RISC OS releases (down to RISC OS 3). In DME, Theme “features” and “aesthetics” are controlled by the DME Theme Engine and so will be automatically restricted on the specific RISC OS release, however the Theme shall never get broken (aka cause problems to a user using RISC OS or his Apps). So it kinda acts like a contract between a Theme Editor and the specific OS release.

Themes are structured in such a way that the DME Theme Engine can control them and ensure the “fulfilment of the contract above”.

The reasons to create a Theme Manager that is Theme Editors friendly, is so that people can create Theming software (or extending existing ones), so that non-tech people can just design new Themes. And, as the WindowManager graphic capabilities increase (hopefully via plugins and not by constantly modifying the WindowManager itself), themes can be improved.

I have recently been using Manjaro Linux with the KDE Plasma desktop (on an Rpi4). Its facilities for personalizing the desktop I find quite impressive. In (Settings)→(System Settings)→(Appearance)→(Window Decorations)→(Titlebar Buttons) you can set the window furniture positions by drag and drop. I find it convenient, for example, to have two copies of the window-close icon, one at either end of the titlebar. It lets you do that. For sheer comprehensiveness I recommend a look.

Yup,
it is and KDE in particular has become an IMPRESSIVE Desktop, I personally think is way better than anything else I have ever used as well as being extremely fast and responsive.

For the DME configuration tool, right now I am experimenting with !XConfig which some how resemble a somewhat similar UI to how KDE allows custom settings. To allow the DME Core engine to process the configuration created via XConfig I have already ported a C library to RISC OS that allows me to read and process complex INI files which are very similar to what XConfig is generating .

So, I am not too far away from that level of integration, but the time I have to work on RISC OS stuff is so little that it really is unsettling some times. There is so much that can be done (and will also look good and easy to use) and yet so little time to make it happen :(

@Paolo if you want to use any of my apps you have my permisson.

http://kevsoft.co.uk/

On a side note: the pre-allocated names for a theme is a bad design idea, every decent OS does not need pre-allocated theme names. So, this probably sounds more like another reason to move away from !ThemeDef?

I’d agree with that. The bug discussion, that slightly derailed things, highlights that a somewhat limited theme management system also has bugs.
Fixing the bugs on a setup with limitations seems like a waste of effort that would be better put into implementing a more flexible system and learning from past mistakes.

@ Kevin

thank you so much Kev! You totally rock! :)

@ Steve

Fixing the bugs on a setup with limitations seems like a waste of effort that would be better put into implementing a more flexible system and learning from past mistakes.

Yes this is the conclusion I came to when I started to look into the !ThemeDef together with looking at works that have been done previously !ThemeDef. Plus the lack of communication from ROOL may cause that (just as an example) someone push a fix for !ThemeDef while you’re changing it on your fork, so very time consuming and very unpleasant when you have little time to work on RISC OS. So, for me it’s all about external tools, non controlled by the ROD/ROOL process (nothing personally wrong with them, just do not have all that time to run after their change of directions etc.). If in the end they want to use my work instead they are more than welcome and licenses are already very clear, if not then not an issue I get the Theming software I want, so I am happy using RISC OS the way I like.

But with that said, I always advocate for Open Source and allow people to follow the path they prefer, so if people wants to put effort in fixing and/or re-designing !ThemeDef that’s totally cool for me, can’t wait to see the results :)