Themed Wimp

Chris,

The theme manager is really nice. I’ve installed it on my Iyonix and I get a dialog box saying argument repeated when I run it. Any ideas?

I can’t reproduce that here. Could you provide any more information? Of particular interest would be:

- Is the error from the Theme Manager plug-in (i.e. the application you run from Configure), or does it pop up when you start the Desktop (and is prefixed by the text ‘Error from Theme Selector v1.18)?

- Are you using Fred’s new WimpSA module?

- Can you give me the exact error message? If it’s coming from my app, then it should give a line number too. However, it may be interfering with something else.

Thanks, Chris

I don’t get an line error but if I remove the !Themse application I no longer get the dialog box on boot.

I have put !Theme into a separate directory. If I open this, I then get the dialog box with the message “Argument repeated” so its something to do with application being seen.

I am running plain 5.13 Iyonix with no new WimpSA module

The “Argument repeated” error is caused by the WimpVisualFlags line in the ‘Output’ obey file. Specifically, the WimdowOutlineColour argument. You need to install the newer version of the WindowManager, mentioned further up the thread, to stop this error.

What might be a good idea is if the theme manager only included that argument if the newer module is installed.

Thanks. The Themes program should only apply the outline colour changes if the new Wimp is present. Fred’s module has a version number of 5.00 at present, which is what is checked for in !Themes. Presumably RO5.13 has a Wimp module with the same version number or higher. So I guess what’s needed is for Fred’s module to have its version number increased to differentiate it from the other versions out there.

I’ll drop an email to Fred to let him know. It would be helpful Mark if you could let me know what the version of the Wimp is on your system. Open a Task Window and type *help WindowManager, which should display the version number.

In the meantime, you can get the system to work either by downloading Fred’s module, or by manually editing the !RunImage file. Got to line 160, and where it says:

IF (OS$="RISC OS 4" OR OS$="RISC OS 5") AND wimp%>=500 THEN

alter the 500 value to something more than the current one in your machine.

Chris,

Its version 5.00 dated 23rd February 2006

Thanks for working out the problem

I’ve changes 500 to 601 and even altered RISC OS 5 string to stop it and I still get the error.

Final answer: I think it’s ModSqz.

You’ll be glad to know it’s nothing to do with your new code

Many thanks for looking into this James. I’ve had a quick check on the RiscPC and the keyboard shortcuts are there so there may be another contributing factor. I’ll do more some testing later on.

Fred’s module has a version number of 5.00 at present

Thanks for pointing this out, I’d forgotten to update the version number and date. I’ve uploaded an updated version. Could everyone who has downloaded the latest version please download it again. Apologies for the inconvenience. http://home.casema.nl/fjgraute/newwimp.zip

Mark,

Please try downloading the Theme Manager application from the website (http://www.lym.iconbar.com/themes) again. I’d be grateful if you’d let me know if this solves your problem. You may wish to delete your old copy before doing this, but I don’t think it should be necessary.

Chris

Works a treat!

I’ve just tried the themes manager and wimpsa module and the steel theme is very nice.

However I noted a couple of oddities:

1) When I switch back to ‘No Theme’ the screen isn’t redrawn ie I have to do an f12 return to see the original theme.

2) The theme that it returns to as a result as selecting ‘No Theme’ is not the theme I was using. I’m using an Iyonix RO 5.11 but was using a slightly modified RO4 window furniture. The RO4 furniture that it returns to is not the same.

2) The theme that it returns to as a result as selecting ‘No Theme’ is not the theme I was using. I’m using an Iyonix RO 5.11 but was using a slightly modified RO4 window furniture. The RO4 furniture that it returns to is not the same.

The Themes Manager switches back to the ROM tools when ‘No Theme’ is selected. To get your old theme back it’s probably easiest to wrap it up as a theme and add it to the Themes Manager and select that instead of ‘No Theme’.

Hi Colin,

When you re-boot you computer with [No theme] set, does your desktop look as it should? Unless you select a theme from the menu, !Themes shouldn’t interfere with any non-standard settings you may have when run from start-up.

However, if you select [No theme] during a session, perhaps after experimenting with setting other themes, you are correct that the desktop doesn’t redraw. I’m not sure why this happens – it’s something I need to look into. Moreover, the Configure plug-in isn’t very sophisticated when trying to re-set the desktop to a [No theme] setting. It currently just *Iconsprites the sprite sets in Resources:, which is why your non-standard set-up isn’t being picked-up.

I guess what would be better would be if the plug-in took a copy of the sprites being used when run, and reverts to these with [No theme] is selected. I’ll have a look at this when I get time.

It turns out that I did have problems with the steel theme not working after a reboot. It turned out to be my toolsprite file being loaded after the theme manager loaded toolsprites – so I needed to remove loading my toolsprites for the theme manager to work.

As Fred pointed out what I was seeing with ‘No Theme’ were the roms tools and as I had to remove the loading of my toolsprites I don’t think that there is any need to do anything other than use the rom tools.

I notice that there is an ‘ugly’ delay introduced when the desktop appears when only the clock from Alarm is visible for a few seconds is this normal?

One change I’d like to see made is I’d like to be able to use the window furniture but not the sprites.

Hi,

I’ve been using WimpSA and the Themes Manager now for a couple of weeks – a definite step forwards ! However after loading the latest versions today I’ve noticed a couple of oddities,

1) WimpSA – although the file header says v5.01 (13 Mar 2008) the version given by the installed module is 5.00 (07 Oct 2007).

2) I seem to have lost the character for “shift” on the Menu keyboard shortcuts. A previous poster reported all shortcuts lost but ^ for “ctrl” is OK. This seems to occur for any desktop font using the /base0 encoding, eg Homerton, Trinity, etc. where ASCII character &8b is undefined.

This is all running on an Iyonix, RISCOS 5.11

2) I seem to have lost the character for “shift” on the Menu keyboard shortcuts. A previous poster reported all shortcuts lost but ^ for “ctrl” is OK. This seems to occur for any desktop font using the /base0 encoding, eg Homerton, Trinity, etc. where ASCII character &8b is undefined.

Just to recap:

This is the Window manager 4.15 (RISC OS 4.02 version)

The latest version modsqz’d 5.01 (13 Mar 2008) shows nothing on my machine.

Version 5.00 not modsqz’d and without your additional code, the shift symbols are missing.

Perhaps the shift symbol being AWOL bug has been present for a while and nobody noticed. In which case the next step is to go through old versions via CVS until you find one where it works

I assume from the fact that people are talking about “WimpSA” that people have been building “standalone” builds of the Wimp, by building the “install” phony target. At Acorn/Pace, at least as far back as the Nested Wimp, we only actually built the “rom” target, even for softloading purposes – this is why there’s a TaskObey file in the Wimp sources to make “rom” but not “install”. As far as I’m aware, the standalone build hasn’t been tested in all that time.

If a “rom” build of the Wimp doesn’t suffer these problems, I’d suspect that there’s something wrong with the version of the WimpSymbol font inside the Wimp sources. This version hasn’t actually been used in years – the actual location of the ROM fonts in CVS is RiscOS/Sources/Video/Render/Fonts/ROMFonts (this component hasn’t been released yet).

The version I built without the new code, which suffers from the missing shift symbol and when Modsqz’d loses all shortcuts was the ROM build.

I’ll admit I was puzzled why WimpSA is being supplied when there is no obey file to build it.

Yes, just to add to Ben’s comment, the “SA” suffix it just to ensure that the module doesn’t get mixed up with the ROM version when people are building stuff. It is not intended to be distributed with that name.

When a disc build is performed, and things get installed into the Install directory, the ‘install’ rule in most components makefiles normally uses $(TARGET) as the leafname for the component. For the Wimp module, this should be “Wimp”.

Sooooo, you should really be calling the module “Wimp” and not “WimpSA”.

