BatMgr icon location

RISC OS is essentially backwards compared with the Windows task bar: start menu far left (=> Task Manager far right) and devices in the system tray far right (=> devices on the left). Hmm.

As the setup that had that iconbar layout first RO is one way and Windows is backwards.

That said I suppose for much of this the question is whether we want to continue to confuse visiting PeeCee users, if not then both wifi and battery status are on the right.

is whether we want to continue to confuse visiting PeeCee users,

RISC OS has so many ridiculously enormous differences that moving some icons isn’t really going to change much…

RISC OS has so many ridiculously enormous

beneficial

differences that moving some icons isn’t really going to change much…

So when wifi comes to RSIC OS where would you place the icon?

As it’s not file system related, and it will be an application that is loaded to deal with wi-fi, it should sit on the right of the iconbar.
Probably where Printers should be as well, but let’s not go there. :-)

I wonder if subliminally people expect the battery on the right because that’s where the Windows system tray is, so on my Dell laptop the battery is on the right.

Not here! I/O (Filesystems, printers, scanners on the left). Status stuff on the right.

I expect most folk that haven’t seen other I/O apps on the left assume it’s file systems to the left and applications to the right. !Printers being the oddity that a lot of folk have probably never seen, I used it for the first time ever a few months ago to print a PDF and thought “why is it on the left?”

Clearly the only way to settle this left/right controversy is a highly divisive and inconclusive referendum and a generation of bitter finger pointing and bile.

Or we could make it configurable.

Or we could make it configurable.

you aint from around these parts are you? We don’t want those sort of free thinkers round here! ;-)

a highly divisive and inconclusive referendum

…in which a bunch of people are arbitrarily denied the ability to vote, and everybody just makes up their reasons and excuses along the way (putting printers on the right will cause every printer on the planet to stop working…).

I like that plan. Let’s do it.

Having just looked at the documentation of the negative “window handle” (location) in the icon block and the “priority” in R0 I realise I can’t predict what any particular combination is likely to do, beyond the most trivial and common example.

As I’m not entirely thick I suspect that most apps do something trivial too… so it may be as simple as paying attention to only the top 8 bits of the priority plus the location (which is 3 bits) and allowing those to be remapped, keeping the low 24bits of priority.

I’m all for nostalgia (though it’s not as good as it used to be), but it’s VERY difficult to explain why a scanner ought to be on the left but an image-searching browser naturally sits on the right. When I had an EPROM programmer it sat on the right… would anyone expect that to have been on the left? I thought not.

I think, regardless of original intent, most users see things on the left as ‘places’ and things on the right as ‘doings’. !Printers gets away with it as one very rarely does anything with it, it just sits there like a badge – “Yes! You can print!”… plus you can drag things onto it, which you can also do with recent filer icons (although not originally intended). But you can drag things onto text editors… meh.

RISC OS doesn’t have a ‘systray’ but if it did, !Printers would be there instead. The filers wouldn’t.

Such a divisive topic. I’m impressed!

Jon Abbot said:

Right, move Printers to the right as well. Irrespective of what the style guide said nearly 30 years ago, the left is irrevocably associated with storage.

I think you’ll find that Printers has been on the left for 30-odd years as well. Just because printers aren’t as commonplace as they once were, it doesn’t mean that the app should lose its right to appear on the left of the icon bar (unless we do actually change the style guide).

Also, surely a printer counts as a write-only filing system? ;-)

Sprow said:

RISC OS is essentially backwards compared with the Windows task bar: start menu far left (=> Task Manager far right) and devices in the system tray far right (=> devices on the left). Hmm.

Which isn’t really true. The Windows start menu and the RISC OS Apps icon are both primarily used for the same purpose (selecting an app from a list and launching it), and they both appear on the left of the bar.

Similarly, the Windows file explorer and RISC OS filing system icons are both primarily used for browsing your filing system, and they both appear on the left.

nemo said:

it’s VERY difficult to explain why a scanner ought to be on the left but an image-searching browser naturally sits on the right.

Which is most likely the fault of the Style Guide (and the User Guide?) for not explaining things clearly enough (or using overly-complex rules to begin with).

I think the ruleset which my brain has derived can be boiled down to the following:

