ROOL ROM branding

Hang on a minute, if you’re worried that trying out a theme will lose your desktop font, what I was suggesting wouldn’t do this: everything you’ve chosen for how you have your desktop looking can be saved as a named theme and bang, you’ve created your own theme (which ideally you could upload somewhere for everyone else to try). Switching to some other theme – to try it out for as long as you want – is simply a matter of selecting that theme from a menu. When you’ve had enough, you switch back to your old, named theme. Or perhaps you select a “merge theme” option which (as Martin was saying) allows you to pick and choose which aspects of one theme you move into another theme.

So every time you change a setting, you’re asked to save the new setup as a named theme, or overwrite some pre-existing named theme. It’s not that hard is it? :)

I’m not worried about trying a theme changing my desktop font for the duration of the trial, (either to a revert, or a restart.)

The test should be just that, see what the designer wanted.

However it is the actual applying of the theme, where I wish to only chose the parts I want. (i.e what I wish to avoid is applying the theme, then having to change the font because I can’t read it, the beep because it’s horrid and the background, because it’s not as nice as my current one.)

Sounds like we’re in agreement then. :) The two main features are 1. switch theme, 2. merge theme – where a theme is the complete package for the desktop look and feel.

I think we may need to have some of the theme manager/themeing code built into the ROM image. At the moment the default theme of the ROM is dictated purely by whatever icon and tool sprites were put into ResourceFS. There’s no way of easily controlling the default font type/size, window border colour, etc. There’s also no way for a running program to know what ROM theme is in use (which is important, since the boot sequence will typically load some high-res sprites).

If we modify the relevant ROM modules (mainly the Wimp, I guess) to directly support themeing, using the same theme package format as which will be used to distribute the themes on disc, then that would allow us to just create a “Theme” folder somewhere in ResourceFS and use that for storing everything related to the default ROM theme. Anything which needs to know the default theme can examine the config file in that folder (or ask the Wimp for the current theme?)

I’m tempted to say this could also be used as a way of supporting different themes at runtime (i.e. by registering new resource files ontop of the existing ones in the Theme folder), but that system wouldn’t work too well when the theme manager wants to work out what the default ROM theme was. So maybe we’d need multiple folders, and a path variable to indicate which folder(s) should be used for the current theme? (Using a path variable would make it easy to override/update files without having to directly replace the originals). Or maybe it would be better if the theme config file specifies the paths for all the files which make up the theme, so that more flexible arrangements are possible (e.g. when the user wants to create a custom theme that uses files from several different themes)

Any thoughts on this? I’ll admit I’ve never tried Chris’s theme manager, so it’s possible that he’s already thought of solutions to some of these problems.

The two main features are 1. switch theme, 2. merge theme

1. Both with and without saving.

Also, it would be nice to be at least compatible with Chris’ theme manager.

So that at the very least the same themes could be used on non RO 5 with it.

Ideally it would be a development of it.

1. Both with and without saving.

It doesn’t sound like you’re understanding my proposition. You don’t have a “Save” option, other than “Save my setup as a named theme”.

Trying out another theme is simply a case of selecting it. If you don’t like it – be that after five seconds or five weeks – you go back into the theme manager and reselect your original theme, using the name you saved it as.

There’s no reason to complicate this even more with some “Test this theme and revert after n seconds” type of stuff – that’s not going to suit most people who want to see how various of their favourite apps look/behave with a theme that’s being tried out.

I have just caught up with this thread and haven’t the time to read all the posts, but want to make a few comments about branding (not the desktop furniture).

Somebody suggested a cartoon character, I hope I have got that wrong. Don’t do it! People will think RISC OS is a joke, not a serious OS.

