ROOL ROM branding

the Sprites’ edges for this theme aren’t quite black, so I’ve set the window outline to dark grey to match.

This is actually pretty useful as it makes it possible to see where the left edge of a black window is, when it’s over another black area. (Overlapping Zap windows, for example.)

A worthwhile distinction IMHO.

This is what I was thinking – it seems like an oversight/bug that this part of the scrollbar doesn’t squash as the other bits do.

Judging by the change notes (Wimp.s.Notes) this seems to be deliberate. Not sure if squashing is the right way to go though. Maybe the blips shouldn’t be plotted when the blob (slider) is too small.

I think it would be good to get Gavin’s !Theme manager as part of the improvements.

I guess you mean Chris (Wraight) unless Gavin (Wraith) has snuck out a Lua based one. ;-)

[…] getting the whole theme management stuff, including improving the existing !Configure plug-ins, integrated into the standard ROOL disc image.

The first thing we need to decide on, I think, is whether we want to move options to a more appropriate location within the existing Configure plug-ins (eg desktop font shouldn’t be in Fonts, IMO), or do we move all options related to visual appearance to a ‘theme’ plug-in (ala Richard Goodwin’s theme manager).

Maybe the blips shouldn’t be plotted when the blob (slider) is too small.

That might be better visually than squashing them.

whether we want to move options to a more appropriate location within the existing Configure plug-ins

A little birdie told me that this sort of thing was recently discussed in person between members of a RISC OS user group.

The first thing we need to decide on, I think, is whether we want to move options to a more appropriate location within the existing Configure plug-ins (eg desktop font shouldn’t be in Fonts, IMO), or do we move all options related to visual appearance to a ‘theme’ plug-in (ala Richard Goodwin’s theme manager).

Personally, I like the idea of having all theme-related things in one place, rather than having to go across many !Configure plug-ins messing about with check-boxes to get what you want. I don’t mind keeping that functionality, mind you, but having a plug-in that abstracts over it all to manage your theme in a much more streamlined way would be nice.

Trevor is right Configure has been discussed and, for certain things, needs work.

However discussing Configure probably needs a new thread.

When ready I will start one.

Fred Graute wrote:

Not sure if squashing is the right way to go though. Maybe the blips shouldn’t be plotted when the blob (slider) is too small.

Maybe. The other option is cropping the blip sprites when they don’t fit. I think any of these options would be better than the current behaviour though. :)

When we were talking about squashing the middle section, I was assuming we were talking about the Wimp actually cropping it – e.g. using a suitable graphics (clipping) window (as per VDU 24) before cropping off the bits of that sprite that aren’t needed – so that you only get closer and closer to a central sliver of that sprite. That’s computationally simpler than actually squashing it and won’t introduce artefacts such as blurring.

Having not used my Iyonix for a while I decided to wipe it and start again. I must say I do like Michael’s blue grey toolsprites just a nice blend of nostalgia and modernism. For my own tastes I would not have the blips neither would I have the line that runs up the middle of the scrollbar wells but would be quite happy with the way they are. Judging by the duration of this thread I’m surprised that these toolsprites aren’t in latest !Boot by now.

Steve Revill wrote:

When we were talking about squashing the middle section, I was assuming we were talking about the Wimp actually cropping it – e.g. using a suitable graphics (clipping) window (as per VDU 24) before cropping off the bits of that sprite that aren’t needed – so that you only get closer and closer to a central sliver of that sprite.

Yeah, I think that would look fine.

Colin wrote:

I must say I do like Michael’s blue grey toolsprites just a nice blend of nostalgia and modernism.

Good! But note that the ToolSprites were designed by Chris Wraight. I just tweaked them a bit. I’ve added a text file to the archive which says that.

Ronald May wrote:
bq. “I downloaded your sample and found the greys are purplish”

It sounds to me that you are in a 256 colour mode in which the theme does indeed look purplish.
The theme is designed for 16 M colour modes, which I suppose is an issue on a Risc PC without a viewfinder or Vpod.
Trouble is, RISC OS has to move on…

Chiming in late…

Thanks to Michael for distributing the Steel-derived theme. I’d be delighted if this, or a version of it, became the default set.

Looking ahead, the important thing is that users have a simple way of setting visual preferences, and possibly also installing new themes. Even with regard to what already exists, the current Configure plug-ins are both incomplete and strangely organised (the desktop font being set in Fonts, for instance).

I would welcome something like the following:

- Creating a single comprehensive ‘Desktop’ Configure plug-in to replace the current ‘Windows’ and ‘Pinboard’ ones (plus any bits and pieces that are scattered elsewhere, such as the Desktop Font selector). This Desktop plug-in would be tabbed, with categories such as Windows, Menus, Iconbar, Pinboard, etc., to control the whole range of visual settings.

- The final tab would be ‘Themes’, which would offer a way of selecting between replacement sprite sets. You could have an ‘Iyonix’ theme for example, that would restore the current RO5 graphics, for any who don’t wish to change the desktop look. Selecting ‘no theme’ would result in the ROM defaults being used.

My Theme Manager provides this functionality, though I really need to finish it off and iron out any bugs. It’s also written in BASIC, but it could easily be rewritten in C as part of a revamp of the relevant Configure plug-ins. If there’s enthusiasm, I’d be happy to look at this when time allows.

As a rough mock-up, the plug-in might look like this:

What do people think?

What do people think?

Sounds great to me. It seems to me that the theme includes more than the sprites though – I’d say the state of all of the tabs is your current “theme” and if you change some things, you can save the new state as a (possibly new) theme. For example, I’d want things like the backdrop image to be part of my theme. So maybe you’d have an “icons” tab which controls the icon sprites, the tool sprites would be selected from a menu in the “Windows” tab and the “Themes” tab simply wraps up whole piles of configuration into named themes.

Which leads to one last question: how would new themes be packaged up such that people could download and install them?

It’s a moot point how much of the desktop’s visual characteristics should be bundled up into a theme. One model is, as you’ve suggested, that themes encapsulate every setting, including pinboard backdrops, desktop font, iconbar settings, etc. Another, IMO simpler, approach is to restrict themes to the window graphics and the filer icons. This makes it very easy to switch themes while still retaining one’s preferences over, say, iconbar scrolling rates and backdrop images. (The screenshot above, which is only a mock-up, confuses things a bit.)

In terms of bundling themes, the system used by my app is to put the necessary sprite files, plus a short text file with other Choices data, into a folder with the name of the theme (‘Iyonix’, or ‘Steel’). These can be dragged to the plug-in to install, where they’re copied to a !Themes directory within !Boot.Resources. Two system variables, Wimp$IconTheme and Wimp$ToolTheme are used to determine whether to override the ROM graphics at start-up. Themes can be uninstalled from the plug-in, or simply deleted from the !Themes directory.

to restrict themes to the window graphics and the filer icons

I also think such things are visual “Themes”.

say, iconbar scrolling rates and backdrop images

These sound as if they could be classified as “Settings”.

It’s probably worth making a list somewhere (e.g. in a new Configure overhaul thread, as Keith suggested a few posts above) of all the options that the new theme manager/destkop settings plugin will take care of. Hopefully deciding which settings belong where will be easier than coming to a consensus about what the default theme should look like ;)

I would like to see Chris’ theme manager (or very similar) as part of the OS, but it should also be available for all versions of RISC OS. (Maybe not 2)

I think a theme should optionally contain:

Application Icons
Tools, etc.
Backdrop
Mouse (either colours or replacement pointer/hour glasses)
Fonts
System beep
Data for programs that support themes (e.g. Netsurf)
Settings for button shapes (for use with select)

These should all be individually selectable.
The current section should be saved in choices (in the same format as a theme is supplied in).

The default theme shouldn’t be designed to appeal to existing users (because they would know how to switch to whatever they want), but to potential new users.

The mock-up looks good. I certainly think all the options for setting the various visual characteristics of the desktop should all be gathered up in one neat place in Configure like that.

I think it’s quite important that things are grouped into sensible tabs in the new desktop configure plugin. For example, it makes sense for the window outline colour option to be next to the ToolSprites selection option. E.G. with blue ToolSprites, you’d probably want to set a blue window outline.

I don’t like the idea of monolithic themes that you download and they take control of everything. If I want a new system beep, I don’t want to download something that will change my mouse pointers, backdrop, and the rest of my carefully configured desktop or force me to unpick the component I actually want from the theme. I believe the idea that settings for desktop font, ToolSprites, and mouse pointers (for example), have any relationship at all is completely flawed. Distributing all that in preconfigured theme lumps is silly. Font size and pointer images depend on the monitor resolution and eye sight of the user in question, not the settings that suited some theme creator, on their setup.

I’d rather see new ToolSprites distributed as ToolSprites, and new IconSprites distributed as IconSprites, etc. That way users can pick up what they want, and have the most control over their desktop.

Jeffrey Lee wrote:

Hopefully deciding which settings belong where will be easier than coming to a consensus about what the default theme should look like ;)

Hopefully. :)

optionally contain […] Backdrop

Tiled backdrops could be part of themes, but should be overridden if a user has specified a fullscreen image (which they probably want to retain).

I don’t like the idea of monolithic themes that you download and they take control of everything.

I agree. The idea with Themes is to make it easier to switch between different icon sets for the filer, and different graphic sets for drawing windows, gadgets etc.

Of course, both views are correct – which makes things difficult for the implementation of the configuration front-end!

For example, yes it’d be a PITA if you wanted to download a theme but not have it (say) mess about with your carefully crafted set up or your favourite backdrop JPEG.

However, it’s equally valid to say if I, as a theme designer, want to have control over the font, backdrop image, mouse pointer, iconsprites and toolsprites – that’s also perfectly valid. Every one of those aspects will be critical to the overall look (and others to the feel) of the theme. A theme is not just a set of icons. That’s just a set of icons.

What I believe we’d need is a compromise between allowing users to take bits of themes that they want/like and leave others (thereby creating their own custom themes).

Equally we should be able to completely transform – just by selecting a named theme – the look of the entire desktop to some pre-defined theme that a graphic artist has (presumably) spent a lot of time and minute attention perfecting. That’s the whole point of a theme! I really don’t want to load some sprites and then have to find a JPEG with the right mix of colours, mess about with millions of WimpVisualFlags, change the pinboard background and icon text colour, etc, for every bleedin’ theme just to see what it might look like…

I don’t like the idea of monolithic themes that you download and they take control of everything.

I agree which is why I said:

These should all be individually selectable.

I meant on install. For example, I usually don’t want the theme’s choice of font.

I would like a test theme button, which loads it, but doesn’t save it.

I’m very much a proponent of never giving users less control than absolutely necessary, and personally I feel an instinctive revulsion at any theme which would go so far as to change one’s desktop font anyway.

Maybe a ‘selective installation’ dialogue would be best? When you double-click on a theme file/application/drag something into the manager (whatever it ends up being), pop up a dialogue box with a list of option buttons, all of which are ticked by default. You could then selectively untick them (don’t like those buttons, horrid font, want my own background image, I’ll keep my current IconSprites thanks) to automate the tedious process of carefully snipping out the bits of a theme you want to keep.

EDIT: Oops, Jess pipped me to the post. Definitely agree with the suggestion to try a theme for ten seconds or so, like with what the Display Manager does these days (only with less drastic consequences if you get it wrong!).

Definitely agree with the suggestion to try a theme for ten seconds or so, like with what the Display Manager does these days (only with less drastic consequences if you get it wrong!)

I was thinking of the try button being replaced by a revert button, which reloads the saved settings, (if you don’t press it, the tested theme stays until the next restart.)

Maybe a ‘selective installation’ dialogue would be best?

I would think there should be one tab with drop downs for each of the items with which theme (or system setting) it is using.

Then another tab where themes can be installed and applied there would be the try and selective install options.

one tab with drop downs for each of the items with which theme (or system setting) it is using

This sounds useful, if I’m understanding it correctly.

Now that we have more horsepower (with modern processors) would it be worth considering visualising/applying the themes/settings immediately, without having to go and adjust-click on ‘Set’ each time? (Even the IOMD based machines could be candidates for this too, being faster than the original Archimedes.)