Iconbar Sprite Enhancement

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

Because when you have lots of similar devices/directories/files attached to the iconbar it helps to tell one from the other. Having to check the help text is no substitute – just try Windows 7/8 which has a iconbar exactly as you describe.

My iconbar at the moment has 7 folders 2 wav files and 2 obey files attached to it. Removing the text would make it unusable.

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

How do you differentiate hard drives, memory sticks, shared drives, printers that may have the same icon, iconised windows, etc? Having to use help text all the time would be an absolute pain.

How do you differentiate hard drives, memory sticks, shared drives, printers that may have the same icon, iconised windows, etc? Having to use help text all the time would be an absolute pain.

Ah, now there you come to the discussions about MiniDisc which pulls all disc icons into one with menu driven selection of specific drives and the suggestion that Printers should be given the same treatment.

I think you’re asking questions that were answered in a previous century.

Rick’s mock up does look very short, but I’m sure most people would get used to it very quickly and decide there are real benefits. Only expensive monitors are more than 1080 pixels high. Vertical screen space is at a significant premium!

I think you’re asking questions that were answered in a previous century.

Not really. Iconbar grouping is not very convenient. May as well have a computer icon and access everything via a directory tree.

Isn’t the more obvious answer to that problem to look at an icon bar which can be relocated to the left or right side instead (or indeed floating)? That said, knowing my workflow on a mac would be better if I abandoned the bottom-dock for a side-dock, I still can’t do it :-(.

Isn’t the more obvious answer to that problem to look at an icon bar which can be relocated to the left or right side instead (or indeed floating)?

Now there’s a thing, do icons appear relative to the bottom of the iconbar or relative to the bottom of the viewable screen?

but I’m sure most people would get used to it very quickly and decide there are real benefits. Only expensive monitors are more than 1080 pixels high.

For those who are obsessed with vertical space – as I am – the iconbar takes up no vertical space. You just make the full size window cover it and have it pop to the front when needed. The height of the iconbar is unimportant and it’s width is dependant on text size – the text is invariably wider than the sprite and that needs to be readable.

None whatsoever – you can already do it today. Here’s a merge-with-boot demo to illustrate.

OMG, your demo looks hideous, but thank you so much for showing me how to tweak RISC OS to get a different background sprite on the Iconbar. I’m going to pimp up my Desktop this weekend. Word!

And thanks to everyone else for a very enjoyable read. I do love talk on User Interfaces. Hmmmm, now, How do we replace RISC OS’s ancient modal error dialog box and with a proper system-wide notification window?….. ;)

I’m going to pimp up my Desktop this weekend. Word!

I’ve been testing it out and run into an stumbling block already. It looks like the sprite routine tiles the sprite, but it always aligns the bottom of the sprite with that of the text that appears in text+sprite icons (such as the filer icons).

In practice you’d want the vertical sprite tiling to start from the the top/bottom of the Iconbar. Until it gets changed, I can’t see being able to improve the look of the Iconbar. Shame. So close…

It seems the the sprite tiling routine starts from 12 pixels up. So I adjusted my sprite accordingly, and this is the result. A nice shiny iconbar.
https://drive.google.com/file/d/0B15K0f5Ieb99UzJFUnM5R1NoR1k/edit?usp=sharing

I’ve noticed that changing screen mode seems to change the horizontal starting position when tiling the sprite. And even going back to my orignal screen mode doesn’t seem to fix it. Strange.

I don’t think it will catch on. Looks rather grubby but otherwise just the same as normal.

I don’t think it will catch on until we get transparent backgrounds to text on both the Iconbar and the desktop.

For those who are obsessed with vertical space – as I am – the iconbar takes up no vertical space. You just make the full size window cover it and have it pop to the front when needed.

Indeed, you could even hide the iconbar completely using Peekaboo

There’s currently an issue with Jpeg backdrop images – the space occupied by the iconbar isn’t redrawn – but that can be easily fixed by making the Pinboard use an iconbar height of 0.

I don’t think it will catch on until we get transparent backgrounds to text on both the Iconbar and the desktop.

But we already have that.

*WimpVisualFlags -RemoveIconBoxes -NoIconBoxesInTransWindows

I don’t think it will catch on. Looks rather grubby but otherwise just the same as normal.

So not quite ready to be the default look for RISC OS ? ;-)

No worries, I’ll be coming up with some more Iconbar designs that will make RISC OS look modern and fresh. Anyone else fancy giving it a go?

A few thoughts.

The current appearance works well and should be the default. Options for different sizes and icon groups and no text would be nice. It would be good for a theme scheme to be able to change these. (It would also be good for the user to be able to choose parts of themes.)

The following are pretty generic, but apply here.

If an improvement to the system is made that requires a new api, (rather than an extended one) then shouldn’t the plan be as RISC OS progresses:

1. New api and old both supported by ROM.
2. Old API is in a separate module in ROM that can be killed.
3. Old API is in a module in the !Boot sequence. loaded by default. choice in configure
4. Old API is in a module in !Boot, not loaded by default, choice in configure, old apps would be modified to rmensure it
5. Old API is dropped, but module (and configure option) can still be added for old programs

(1 & 2 might be the same) Given the software situation, many changes would be expected to only reach 2 or 3

If an improvement is made that breaks some apps that aren’t written correctly, (or are written not expecting changes) then a work around module should be supplied in boot, controlled by configure.

(This is drifting off topic, but there should be an in depth backwards compatibility section in configure, where support for old apis, old processor modes, system protection etc. can be turned on and off.)

but there should be an in depth backwards compatibility section in configure, where support for old apis, old processor modes, system protection etc. can be turned on and off.

Given that the Wimp ought to still be able to run Arthur applications (!), and can still downgrade to drawing in VDUtext (etc), backwards compatibility should be maintained insofar as it is possible without strangling advancement.

This is one of the issues concerning (re)development of the internationalisation system. The basic premise is sound, but the way it is implemented…well…y’all know my thoughts on Territory. ;-) Problem is, while certain of us might be able to come up with a great API for a new system, it isn’t worth a single baked bean if there is no sort of compatibility layer for all of the existent applications using the current API.

Just my 1 pence as regards text on the iconbar. I think there are a few Applications that don’t need text (ram disc,Apps,Discs – i.e. shared discs icon, memphis) as in those cases there can only ever be one instance of them. The USB discs, SCSI, CD, omni/LanMan icons there are multiple and it makes it really easy to see what is what.
Also for some of the applications I’m writing it’s nice to have a status indication (other than an icon) e.g. Idle,Downloading etc.
The grouping on windows drives me crazy, but there again finding windows in RISC OS drives me crazy when I have 20 or so filer windows open and 5 or 6 source files open, which gives me an idea.
I’ll open a thread for that idea….

backwards compatibility should be maintained insofar as it is possible without strangling advancement.

My suggestion wasn’t that it shouldn’t be. More about where it should live.

Initially in the ROM (with the ability to disable it.)
Then as it becomes standard in new apps, in the boot sequence. When the majority of regularly used apps support it, it is still supplied on the default image, but not enabled at boot. Requiring the apps to have an rmensure line added, or the user to tick the box in configure.

When it becomes a historical rarity, then the module would cease to be supplied in the boot sequence, but supplied separately (packman or downloaded manually). For this situation to occur, RISC OS would have to enjoy run away success,I think, so is more for completeness than an expectation.