I like Michael Drake’s work. I like his initial efforts combining the ROOL brand and the cog; but, thinking about folk who will be coming to RISC OS for the first time or revisiting RISC OS from their distant past experience, the cog fails as it means little to either. An oak leaf or tree as a logo or switcher would show a link with the past, for those who remember, and ties in with plant symbols used by other platforms like the Raspberry Pi and Apple for everyone. Being green in colour suggests the link with environmental considerations (low energy consumption of RISC OS on ARM).
I would like to see Michael Drake do a mock up similar to those he has done, but replacing the cog with a green oak leaf or an oak tree (or both). This indicates that what started life as an acorn has grown into a tree.
The Raspberry Pi splash screen should show both the Raspberry pi logo and the RISC OS logo (leaf or tree).

There’s no reason to complicate this even more with some “Test this theme and revert after n seconds” type of stuff – that’s not going to suit most people who want to see how various of their favourite apps look/behave with a theme that’s being tried out.

(Auto revert is only needed for changes that could prevent you operating the machine.)

I had imagined what loads at system start would stored in choices in the standard theme format. (Which could be fished out and passed on or backed up.)

The test theme button would not touch this file, but would load the theme. The revert button would reload the configured theme.

On the theme management tab there would be options to test themes, apply, load and delete themes. The apply button would bring up a set of tick boxes to confirm which parts are to be applied.

On the appearance tab, there would be drop downs for all the theme parts, with choices of all the installed themes, plus system supplied options.

There would also be the option to save the current settings as a theme (i.e. added to the resources theme store, unless dragged out)

Jeffrey Lee wrote:

I think we may need to have some of the theme manager/themeing code built into the ROM image.

[snip]

Any thoughts on this?

I think that would be worthwhile, and and both the ideas you had sound good to me.

On the other hand, I think there are two separate tasks:

1. Changing the default ToolSprites that come with RISC OS
2. Making RISC OS more easily “themeable”

At the moment it’s pretty trivial for anyone who is familiar with the OS to change ToolSprites with an Obey file and a set of sprites in their Boot sequence, but it’s not at all clear or obvious for someone who’s new to the platform.

So in the short term I think it would be good to update the ToolSprites that are shipped with RISC OS, to make it look a bit more modern for new users. Especially since the new Raspberry Pi port and the buzz around the platform might actually get new users trying RISC OS.

The ToolSprites proposed earlier in the thread are cleaner and lack the dated look of the current defaults without being a massive change in desktop design.

I think it would be easy for ROOL to provide downloads of the current desktop ToolSprites wrapped up in a !Boot directory to be merged if existing users want to revert.

In the longer term support for themeing could be improved, so that people can fiddle about with look and feel more easily.

Did anything come of this ? We’d love to have some new themes and a theme management !Configure plug-in in the RISC OS 5 disc image but the first steps would be collecting all of this stuff together and ideally getting it into the ROOL CVS repository somewhere.

Did anything come of this ?

I don’t think so.

Did anything come of this?

It seems there are two quite distinct tasks:

1. Make Michael Drake’s new blue-grey toolsprites and switcher the default:
   • Put into CVS as target for Wimp’s ResourceFS
   • Remove +Resource
   • Remove the blue jelly bean switcher/taskmanager from !Boot.Resources.Configure.Sprites²²
2. Produce a theming plugin for !Configure

The former seems trivial, and makes the desktop look far more modern (losing the annoying/depressing titlebar in the process). The latter… harder.

Sorry, this is my fault. I have an almost complete theme manager plug-in that I’ve been meaning to finish off forever. I’ll try to get it done this week. Once that’s done I’ll send around for testing, together with some suggestions for how a theme manager system might work. If people like those, I’m very happy to make it available to ROOL for distribution with the disk image.

“I have an almost complete theme manager plug-in that I’ve been meaning to finish off forever. I’ll try to get it done this week. Once that’s done I’ll send around for testing”

Very happy to help test this as I think it’s vital RISC OS go out to Pi users with a modern look.

Sorry, this is my fault. I have an almost complete theme manager plug-in that I’ve been meaning to finish off forever. I’ll try to get it done this week.

