WimpVisualFlags Button Parameters Introduced in 5.29

The WimpVisualFlags star command is a very useful star command as it can be used to alter the look of the desktop system wide.

Now in RISC OS 5.29 from late July 2021, it allows for extensive support to change the look of Icons too. This is a wonderful step toward providing a more complete themable desktop.

From testing the new functionality, I think there are a few things not quite correct, but perhaps I’m being pedantic so thought I’d raise it here for discussion.

The new parameters are:

I used some garish colours to test this new functionality.

This is what it looks like for each Icon Border Validation String

Hopefully you can see how each of the colours relate to each WimpVisualFlag parameters (with the exception of the -ButtonHighlightColour which is excluded as it relies on being clicked)

My Queries around current implementation

1. The flags identify to change button colours, but would it not be more accurate to say they are an Icon, and hence all the parameter names and abbreviation are incorrect?
2. The -ButtonBorderFaceColour and -ButtonBorderOppColour help descriptions are not quite accurate when they say its for top left and bottom right colours respectively. They actually change based on the border validation string used (as you can see in the image above). Perhaps they should be more like the wiki PRM’s and state they change the Light3DEdge and Dark3DEdge.

I feel I’ve been far too verbose in this post. Basically, What are everyone else’s thought on this new functionality? I know there are still a few Flags missing for icons, such as Writeable Background Colour, Writeable Font Colour, and Caret Colour etc, but I just want to discuss what has been implemented. Using them certainly brings up some startling looks in certain apps.

!Boot.Choices.Boot.PreDesk.ThemeSetup file Example

WimpVisualFlags -RemoveIconBoxes -WindowOutlineOver -WOC &505258 -BBFC &FF0000 -BBOC &00FF00 -BBSC &0000FF -BC &FFFDD0 -BWC &FFFF00 -BHC &444444

Basically, What are everyone else’s thought on this new functionality?

My feeling, albeit highly biased, is that introducing more built-in functionality to the built in wimp icon styling is the wrong way to do things. It would be better if the ability to style icons and provide differing mechanisms for drawing the icons could be passed off to plugin modules which could provide the functionality in different ways. This would allow different ways to render the icons, dynamically at runtime and replacable without having to install specific versions of the WindowManager.

Additionally, it would mean that less assembler is added to the WindowManager’s already bloaded and confusing frame beyond that needed to make the interface for exposing the ability to draw the icons how you like.

RISC OS is, by its very nature, configurable and extensible through vectors and plugins. The interfaces for exporting functionality out of the WindowManager already exist in the form of the FilterManager and an interface to be able to expose the rendering of different window icon styles was defined in Select.

So, yes, my feeling is that this is going about it the wrong way.

References:

• https://usenet.gerph.org/IconBorders/
• https://gerph.org/riscos/ramble/iconborders.html

You may well be right about abstracting the functionality away from the WindowManager, however, as the code was never made available, RISC OS 5 has never gained all that great work that was done and now seems lost to us all which is a great shame. I did see nemo’s work on twitter several months ago where he created some new plugins for the GUI that looked really good, but again, alas not available to RISC OS 5.

I love the RISC OS Rambles blog, and have read it many times over the years. It must have been so hard having a whole OS user base expecting so much from you. I can’t imagine the stress and pressure that must have caused. At least now, RISC OS is now a non-commercial Open Source venture so hopefully the OS developers don’t feel as much stress from their involvement.

I see what you mean about ‘Button’. I suppose the idea is that if not functionally at least in appearance R1,2,5-7 all look like a button that’s pressed or unpressed. R3,4 are the odd ones out – can these be used at buttons? WinEd wouldn’t let me. Channel is what’s called Group box in WinEd and Labelled box in toolbox. The editors don’t seem to have an option for ridge, but there’s an example in TextSeek.

I expect in the future there would be more options distinguishing button and non-button. For example if you set

*WimpVisualFlags -BHC &FF0000

and look at Configure > Windows, you see that as well as the buttons being red, also the background of iconbar speed is. I guess as it stands the Wimp when drawing must go by looks and not function.