Could I have an indication of when people want this stuff folding back into our cvs repository? The cludges mentioned above about up-versioning the Wimp really make me wince – that’s exactly what we DON’T want happening! If you take a module from ROOL and make changes that you’re happy with, we should be folding that back into cvs and up-versioning in the standard fashion.

The up-versioning of the Wimp was necessary so that Theme Manager could tell the difference between the updated Wimp and the version in ROM (to sigmify this I created a standalone build rather than a ROM build). In retrospect it would have been better to contact ROOL about how to best go about this and I apologise for not doing so.

The code is largely ready to be folded back into CVS bar the odd comment here and there. What’s holding it back is the issue with keyboard shortcuts in menus not being displayed correctly.

James’ tests show that the shift symbol also disappears when a ROM build of the Wimp is made that doesn’t contain any additional code. Tests here show the same so it’s most likely not down to the changes I’ve made, but I’d prefer confirmation of that before submitting the changes.

However if ROOL are happy to receive my changes before the issue is resolved then I’ll finish off the changesets and send them in.

Is it too late to chip in regarding Theme stuff?

Is there any objection to my setting Wimp$IconTheme to a string with the name of the currently selected theme?

Erm, yes. Richard Goodwin and I sorted out a very nice theme protocol years ago (2001) which he used in his ThemeManager and which was supported by a number of applications.

• The current desktop theme should be in a variable called Theme$Current.
• Icons for the current theme should be accessible through the Theme$Path variable (i.e. Theme:)
• !SomeApp must load theme icons in the following way:

  Set Theme RO4
  RMEnsure UtilityModule 3.80 Set Theme "" 
  If "<Theme$Current>">"" Then Set Theme <Theme$Current>
  IconSprites <Obey$Dir>.Theme.Default.!Sprites
  IconSprites <Obey$Dir>.Theme.<Theme>.!Sprites
  IconSprites Theme:Apps.SomeApp.!Sprites
  Unset Theme

And the application will be structured like this:

  !SomeApp
    |--!Boot
    |--!Run
    |--!RunImage
    |--Resources
    '--Theme
         |--Default
         |    |--!Sprites
         |    '--Sprites
         '--RO4
              |--!Sprites
              '--Sprites

Private application icons should be loaded in a similar way. This allows:

• the application to adapt to the installed OS/theme.
• the application to contain multiple themed icon sets which only need to include those that differ from the default set, reducing storage requirement (eg RO3 versus RO4 directories)
• the sprites to adapt to monitor calibration (eg “RO4” versus “RO4_Linear”)
• the user to override individual icons without having to duplicate the rest or change the application files.
• the user to override the OS icons without changing operating system (eg “Set Theme$Current RO3” in an RO4 boot sequence).
• installed themes to replace application icons without affecting the application installation.
• updated applications (with additional icons) to continue to work without losing icons even when themed with an older sprite set.

Obviously Theme$Path can contain both official and user prefixes (with user first), thereby allowing the user to fine-tune ANY icons without fear that an application or OS update will blow their edits away.

OK. It would be good to follow the existing protocol, especially if some third-party apps already use it. Wimp$IconTheme is apparently set by the Wimp, so it seemed an obvious choice. However, it may be desirable to replace this with Theme$Current, or simply set both.

I’m a bit confused by the pathname in the penultimate line of your !Run file example. Under my Theme Manager scheme, the Icons and Tools would be held in

BootResources:!Themes.Themes.<Theme$Current>

IconSprites Theme:Apps.SomeApp.!Sprites

The following minor modification would work:

IconSprites Theme:Icons

Which I think looks quite neat ;-)

Just to muddy the waters a little:

Wouldn’t it be easier to alias the IconSprites command onto something in a support module, rather than require apps to have their !Run files changed?

Fred, when you submit your changes to ROOL would you mind including the bug fix described at: http://groups.google.co.uk/group/comp.sys.acorn.programmer/browse_thread/thread/8edb718a3ba7e1fb?hl=en

I’m not going to bother adding this to the tracker at the moment.