Iconbar Sprite Enhancement

At the moment the Iconbar uses the same sprite as the filer windows rather than it’s own. Although it has served us very well for many years, it would make for a more visually impressive Desktop if the Iconbar could have it’s own sprite.

It would probably have to be similar to Titlebar’s implementation where it would have multiple sprites (left, right, upper & lower) And this would allow for various sizes of iconbars.
If a theme doesn’t have the sprites names, it falls back to use the filer windows sprite (as it does now).

Would there be a lot of work to achieve this? or as code for plotting titlebars sprites already, or simply reusing what we already have an pointing to a different sprite pointer?
Would there be other people interested in seeing this happen? (a roundabout way of asking if anyone would like to attempt the work ;-) )

I think it is more that the icon bar and the filer are using the application’s app sprite. ;-)

I am not volunteering, however I had wondered about the feasibility of a half-height iconbar¹ to give a little more screen space (especially on lower resolution devices such as the Pi’s composite video) – there is already in many places a suitable sprite in the “sm!appname” sprite. This will mean, as a side effect, that pretty much every iconbar menu will appear to ‘float’ as opening menus is the responsibility of the app and they open at a specific preset y-pos for iconbar menus. This could perhaps be corrected by hacking the wimp to say “if iconbar = small and menu-y = blah, then menu-y = meh” but I’m not sure I like the idea of messing with stuff in that way. Don’t even think about the messing around that would be needed to deal with placement of menus if the iconbar is anywhere other than the bottom of the screen – in there lies insanity.

¹ With a basic on-screen clock as a part of the iconbar itself (not an additional app), like Windows, like Ubuntu, like…

This will mean, as a side effect, that pretty much every iconbar menu will appear to ‘float’ as opening menus is the responsibility of the app and they open at a specific preset y-pos for iconbar menus.

The first thing I thought about was the possibly not so minor detail that application icons are a specific size and with an iconbar that isn’t a matching height icons could look like christmas cards on a rail¹ unless a scaling method is used, but yeah ‘float’ is probably a reasonable description.
At the risk of sending people into ani-Linux rabid fits, there is the idea of putting a left and right iconbar area and leaving the bit in the middle blank (or different)

¹ This might be a positive thing for some users

With a basic on-screen clock as a part of the iconbar itself (not an additional app)

Clock, CPU temperature … ?

it would make for a more visually impressive Desktop if the Iconbar could have it’s own sprite. Would there be a lot of work to achieve this?

None whatsoever – you can already do it today.

The iconbar is just another window which the Wimp loads it from a templates file held in “WindowManager:Templates”. The tiling is based on the workarea background colour, which by convention is colour 1, and the tile sprite for that is called tile_1 in the Wimp pool.

So, somewhere prior to entering the desktop just prefix the WindowManager$Path with some chosen directory, and place a copy of the Templates there. Use your favourite template editor to set the background colour of the ‘iconbar’ template to be some unlikely colour like 8 (deep blue). Make a sprite file with a tile in it called tile_8 and ICONSPRITES that file.

Here’s a merge-with-boot demo to illustrate.

This will mean, as a side effect, that pretty much every iconbar menu will appear to ‘float’ as opening menus is the responsibility of the app and they open at a specific preset y-pos for iconbar menus. This could perhaps be corrected by hacking the wimp to say “if iconbar = small and menu-y = blah, then menu-y = meh” but I’m not sure I like the idea of messing with stuff in that way.

Although apps can position the menus themselves, they don’t have to (I never have in any of my apps; I’ve just let the Toolbox handle it). Does anyone know roughly what proportion of apps use the Toolbox? If it’s a majority (and I really have no idea; I’m still pretty new to RISC OS) then it may be worthwhile to update the Toolbox to handle the smaller size, rather than hacking around in the Wimp directly.

So, somewhere prior to entering the desktop just prefix the WindowManager$Path with some chosen directory, and place a copy of the Templates there.

Assuming the person testing the ideas has a copy of the DDE, downloads a suitable source archive, sets up Builder, then edits the Templates file in one of the Themes .castle.riscos.sources.desktop.wimp.resources.uk.Sovereign for example, then the altered bits are in the ROM you build are they not?
Hmmm, can you do the same thing with a Template in a disc based theme directory?

it may be worthwhile to update the Toolbox to handle the smaller size, rather than hacking around in the Wimp directly.

Uh… You do realise that the only reason you don’t is because the Toolbox does (it for you)? It is really not so different (from outside) to using a library like DeskLib, only it is a module interface instead of something linked directly into your program.

The Wimp would still need to be hacked in order to cater for everything that does not use the Toolbox.

Hmmm, can you do the same thing with a Template in a disc based theme directory?

In a word, no.

I think that method used to work, back in the RISC OS 3.10 days.

However, I just copied all of the Wimp stuff from Resources:$.Resources.Wimp to SDFS as $.Resources.Wimp, and set WindowManager$Path to point to it.
The Pi’s desktop hangs at the point where the initial boot has completed and the big logo is on-screen. The mouse pointer returns to normal from hourglass, but no desktop. Don’t know why, but that’s not a good sign.

I can’t seem to unplug BootFX (reboot and it is back again). However, if I poke in a call to RMKill it, the desktop init fails with an Abort on data transfer at &FC1473B0 – which is in MessageTrans (an LDRCCB).
This isn’t worth wasting time on right now, I’m reverting my boot to normal behaviour.

Uh… You do realise that the only reason you don’t is because the Toolbox does (it for you)? It is really not so different (from outside) to using a library like DeskLib, only it is a module interface instead of something linked directly into your program.

Yes, but unlike Desklib, we have more control over the Toolbox as it’s shipped in the OS and isn’t a statically linked library. “Fixing” the Toolbox would “fix” every Toolbox app on the system; “fixing” Desklib would still need every Desklib app to be recompiled from source.

The Wimp would still need to be hacked in order to cater for everything that does not use the Toolbox.

That’s the more fundamental problem, yes… :-)

ETA: Oh, and the fact that once a non-Toolbox app has been “fixed”, it won’t work on any other version of RISC OS unless the same API is made available over there or there’s a clean way to fall back to doing the old calculations.

For those who do need to save screen space may I recommend my dinky theme for NetSurf? Available at http://www.netsurf-browser.org/downloads/themes/
It is much smaller than the others, but still works on my standard screen of 1920×1080. I also use toolsprites that are much slimmer, and more discreet, than the standard ones in the RO distributions.

I know that things like window-furniture, colours and icon-design seem like frivolities. But, amortized over the time one spends using the desktop, I reckon that getting the details right for one’s own comfort is a good investment.

ETA: Oh, and the fact that once a non-Toolbox app has been “fixed”, it won’t work on any other version of RISC OS unless the same API is made available over there or there’s a clean way to fall back to doing the old calculations.

Which is exactly why I mentioned hacking the Wimp. After all, if we are modifying a fundamental part of the Wimp to a behaviour different to that documented and implemented for a quarter century or so, the most options are:

• Tweak the Wimp to support the new behaviour and curse Acorn for never having a magic value like Y is -1 for an iconbar menu. Benefits – everything ought to “just work” except the fringe case of a non-iconbar menu opened at the same offset as an iconbar menu normally is, may appear to “jump”.

Or:

• Leave the Wimp to dumbly obey open menu requests without modification, and instead modify everything else which will surely require a massive pile of code to do with all the various use cases – older Wimp, new iconbar kept at normal size, new iconbar at reduced size, blah blah blah. Doesn’t this seem kind of nuts, really? ;-) Oh, yeah, and god help older program’s that won’t be modified, authors that follow the already-woefully-outdated PRM without looking at the forums, etc. oh, yeah, and if some crazy sod should one day try to implement a vertical iconbar…….

Yes, but unlike Desklib, we have more control over the Toolbox as it’s shipped in the OS and isn’t a statically linked library. “Fixing” the Toolbox would “fix” every Toolbox app on the system

Thanks; that’s exactly the point that I was trying to make :)

Unfortunately I forgot to say in my earlier post that I am indeed aware that fixing the Toolbox won’t help with apps that don’t use it.

At the moment the Iconbar uses the same sprite as the filer windows rather than its own.

Not true.

