What is Wimp$IconTheme etc?
nemo (145) 2603 posts |
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? |
Jeffrey Lee (213) 6048 posts |
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. |
nemo (145) 2603 posts |
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:
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? |
WPB (1391) 353 posts |
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”. |
Ben Avison (25) 445 posts |
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:
|
nemo (145) 2603 posts |
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 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. 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. |
nemo (145) 2603 posts |
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. |
Rick Murray (539) 13890 posts |
Aaaaaaaargh!!!
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). 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:
I believe this would be a more useful future-going way to ID the device in use. |
nemo (145) 2603 posts |
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.
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. ;-) |
Ben Avison (25) 445 posts |
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.
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!
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… |
nemo (145) 2603 posts |
I thought this was automatic behaviour by *IconSprites and hence inherited by all existing applications? Apologies if I have misunderstood.
The namespace issue is the problem. An application that uses the Theme Protocol will *IconSprites the following files:
When it runs it may load its own sprites from the same locations:
Thanks to Wimp$IconTheme there is now a potential clash between the monkeying-about with the Consequently I’d have to conclude that the two are incompatible and advise that
Oh hell, I didn’t know there was one. Where is it? |
Jeffrey Lee (213) 6048 posts |
Yes, the behaviour is automatically inherited.
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. |
Wouter Rademaker (458) 197 posts |
The last part is about a theme configure plugin: |
nemo (145) 2603 posts |
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 In other words, this is typical:
With the app containing:
|
nemo (145) 2603 posts |
Aside: Aaaargh! The markup on this forum is atrocious. Why the double-spacing in the above Something See? Oh, apparently it thinks it’s an image… even when inside UPDATE! Octal HTML entities work, but not hex ones: ! ! |
Rick Murray (539) 13890 posts |
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: The code for that is: The |
nemo (145) 2603 posts |
Thank you. |