• Permanent stuff on the left
• Temporary stuff on the right

I.e. if I restart my computer, the left hand side of the icon bar will look pretty much the same as it did before the restart, while the right hand side will be empty.

• If you want to load a file, you need to take it from the left of the icon bar (filer, scanner, etc.) to the right (to an editor / viewer app)
• If you want to save a file, you need to take it from the right of the icon bar (editor / viewer app) to the left (filer, printer, etc.)

Things get a bit muddy when you take into account any apps that you’ve configured to run on startup (since they’ll clearly be there if you restart your computer), but any work which you had open in those apps will probably have been lost, so there’s still a temporary nature at heart. Plus of course there are oddities like the display manager – it represents a physical device, so the style guide suggests it should be on the left, but any settings you make are temporary, so brain-logic suggests the right side could be correct.

• If you want to add or remove something from the left of the icon bar, you typically have to plug / unplug a physical device (the obvious exception being stuff like Printers, for which you could simply load/unload the app). Sometimes you have to turn off the computer in order to make this modification (internal drives, podules, etc.)
• If you want to add or remove something from the right of the icon bar, you can do so entirely from the RISC OS desktop (except for stuff which aren’t intended to be killed, like the display manager or task manager)

But in general, things which are on the left can’t be removed via a ‘Quit’ option on their menu, whereas things on the right can.

!Alarm is an interesting one to consider. It represents a physical device, and the time (normally) won’t be lost if you restart your computer. Although you can set alarms and then forget to save them, that’s a fairly uncommon use-case – usually you’d just leave Alarm running with your alarms preconfigured for the next N weeks/months. Which makes it sound like it should belong on the left as well.

You remember me saying “difficult”?

if I restart my computer, the left hand side of the icon bar will look pretty much the same as it did before the restart

Then Printers won’t be there.

things which are on the left can’t be removed via a ‘Quit’ option on their menu

Then Printers shouldn’t be there.

whereas things on the right can [be removed via Quit]

Task Manager and Display Manager beg to differ.

Also, surely a printer counts as a write-only filing system? ;-)

Ho ho, no.

!Alarm is an interesting one to consider. It represents a physical device

No it doesn’t.

Permanent stuff on the left

Access would like to quibble about your definition of “permanent”.

I’m going to return to the defined example of a scanner icon. Normally one would scan from an image processing or painting program, whose icon is on the right. This is a program which produces an image in a window which one then needs to save to disc.

However, if one clicked on the “scanner” icon one would expect it to produce an image in a window which one then needs to save to disc.

Does the scanner icon have to be on the left because it is not an editor? Does an editor that uses TWAIN have to appear on the left? Does PrinterSP (the print-to-sprite driver) have to be on the right because it opens a save window after printing? What about PrinterPS printing to file with no physical printer present – on the right, still on the left? What about a BBC Micro emulator… is its “hardware” any less real than a printer driver printing to file?

“Places” on the left, “doings” on the right.

My IconMover module allows the user to drag any icon anywhere on the iconbar, so there’s always that.

Such a divisive topic. I’m impressed!

Vive la Révolution 😂

You remember me saying “difficult”?

Yes, I even quoted that part of your message.

I’m going to return to the defined example of a scanner icon.

Assuming we’re living in a world of plug-and-play drivers, my logic says that the scanner should be on the left, because if you restart your computer the icon will still be there. The only way to stop the icon appearing would be to turn off/unplug the scanner or stop the driver from being loaded.

“Places” on the left, “doings” on the right.

So by your logic, is a scanner a “place” or a “do”? To me it sounds like it’s both (it’s a physical place where you put documents to be scanned, and it’s a piece of software which allows you to do the scanning). Just like a disc drive icon is a physical place where data is stored, but also a software filing system to allow you to access and manage that data.

So by your logic, is a scanner a “place” or a “do”?

I think it’s almost indistinguishable from !PhotoDesk.

As for !Printers, I’ve knocked up a module that allows icon position to be overridden (it would be trivial to edit the Printers !RunImage, but this is done via Wimp_Extend SWI intercept). And I have to confess it’s strange having Printers on the right. I tried dragging it about too:

https://video.twimg.com/tweet_video/DVcyTyNWsAEOVGV.mp4

But in general, things which are on the left can’t be removed via a ‘Quit’ option on their menu, whereas things on the right can.

Uh… RamFS can be quit. On the right with it… ;-)

Far simpler to say that apart from historical anomalies, it’s generally “files and such on the left” while “applications on the right”.

my logic says that the scanner should be on the left, because if you restart your computer the icon will still be there.

Really? I’d have thought it should be loaded as required. SparkFS is extremely useful, and is pretty much always on my iconbar, but it isn’t loaded by default.

But, then, if a scanner driver should go on the left, shouldn’t Hearsay as well? After all, it’s a serial port interface program, so that’s hardware…?

What nemo says: “Places” on the left, “doings” on the right. (with some anomalies, but then maybe outputting to a printer is a “place”, while changing screen mode is definitely a “doing”)

Also, surely a printer counts as a write-only filing system? ;-)

Damn. Beaten to it – I was going to suggest printing is storing stuff on paper.

But… printers aren’t necessarily write only if they’re multi-function devices. The read function may be a bit lossy compared to the write, admittedly. :p

Also I can write to/read from an SD card in my printer at the office.

This hinges on what is meant by “device”. RISC OS can use “device” as jargon to mean something handling files, which might be an over simplification, such as null: or printer: and filing systems.

The term used in the PRMs is “System devices”. In the DDE28 PDFs see pages 2-20 and 2-495.

printer: is listed as a System device.

printer: is listed as a System device

Yeah, so is vdu:. I wish we lived in a world where every word of the PRMs was strictly and accurately defined.

But we don’t.

But we don’t.

If there should ever be a revised PRM, could we please ditch the annoyance that is “This call is for internal use only and stupid peons like you are not worthy of knowing this call exists, never mind using it”.
Such a thing should never have been in a technical document of the level of detail of the PRMs in the first place…

If there should ever be a revised PRM, could we please ditch the annoyance that is “This call is for internal use only"

I think it needs rewording to indicate that the call is for use by integral OS modules only and should not be relied upon to be available to user applications/utilities.
Most OS documentation across many platforms will note that although a particular system call/hook may exist it may be subject to change at any time – roughly translated as “if you use it and then we change it and break your stuff then that’s just tough, suck it up”

Most OS documentation across many platforms will note…

Hear, hear.

My favourite part of the RISC OS API is that concerning the Scratch Space at &4000 which, if memory serves, “should not be used unless you know you can”.

TBH that proviso should be attached to every API in this OS.

If there should ever be a revised PRM, could we please ditch the annoyance that is “This call is for internal use only and stupid peons like you are not worthy of knowing this call exists, never mind using it”.

No, Rick. The statement acknowledges that the SWI exists, that the writers have not simply forgotten to document it, and is a clear prohibition on its use by user programmes.

It is an entirely correct thing to do.

It is an entirely correct thing to do.

In the case of RISC OS it isn’t correct at all. As an open source OS, there should not be undocumented calls, everything should be fully documented with the disclaimer that certain calls are for OS integrated Modules only.

For example, if someone wanted to implement say a type 2 Hypervisor and needed to hook into AMBControl to switch VM’s, how would they do that without it being documented? Or if someone wanted to completely rewrite a section of undocumented OS into C?

CDFS is another fine example that should have been documented long ago, I hate to think how many hours I spent looking through source code trying to figure out how some calls worked. There’s been a few other undocumented features of well known calls that are mentioned in the source code, but undocumented so far as the PRM’s go.

What Jon said.

When the entire code is available and can be read, refusing to document certain calls as they are “something internal” is little more than purile childishness, a mentality from when RISC OS was closed. It is also the height of inconsistency, for Dave said:

on its use by user programmes

This being a set of documents running to thousands of pages that tell you how to write FIQ code, filing systems, and hijack all manner of events and ServiceCalls to be capable of changing the behaviour of the OS. It’s fine to do all of these things, but certain SWIs are sacrosanct – things which should not be spoken of? Is it too hard to document the calls along with a note on their nature? That makes no sense normally, and negative sense when we’re talking about a system that is in need of attracting developers.