Actually the filer window uses the Sprite defined within the application that has the same name as the application (or a default ‘application’ icon if none exists) and the icon bar icon is whatever the application chooses to plot there. The fact that most applications choose to plot the same sprite on the icon bar is a choice they have made.

Actually the filer window uses the Sprite defined within the application that has the same name as the application

I think you’re talking about application sprites ON the iconbar.
Sprow is talking about the sprite used to create the iconbar itself.

If you look in the source files in path section I quoted earlier you will see the Templates file and sprites that do the work

At the moment the Iconbar uses the same sprite as the filer windows rather than its own.

Not true.

I think Alan was referring to the window background sprite, not the application sprites that might sit on the Iconbar.

Rick raises a fundamental point, that the position to open iconbar menus is a hard-coded value. It really ought to be something the Wimp tells (or at least suggests to) applications, not the other way around.

In terms of hacking the Wimp, you could watch menu button presses: if they’re over an icon belonging to the iconbar, record the x coordinate. Then, when the next open menu call is made, if the x offset is close to the recorded x coordinate, fiddle the y coordinate to a value suitable for the size of the iconbar.

Am I the only one who does not see this as an enhancement?

Varying the icon bar size looks like it’s going to create a real mess because the non-Toolbox-based apps would not be aware of the new requirements. But even if you could wave a magic wand and fix all that: how would it look or function any better than it does today?

I think as Rick said, it could be useful to have a smaller iconbar on very small screens. But for a lot of people, I suspect it’s just the idea of theming that’s attractive. Personally, I’m happy with it the way it is, but that doesn’t mean everyone else is. And just from an engineering POV, it’s not very pleasing the way the vertical size is hard coded at the moment! ;)

Varying the icon bar size looks like it’s going to create a real mess because the non-Toolbox-based apps would not be aware of the new requirements.

As mentioned by both Rick and WPB, it should be possible to use a relatively clean hack within the Wimp to get the iconbar menus to open at the correct location.

But even if you could wave a magic wand and fix all that: how would it look or function any better than it does today?

It would look 50% smaller with 50% smaller icons and function the same as it does now? One of the goals, as Rick says, is to increase the amount of screen real estate available on low resolution displays. Or at least, increase the number of application icons which you can fit on the iconbar before it begins to scroll – because whether it actually gives more screen real estate for other windows depends on whether you prefer to have the iconbar always at the front or not.

Of course, this discussion has mostly wandered off-topic from Alan’s original suggestion (themeable iconbar background sprite sets), which sounds like a good idea to me.

how would it look or function any better than it does today?

Well, to give you an idea, here is a slightly naff version that I made in a photo editor (dithered rescale). This shows a half-size iconbar on a 1280×1024 screen.

http://heyrick.co.uk/random/pics/codingpic.jpeg

Now imagine the difference it could make on a screen of this size:

http://heyrick.co.uk/random/rocmos.jpeg

If we’re feeling really extravagant, we could even have application icons on the icon bar “pop up” (to regular size) when the mouse lingers over them. Maybe even with a slight jiggle iOS style. Then we don’t need to fiddle menu positions. :-).:-) :-)

You’ve convinced me that the current icon size is better in both situations.

You’ve convinced me that the current icon size is better in both situations.

Yes.

Text plus sprite icons risk having the text become illegible because there aren’t enough pixels.

Simply use smApplicationIcon. Works for the filer, should works for the taskbar.

Of course, this discussion has mostly wandered off-topic from Alan’s original suggestion (themeable iconbar background sprite sets), which sounds like a good idea to me.

I think shortening the sentence to “themeable iconbar” should cover it.

Text plus sprite icons risk having the text become illegible because there aren’t enough pixels.

I sometimes wonder whether we should bother with text in the iconbar icons.

Consider this: If you look in $.Apps and run !Help and then hover over an iconbar icon there should be text telling you about the application that owns the icon – so why do we need text incorporated in the iconbar presentation and stealing space from the graphical aspect of the iconbar presence?

While we might not want the full Help implementation active what’s wrong with a simplified implementation?
Then you can use all the space for the graphics. Of course since we’re talking about a themeable aspect people who like the old way can have the legacy theme.