There is always a shortage of round tuits

Once that’s done I’ll send around for testing, together with some suggestions for how a theme manager system might work. If people like those, I’m very happy to make it available to ROOL for distribution with the disk image.

To date I have only tried the themes you have published on RPCEmu (I keep testing other items on the Beagle)
Like a number of others round here I’m more than happy to test the new version. Does the plugin version remove the double GUI load aspect? (i.e. existing version briefly shows the non-themed desktop before running the themed version)

Steve:

Have a look inside your predesk folder – if there’s an obey file called newlook you can safely delete it.

Speeds things up a bit (although of course you might still see the non-themed version of the desktop for a bit <— as it is in the ROM!).

Keith,

Thanks, just need to finish work to do that bit.

Maybe I should bring my pet Beagle to work.After all I work in IT, so it must be legit :-)
I wonder if I can get a RADIUS server working on a beagle…

OK, I’ve made some progress on finishing off a test Theme Manager. However, before going any further, I’d appreciate some advice on a couple of points.

1. I’d assumed, I now think wrongly, that Wimp$IconTheme was unset by default unless a third-party app decided to do something with it. As it’s currently written, my theme manager changes Wimp$IconTheme to the name of the theme selected from the Configure plug-in, or ‘[No Theme]’ if the user explicitly selects that option. At start-up, if Wimp$IconTheme is set to anything other than ‘[No theme]’ or nothing, then the Manager will try to load a theme of that name from a repository it keeps in Boot.Resources. Nothing breaks if it can’t find what it’s after, but it would be good to get some clarity on what, exactly, Wimp$IconTheme is meant to control, since I imagine it would be confusing if my Theme Manager were using it to track the name of specific theme files (stored in Boot.Resources.!Themes.Themes) and other things were using it for something else or in a different way. Has the exact function of Wimp$IconTheme ever been explicitly defined? Should I avoid using it for this purpose?

2. By far the most requested feature, when I originally released a Theme Manager a while back, was for a separation between the graphic sets controlling the appearance of windows and menus (toolsprites, textures, gadgets such as option-buttons, etc.) and those controlling the file icons used by the Filer and the icon bar. The reasoning for this is sound: it’s a huge job to redesign all the filetype icons, and a much easier one just to redesign the toolsprites, etc. Also, someone might well prefer (say) the RISC OS 4-style window tools, but prefer the the RISC OS 5-style file icons. So, as currently written, the Theme Manager allows the user to choose between ‘Icon’ themes (complete sets of filetype icons, drive icons and other things used by the Filer and icon bar) and smaller ‘Tool’ themes (window furniture, gadgets such as option and radio buttons, plus a selection of visual flag settings). The Manager sets Wimp$IconTheme to the name of the current Icon theme, and a new system variable, Wimp$ToolTheme, to the name of the current Tool theme. I think this works very well – it’s a simple distinction, and one that (from a user’s point of view) makes perfect sense. However, I’d welcome comments on this too, particularly from the ROOL guys, in case it breaks something or goes against some important principle.

Any thoughts very welcome.

After having a quick search through the sources, it looks like Wimp$IconTheme is used as follows:

• When the window manager initialises, if Wimp$IconTheme is unset it will set it to the user interface type that was set at compile time (Iyonix, Sovereign, etc.)
• *IconSprites will try prepending the sprite file leafname with <Wimp$IconTheme>. So <foo$dir>.!Sprites becomes <foo$dir>.<Wimp$IconTheme>!Sprites. It’ll look for the usual Sprites11, Sprites22, etc. files with the theme variable present before falling back to doing a search with the variable absent.
• resspr_init() in the C library, and task_initialise() in the toolbox, also make use of <Wimp$IconTheme>, again via prepending it to the sprite file leafname, and falling back to non-themed sprites if the themed ones aren’t available.

This has set me thinking. I’m not really graphical artist but some things in the existing sets seem to clash.
Anyone else think that the display mode iconbar icon is slightly off from an intuitive version?
If you extract the co_display icon from the RO5 set and then add it to the icons file in the RO5 theme as “display” then the display change has the vertical and horizontal arrows indicating its purpose.

I have the green cogswitcher icon in place as the taskmanager icon but I somehow feel that should be modified to an angled 3-D version of the ROOL multicolour icon.

The actual icon for the Theme plugin fits with a RO4 set but looks out of place in a RO5 build, however the ThemeMan icon is slightly too short and appears to float a distance above the ThemeMan text (or as a re-use floats above the Themes text.

It was me that added Wimp$IconTheme in the first place:

http://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/VersionNum?rev=4.97

It came about because of varying preferences amongst the Iyonix developers for the Iyonix sprites, the Ursula sprites and the traditional RISC OS 3 sprites. I planned to eventually write a theme manager, but that got shelved, so we never established when Wimp$IconTheme would actually get set.

One of the aims for it was to enable end users to add themes to third-party applications without requiring any code changes (so simply by adding additional files into an application directory).

One possibility which was deliberately left open was to have a ‘.’ character in Wimp$Theme. So for example, if it was set to “Ursula.” then all the Ursula-themed sprites would live in a subdirectory of the application directory with that name, thereby avoiding long filenames which might cause problems for those who might want to distribute an application which also works on RISC OS 3.

A more recent change was this, by Sprow:

http://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/VersionNum?rev=4.131

This makes some sense – it permits a different theme for Iyonix or Raspberry Pi builds (even if only a different splash screen and switcher icon) without needing any additional code in the boot sequence. I haven’t checked if it uses the ‘.’ trick I mentioned above, though.

After having a quick search through the sources, it looks like Wimp$IconTheme is used as follows:

Thanks. That’s helpful. If I understand all that correctly, there’s no reason why a Theme Manager shouldn’t set the Wimp$IconTheme variable to indicate that a different theme has been adopted. However, I’d be interested to get views on whether using Wimp$ToolTheme too is a good idea, or just muddying the water.

One of the aims for it was to enable end users to add themes to third-party applications without requiring any code changes (so simply by adding additional files into an application directory).

Indeed. I’m interested in the method you adopted of prefixing the sprite name with the theme name (with or without the ‘.’). I’d been toying with a different approach. 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 (Edit, Chars, etc.). I’d imagined these being populated with replacement !Sprites/Sprites files for the apps in question to allow the third-party app to blend in with the current theme. The app’s resource loading functions would need to be adjusted to check whether suitable files existed in the current theme, and if so load them in preference to the ones in its own application directory. The advantage of this approach is that once the app was ‘theme-aware’, no further changes would need to be made to it in order to extend its theme coverage – it would be up to the distributor of the theme directory to provide the replacement sprites.

However, this system would be incompatible with the one existing for *Iconsprites, etc., so perhaps it’s best not to pursue this?

However, this system would be incompatible with the one existing for *Iconsprites, etc., so perhaps it’s best not to pursue this?

Which reminds me – there was a thread in bugs relating to the previously missing error message regarding IconSprites and co_sprites.
When the long standing bug was removed a number of programs suddenly started throwing errors because of missing sprite files. Theme manager was one of them IIRC.

Whatever happens with themes and the like, please can there be an option to stick with the “traditional” (antique?) RISC OS look? I rather like the original RISC OS 3/4-style tool and iconsprites – it reminds me of the good old days back when I enjoyed computing.

Whatever happens with themes and the like, please can there be an option to stick with the “traditional” (antique?) RISC OS look? I rather like the original RISC OS 3/4-style tool and iconsprites – it reminds me of the good old days back when I enjoyed computing.

Chris’s theme manager includes a “no theme” option which will take the system build default, it also has older (RO 3/4) themes for the nostalgic users. If that is what ends up as the built in theme manager then I think you will be happy.