Iconbar at the top

With Raspbian I can choose to have the iconbar at the top. I can also choose its background colour to blend in with the desktop background image, which, more often than not, is more uniform at the top, being sky. So the contents of the iconbar appear to be floating at the top; it means fewer harsh straight edges. With Manjaro I can choose to put the window furniture where I want on a window’s titlebar, and even to have two copies of the close-window icon, one at the extreme left and one at the extreme right.

What are the chances of these facilities being available for RISC OS? Choosing to have the iconbar at the top surely cannot mean a radical upheaval.

Choosing to have the iconbar at the top surely cannot mean a radical upheaval.

Apart from all the applications that know that it’s at the bottom and how tall it is…

Most applications only know the iconbar by its icon number. How many need to know its size or position? I do remember a funny little application that had a railway train emerging from a tunnel and running along the top of the iconbar. But I cannot think of any others.

There’s menu offsets (and other related stuff?) defined in the Style Guide, so that will have to be reviewed and standardised.

For instance, when you open a new document window in PipeDream, it offsets its position from the previously opened one, but tries not to obscure the icon bar – so it needs to know its placement and height. Fireworkz adjusts the position of dynamically-created dialogue boxes similarly.

For instance, when you open a new document window in PipeDream, it offsets its position from the previously opened one, but tries not to obscure the icon bar – so it needs to know its placement and height.

That’s not even the biggest problem. Every application with an iconbar icon will open its iconbar menu at a height of “menu height + 96 OS Units”, using the same Wimp_CreateMenu SWI that any other menu is opened by. Each one would need updating to open its iconbar menu in the new correct place.

And I don’t think that the Wimp could even detect a Y position of “menu height + 96 OS Units” in the style of a true Acorn bodge, because with the iconbar at the top of the screen, the likelihood of a “normal” menu opening at “menu height + 96 OS Units” is high enough to be unacceptable if the result is the menu zipping off to the top of the screen when it does go wrong.

Well that is all very sad: evidence of historic insufficiency of abstraction, aka concrete code.

IIRC RISC OS 2 had its iconbar defined in a template file, so with some DeskFS meddling you could FormEd-it it into being a movable window with a titlebar. Stuff went mildy wrong if you did that though. Around RISC OS 3 time I think it got hard-coded into the Wimp.

You could probably use a Wimp filter to adjust menu opening positions (if middle click on icon bar, intercept Wimp_CreateMenu and adjust position of next menu opening) but there’s other things in the mix, like the ‘no cover icon bar’ flag. My PrivateEye app respects that flag and because of the lack of an official interface for these values ends up assuming that the iconbar is at the bottom of the screen with a height of 134 OS units.

Ah well. Thanks for the replies. It was only a trivial suggestion.

Well that is all very sad: evidence of historic insufficiency of abstraction, aka concrete code.

Um. It’s RISC OS… what were you expecting…?

Difficult path to navigate, between concrete code and bloat. Has anyone managed to get it right?

Back in the dim past, I began to abstract the iconbar so that the system could provide multiple classes of application icons in different places, handled by different parts of the system. The idea was that applications created icons as normal through the regular interface. These were created within the Iconbar window as normal but the iconbar wasn’t visible. Clients could be registered which would know about the iconbar regions – the left side, right side, or specific priorities. Because the priorities were defined for particular things, you could ensure that (for example) disc devices were always held together. The interface which showed their icons could be provided by separate applications which did so in completely different ways to the standard iconbar. Thus applications might appear prominently, whilst devices are only available when you select a different part of the screen, or expanded something… or whatever you wanted.

The managing application would obviously send messages to the application that was clicked on to ensure that it still got those events. The issue of the iconbar menu position was a minor issue, but relatively easy to recognise:

a) you’ve just clicked on an application via the iconbar, so the next menu (or window) to open by that application on receipt of that call is going to be a response to that.
b) the position of the menu is recognisable because it is defined to appear with its base at a given y-coordinate.

This meant that it was relatively trivial to filter off with WimpSWIve in the prototype, and make sure that it appeared in the correct location.

It was never completed but the process of separating away the iconbar was something that was considered and worked on. The managing apps were amusing in that as they started they were populated with icons (eg a ‘drives’ iconbar handler) from the main application handling the iconbar, and then when the application exited, the iconbar icons moved back to the main iconbar again.

I had also played with the way that the iconbar reported its position so that Pinboard could size itself properly. I do not remember if that code worked correctly however. Part of the idea of that was that even without the separate handler, the iconbar could slide off the bottom of the screen and then slide back on again, with Pinboard moving its image as appropriate.

Some notes about it can be found here:

https://gerph.org/riscos/ramble/futuredirection-desktop.html#Iconbarabstraction

Has anyone managed to get it right?

No, I was being unreasonable. Lots of RISC OS had to err on the concrete side for good economic reasons. I remember how everybody complained in the early days how the excessive abstraction of X11 slowed everything down (on Sun workstations). Hardware caught up in due time. Besides, I think part of the pleasure of RISC OS is seeing how ingenious geniuses can jump the concrete barriers now and then. Thanks, Gerph, for the reminder.

I’m old school. I like my icons where they belong. Down there hidden behind the bag of Maltesers…

https://gerph.org/riscos/ramble/futuredirection-desktop.html

And a few pages further on… the idea of creating system sprites on the fly from DrawFile originals. Now there is an idea with merit.