For the descriptions, I think top left/bottom right is a fair mnemonic, and match the existing window/menu help text. In any case your image looks a very useful reference. I wonder if there is a similar tool available for theme designers to see the effects of settings immediately on all icon types?

I’ll look forward to seeing how updated themes take advantage of this!

You may well be right about abstracting the functionality away from the WindowManager, however, as the code was never made available,

So reimplement the functionality. It’s really not all that hard (honest). Doing it a different, less extensible way seems (to me) to be just generating more incompatibilities for little reason. And personally, I find frustrating that I spent the time to work out a good way to do things that would be able to be used by other people and then people go and do things in a different and incompatible way.

The information of the API was in the IconBorders SDK that went out, although I can’t find the docs for the FilterManager changes in my copies of things here – it probably got lost when I lost a lot of things. I could almost certainly re-write that documentation in a few hours without too much hassle.

To back up my statement that it’s not a good way to do things, you’ve created new options that will not work on earlier versions of the system, so when people downgrade they’ll lose ALL styling on the system because the `*WimpVisualFlags` settings could not be parsed. Having a separate configuration for the icons makes it much more flexible. There’s ways around that with having the command issued in stages, but it’s an extra burden that is unnecessary.

I have exported one of the modules from the IconBorders SDK:

• https://github.com/gerph/iconborders-example/

It really isn’t that complex – most of the code is a duplicate of the default algorithm. An implementation that provided the interface to change the colours as you have described above would be significantly easier because it would only need to provider the `IconBorder_Colour` entry point to update the colours.

Binaries published under releases:

• https://github.com/gerph/iconborders-example/releases/tag/v0.08

I have written (re-written?) the documentation for the FilterManager interface for the icon borders:

https://github.com/gerph/iconborders-example/blob/iconborderfilters-documentation/prminxml/filters-iconborders.xml

R3,4 are the odd ones out – can these be used at buttons? WinEd wouldn’t let me. Channel is what’s called Group box in WinEd and Labelled box in toolbox. The editors don’t seem to have an option for ridge

I think all you need to do is change the Icon Button Type flag to one of the clickable values.

I guess as it stands the Wimp when drawing must go by looks and not function.

Yes, there is no concept to gui control classes built into the Window Manager. There is only Window and Icon.

I have exported one of the modules from the IconBorders SDK:

Wow. That’s impressive, and the test example works perfectly to showcase your logic that different border types can be implemented if a FilterManager for icons exist in the RISC OS 5 Window Manager.

you’ve created new options that will not work on earlier versions of the system, so when people downgrade they’ll lose ALL styling on the system because the `*WimpVisualFlags` settings could not be parsed.

I haven’t tested it on an older version of RISC OS, but I understand what you are saying. It may well cause the whole command to be discarded if all the parameters are not known.

Wow. That’s impressive, and the test example works perfectly to showcase your logic that different border types can be implemented if a FilterManager for icons exist in the RISC OS 5 Window Manager.

It’s not that complicated; aside from the colour selection it’s essentially just the same code as you would use on the BBC, just written in C. ‘cos the graphics calls are exactly the same. If you’ve seen my discussions about writing test code, it should be a pretty familiar pattern – write some code that just exercises the same thing as you would write in the module, so that you can check the behaviour without long cycles between development and test.

And of course, I’ll stress again that this is being built and exercised on the online build system – that’s what built the binary that you ran, the module that provides the borders, and then saved the test output sprite.

My understanding is that while the Select code is not (legally) available, the API could be re-implemented. Even if not fully at first, it would be a start.

While a lot of the work in Select was coding, there was also a lot of design work which I believe CAN be used in the ROOL “branch”. There is no point in adopting a “not invented here” approach if we can benefit from what’s been done before.

I have uploaded the IconBorderFob example source code from the SDK. This was a second example to show a relatively simple set of modifications:

• Using a different buttons style.
• Only providing some of the buttons (so the others would be unaffected).
• Forcing colours (which isn’t a good idea in general, but for specific cases can be desireable).
• Supports highlighting.

The source can be found here:

• https://github.com/gerph/iconborders-fob

The release is downloadable here:

• https://github.com/gerph/iconborders-fob/releases/tag/v0.08

And this is a screenshot of the test code running under Pyromaniac: