ROOL ROM branding

I’m looking forward to the new manager.

Could the switcher icon be managed separately to the other icons?
Could the theme manager and themes be distibuted by riscpkg?
Could themes also (ultimately and optionally) contain fonts (or choice), backdrop and system beep?

A theme bundled with my Theme Manager is a directory containing various sprite files for system Icons, Tools, etc. Inside that is an ‘Apps’ subdirectory containing further directories with the names of applications[…]

I can see the attraction to a theme designer of keeping all the icons for a given theme in one place, especially since there’s no standard installation location for most applications, so it’s hard to distribute a set of icons in such a way that they get installed in all the various application directories.

However, realistically, no theme is ever going to be able to provide icons for all applications. Nearly 2000 application names have been registered, and there are no doubt countless more that haven’t been registered. Also, I’m a bit reluctant to lose one of the nice things about application directories, that everything you need for an application to run usually lives inside the directory – most RISC OS applications still don’t need an installer.

I think it makes some sense for the theme manager to control the contents of the high-priority Wimp sprite pool (i.e. Resources:$.Resources.Wimp.Sprites – the file which is currently overridden by !+Resource) leaving applications to install their own sprites using *IconSprites as usual.

This way, a theme designer can still provide icons for as many applications as they like until they get tired, and application authors can still provide icons to fit in with particular styles without having to coordinate with the theme designer and without having to write an installer. Themes can be changed at run time, and while some applications will retain the wrong theme of icon until the next reboot, they will at least have something, even if the new theme defines fewer icons than the previously selected one.

Could the switcher icon be managed separately to the other icons?

That might not be a bad idea – it’s one that lots of people like to personalise anyway, and we already have the situation where the “official” releases (for Iyonix and, I think, ARMini) set it differently from the generic ROOL cog. The official Raspberry Pi release will likely be customised differently again.

From a technical viewpoint, there’s no particular reason why the Switcher icon has to get its sprite from the Wimp sprite pool. Anyone fancy adding the code for it to maintain its own sprite pool, and probably a star command to load it?

no theme is ever going to be able to provide icons for all applications. Nearly 2000 application names have been registered, and there are no doubt countless more that haven’t been registered. Also, I’m a bit reluctant to lose one of the nice things about application directories, that everything you need for an application to run usually lives inside the directory.

Well, the idea was that apps would still have their default !Sprites and Sprites files in the application directory, just as normal; these would only be overridden if the relevant desktop theme came with suitable replacements. So, if the ‘Steel’ theme happened to have a replacement set of sprites for, say, EasiWriter, then EasiWriter would use them in preference to its own internal set, but if the ‘Smart’ theme had no such replacements, or no theme was set, then EasiWriter would load its own versions from the application directory in the usual way. In either case, the application would decide whether to load resources from the theme directory or its own directory; all the theme author would do is provide the resources.

But I’m not wedded to this idea, and can see the simplicity of the model you’ve created. The first step, as you say, should be to release a Theme Manager for the default Wimp icons. Perhaps, if that system works well, coming up with an extension for third-party apps should have a discussion of its own.

It seems to me that there should be 2 methods for theming apps.

One method for non aware apps. Iconsprites looking for suitable icons in the configured theme, before using the default ones would make sense.

For apps designed to be themed (Netsurf is the only one I can think of, though I think some apps have different themes for different versions of the OS), it makes sense to have an OS (or OS extension) based system to use.

I think themes ought to be stored in resources, I think they should probably have registered names, to avoid confusion. And I think they need to be able to be selected on a per app basis. (But using a config option in the app itself, to override the default app theme setting.)

When it comes to apps the biggest problem I always have is when they enforce their own filetype icons <— !intergif is a classic case of this – once seen by the filer you’re back to RISC OS 3 for gifs!

When it comes to apps the biggest problem I always have is when they enforce their own filetype icons <— !intergif is a classic case of this – once seen by the filer you’re back to RISC OS 3 for gifs!

Been there, done that, T shirt now worn out. Just like many others.

For my money this is a reason to put a protect option into the theming such that the theme manager gets first crack at determining the look and feel and thereafter the user options allow (or not) alteration of any aspect of that.

In terms of Keiths comment – over the years I have spent time ripping out the overly insistent naffness of some RO applications on my machines, just as I have “amended” the setup of the windross pcs that have been on my desk or my colleagues (plus, as much as officialdom allows, the other 4500 machines on the network)
I’m sure of one thing – we all want the OS to look decent. Our individual version of decent may vary, but we don’t want individual apps mucking around with our chosen “decent”

I’d also like to test the theme manager, Chris!

Another one over here please Chris!

I’d also like to test the theme manager, Chris!

Has it been written yet? Point me to it.

A 180dpi version was required, so here’s a new download for the ToolSprites.

Normal 90dpi ToolSprites:

Large 180dpi ToolSprites: