What is Wimp$IconTheme etc?

Sorry for disappearing for a year and then poking at things, but an agreed Theme system has existed for well over a decade, why is a new one being invented?

It isn’t a new invention; it’s been around for almost 10 years. It’s just that it’s only now that we’re starting to use it for something.

See here for some of the history behind it.

That’s disappointing.

Many applications shipped well before the Iyonix existed that were compatible with Rich Goodwin’s Theme Manager using the Theme protocol. That had the advantage of:

1. Already existing
2. Allowing unchanged sprites to be shared instead of repeated
3. Allowing installed Themes to override Applications
4. Not requiring an updated Wimp or Toolbox
5. Allowing Applications to be updated without breaking user themes
6. Already being used by a number of authors

Sigh. Wimp$IconTheme is far less sophisticated and is also rather dangerous – what if you set it to “Resources”? (Or more specifically it imposes the ‘theme’ namespace onto the contents of every application directory, which is madness).

Its use isn’t being encouraged is it?
It is being phased out isn’t it?
We do all fully understand the faults with it don’t we?
:-)

I don’t pretend to understand anything about either approach (if anyone has the time to enlighten me, that would be most welcome), but for reference here is a link to the aforementioned Theme Manager by Rich Goodwin. Couldn’t immediately find a reference for the “Theme protocol”.

From what I can see from a quick web search, the two schemes are almost exactly contemporary – 2002. It looks like Rich’s scheme hasn’t gained a lot of awareness to me, and it also looks like it stalled before it was completed. The closest I can see to a “protocol” is here (and I wouldn’t really consider that a protocol, there’s no messaging involved that I can see)

Some counter-arguments in favour of the new theme manager, as far as I can see:

• it allows themes to be changed at runtime (useful so you can try out alternate themes without needing to reboot)
• it doesn’t require code changes in any applications – an important consideration, given the trouble that we have in getting people to update their apps even when unavoidable hardware incompatibilities arise!
• it doesn’t break the “everything an application needs can be contained in its directory” model any more than it already is

From what I can see from a quick web search, the two schemes are almost exactly contemporary – 2002.

Nope. The Theme Protocol was defined around 2000 or early 2001. eg: https://groups.google.com/d/msg/comp.sys.acorn.programmer/oT_alpBTbow/NWf1BEbTB7cJ from July 2001

It looks like Rich’s scheme hasn’t gained a lot of awareness to me, and it also looks like it stalled before it was completed.

It was not “Rich’s” scheme. Rich Goodwin’s Theme Manager is just an example of a Theme Protocol compatible program. He had stand-alone themes much earlier than that, and the Theme Protocol was designed to work independently of any Theme Manager – I’ve never used one for example.

Apps using the Theme Protocol have been published by a number of independent authors since 2000. Have any apps published by independent authors used Wimp$IconTheme?

As for your bullet points, 1 and 2 are contradictory (in general, unless a number of additional rules are mandated – icon sizes, translation tables, scaling and palette modifications are just some of the potential problems that do require application co-operation). Regardless:

1. The Theme Protocol also allows the theme to be changed at runtime.
2. The Theme Protocol only requires “*IconTheme appname !Sprites” instead of WimpSprites in its obey file. However, if it loads its own sprites it must (potentially) merge two additional sprite files. The benefits are well documented.
3. Appears to be a misunderstanding:

Under the Theme Protocol an application MUST include its default sprites (in <!app>.Theme.Default), it MAY include themed sprites (in <!app>.Theme.< ThemeName>), and in addition a theme directory MAY include sprites for applications (in Theme:Apps.appname ).

A usage example may be useful: I prefer RO3 style icons on this RO4 installation for a number of reasons (leaving the semantic and design discussions aside, I don’t like green directories!). I recently downloaded !DirSync by Jan-Jaap van der Geer. It auto-selected RO4 style icons and therefore green directories in its icons.

As DirSync uses the Theme Protocol I had a couple of choices as to how to solve this problem. I could add my preferred icon designs (and only those icons I needed to change) to a RO3_Linear directory inside !DirSync.Theme. However, I have a !RO3Icons theme directory in my boot sequence, so I saved my altered sprites to !RO3Icons.Apps.jjvdgeer.DirSync.RO3_Linear and hence customised its sprites without altering it at all.

If Jan-Jaap updates his app with additional icons, I’ll still get my customised icons but also still get his new icons (which Wimp$IconTheme cannot do). The same method also allows one to theme applications in ROM or in shared locations.

In fact, the only reason I came across Wimp$IconTheme was due to a search here before asking a question about the Theme Protocol prompted by using DirSync, but I’ll put that in a separate post for clarity.

Meanwhile the flaws with Wimp$IconTheme remain unanswered – most seriously of which is the conflation of the theme namespace with the contents of every application ever written. That alone ought to be a stop-ship.

The question I was going to ask about the Theme Protocol relates to calibrated monitors.

The Theme Protocol was developed partly in respect of the requirements and repercussions of calibrated displays, in addition to that of themes. My Theme$Current is “RO3_Linear” – RO3 style icons designed for a calibrated monitor.

Now RO3_Linear is not really a standard theme name, unlike “RO3”, so I don’t expect Theme Protocol compliant programs to (necessarily) supply suitable icons out of the box, but in the absence of RO3_Linear I’d still prefer RO3 over the RO4 icons that get substituted (due to the OS version).

It occurs that if my theme were called “RO3.Linear” then the Theme Protocol could be modified to fall back to “RO3” in the absence of my more-specific requirement.

So someone who likes RO4 style icons (why, for the love of all that is holy?!) but wanted yellow directories (gak!) could create an RO4.yellow theme and at least get the right shape icons in the absence of the desired colour.

Any thoughts?

The other question relates to RISC OS version sensing. This had always been done using OS_Byte,0 and a lookup table (which included such milestones as “RO420”), but only foresaw “RO5” and not beyond. I wonder whether this hierarchical fallback could be applied to version number too (in absence of the user’s theme of course). ie try “RO5.67” first then fall back to “RO5”.

It is unlikely that minor version numbers will signify a major change of design element, but it is not impossible.

most seriously of which is the conflation of the theme namespace with the contents of every application ever written.

Aaaaaaaargh!!!

The other question relates to RISC OS version sensing.

I wonder if this didn’t get a bit messy when ROLtd released RISC OS 6? Not to mention, there can be issues of what hardware said version is running on (though, granted, less so for userland apps).
The method I’ve been using is OS_Module to return the BCD version of module zero (always UtilityModule) and parse as much of that as necessary (i.e. &0005xxxx for RO5). When I know we’re on RO5, check for HAL (OS_Hardware, IIRC), and then call the HAL to retrieve the hardware ID/version.
This may fall apart with ROLtd as I check version 5 as “>4”; however given one branch is being actively developed, that’s the one I’m considering “has vitality”.

To be honest, I think the “magic numbers” OS_Byte made sense on the Beeb. It’s a bit of an anachronism these days, and really OS_PlatformFeatures or the ReadSysInfo should be modified to be capable of telling you:

• The exact version of RISC OS in use (look at all the versions of 5.19 for example). Probably best to return a string in a known format, like “5.19x dd-mmm-yyyy” (where ‘x’ can be a space if no subversion to note).
• The hardware in use (Beagle xM, RPi B, Panda, etc), can return the same values as the HAL.
• Whether or not the CPU supports alignment exceptions and fudging, and whether or not said behaviour is on or off.

I believe this would be a more useful future-going way to ID the device in use.

Aaaaaaaargh!!!

I may have misunderstood this post from Jeffrey: https://www.riscosopen.org/forum/forums/2/topics/209?page=8#posts-13459

But it suggests to me that if an app happens to have a spritefile called Foo!Sprites that ‘Foo’ is now part of the Theme namespace. I don’t know whether that is actually ‘Foo’ or ‘Foo.’ but either way it’s a bold claim that this cannot ever clash with any existing application.

To be honest, I think the “magic numbers” OS_Byte made sense on the Beeb. It’s a bit of an anachronism these days

I fully agree. From a theme point of view minor version numbers are probably irrelevant now (certainly post RO3 – 3.80 was different to 3.50 which was different to 3.10 of course) but your other points certainly do apply to ReadSysInfo.

Version number of Utility Module is a good call, and hopefully similar to the output of fx0.

As for ROLtd, I’ve been pretending they don’t exist since 1999 and I’m not going to change now. ;-)

the conflation of the theme namespace with the contents of every application ever written

I’d argue that given the design goals of the scheme (to keep application-related resources inside the application directory, and not to require any code changes) then some namespace assunptions are unavoidable. Also note that no application is mandated to use that scheme.

Have any apps published by independent authors used Wimp$IconTheme?

The whole point of it was that no application authors need become involved. Remember it was designed against a backdrop where the number of people involved in RISC OS development was in seemingly terminal decline, unlike today!

icon sizes, translation tables, scaling and palette modifications are just some of the potential problems that do require application co-operation

Which is why it doesn’t attempt to address those – again, the aim was to avoid application changes. The RISC_OSLib and Toolbox changes were to enable matching theming of the application’s own sprite pool (conventionally in the file !MyApp.Sprites). I suppose it could be extended to intercept Template and Res files to enable more of that sort of theming, but any theme that requires that sort of change it likely to end up with a lot of non-matching applications.

I don’t think the two schemes are necessarily mutually exclusive. Feel free to contribute to the theme manager in CVS to make it integrate with the other scheme – but there’s a big Raspberry Pi release imminent, so you’ll need to be very quick about it…

Also note that no application is mandated to use that scheme.

I thought this was automatic behaviour by *IconSprites and hence inherited by all existing applications? Apologies if I have misunderstood.

I don’t think the two schemes are necessarily mutually exclusive.

The namespace issue is the problem. An application that uses the Theme Protocol will *IconSprites the following files:

• !ThisApp.Theme.Default.!Sprites
• !ThisApp.Theme.<Theme$Current>.!Sprites
• Theme:Apps.ThisApp.!Sprites

When it runs it may load its own sprites from the same locations:

• !ThisApp.Theme.Default.<anything>
• !ThisApp.Theme.<Theme$Current>.<anything>
• Theme:Apps.ThisApp.<anything>

Thanks to Wimp$IconTheme there is now a potential clash between the monkeying-about with the !Sprites leafname and the <anything>.

Consequently I’d have to conclude that the two are incompatible and advise that Wimp$IconTheme must be unset on any RISC OS where Theme Protocol compatible applications are used. In fact, the namespace problem affects all applications, not just Theme Protocol compatible ones.

Feel free to contribute to the theme manager in CVS to make it integrate with the other scheme – but there’s a big Raspberry Pi release imminent, so you’ll need to be very quick about it…

Oh hell, I didn’t know there was one. Where is it?

I thought this was automatic behaviour by *IconSprites and hence inherited by all existing applications? Apologies if I have misunderstood.

Yes, the behaviour is automatically inherited.

Oh hell, I didn’t know there was one. Where is it?

The theme manager? I believe this is what Ben’s referring to, although it’s more of a tool to load the right high-res theme sprites from disc rather than a fully-fledged theme manager.

The last part is about a theme configure plugin:
https://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/SystemRes/ThemeDefs/doc/Design?rev=1.4

The theme manager? I believe this is what Ben’s referring to, although it’s more of a tool to load the right high-res theme sprites from disc rather than a fully-fledged theme manager.

Thanks Jeffrey. That actually looks OK in isolation (it’s blissfully unaware of Theme$Current, but that would usually be imposed later during boot anyway). Though it could check Theme$Current too I don’t think it would add anything. For starting with better ROM sprites (that’s its purpose essentially) that seems to work OK. It’s hard-wired to only replace certain resources and it doesn’t scale well but they aren’t really problems in its limited scope. My concern has been with the change to IconSprites.

The documentation and implementation doesn’t seem to suggest that !ThemeDefs is a general purpose Theme repository for third party apps to use. Nor can it be used to theme anything but the Wimp, Paint and Draw. The Theme Protocol and its various implementations (some more compliant than others it appears) are general purpose and do support third party use, so in that respect these two systems are orthogonal. However, the automatic IconSprites thing remains perplexing. That’s a quite separate thing from !ThemeDefs and its loader.

Is the magic IconSprites behaviour limited to paths of the form *.!*.!Sprites or does it ALWAYS stick <Wimp$IconTheme> in there regardless of where the spritefile is? Could its scope be so reduced without affecting its current uses? If not, it remains incompatible with the Theme Protocol (not exclusively, but more so than any other app layout because directories beneath !app.Theme are defined to contain other arbitrarily named sprite files in addition to !Sprites, whereas in other app layouts additional sprites may be hidden inside a Resources directory).

In other words, this is typical:

|| !ThisApp.!Boot

Set Theme ""

If “<Theme$Current>” > "" Set Theme “<Theme$Current>”

IconSprites <Obey$Dir>.Theme.Default.!Sprites

IconSprites <Obey$Dir>.Theme.<Theme>.!Sprites

IconSprites Theme:Apps.ThisApp.!Sprites

Unset Theme

 !ThisApp

  |-!Boot

  |-!Run

  |-!RunImage etc etc

  |-Resources

  ’-Theme

     |-Default

     |  |-!Sprites

     |  |-!Sprites22

     |  |-Extra!Sprites }

     |  |-My!Sprites    } <— This is the namespace clash 

     |  |-Old!Sprites   }

     |  ’-Icons

     ’-RO4

        |-!Sprites

        |-!Sprites22

etc

Aside: Aaaargh! The markup on this forum is atrocious. Why the double-spacing in the above <pre> tags? Why is it impossible to write Pling something Dot Pling something?

Something

See?

Oh, apparently it thinks it’s an image… even when inside <pre> tags.

UPDATE! Octal HTML entities work, but not hex ones: ! &#x0021;

Funny, we rarely (ever?) see anybody praising Textile, just many people fed up at how it takes a set of standards and breaks them in horribly convoluted ways (as you mention, and I repeat, why does spacing outside of certain formatting tags affect the contents within said tags?).

As for your immediate problem, I would guess you want something like:
!this!

The code for that is:
<notextile><code>!this!</code></notextile>

The notextile tag is useful for reverting back to HTML for stuff that Textile simply cannot do without being a monumental P.I.T.A.

Thank you. <notextile> is indeed what I was looking for.