New user advice

I have just started using RiscOS and I love alomost everything about it.

But my cynic side says: Is it relevant.

So convince me, why should I use RiscOS?

I love alomost everything about it.

Haven’t you just answered your own question?

See also https://youtu.be/YFFAwtkLbCM

RiscOS….Is it relevant.

Depends pretty much what you want to do. If you want to spend your life watching YouTube videos, you won’t get very far with RISC OS; on the other hand, it is possible to use it as your main computing platform providing you don’t mind switching to a more mainstream OS for the bits that RISC OS can’t do or is not very good at. I’m aware this sounds a bit downbeat, but it isn’t meant to – this is still IMHO one of the nicest, if not the nicest, OS to do any kind of graphics work, for instance, because it is fast and doesn’t get in your way. I find Artworks and OvationPro nicer and easier to use than any MacOS or Windows equivalent I’ve tried. There is a wealth of small apps like GraphDraw, Thump, DPingScan, SyncDiscs, Memphis, SparkFS and Calibre which add useful functionality. Simple programs can easily be written using the built-in BASIC. CloudFS enables access to cloud storage. You can actually buy and keep commercial apps, and move them easily from machine to machine: you won’t be locked into the kind of monthly rental system that seems to be the norm for Windows Office, for example: in this respect, being behind the fashion feels positively advantageous.
I started using RISC OS in 1992 and it is still my main daily OS – ’nuff said?

Edit: I should also add, you’ll have the support of an exceptionally friendly and expert user community, which has saved my bacon on innumerable occasions over the years!

I use Raspbian for browsing, with Chrome. But for practically everything else, including email, I use RISC OS. I have not come across anything better than StrongED as a text-editor on any platform.

The fact that RISC OS uses cooperative, not preemptive, multitasking makes for a much more agreeable user experience IMHO, because the response to user input is immediate.

It is worth understanding about filetypes, about Obey$Dir, and how an application’s !Boot, !Run and !Help files work. They enable you to have a filing system that suits your ideas of where things should go, rather than those of somebody else.

On the other hand, it is possible to use it as your main computing platform providing you don’t mind switching to a more mainstream OS for the bits that RISC OS can’t do or is not very good at.

No need to switch ….

Just open a window to a another device. I use !RDPclient to use a Windoze PC and !Avalanche (VNC) to use Linux. All on the RISCOS desktop and you can cut and paste between them :)

Just open a window to a another device.

Can you do that with a Mac running El Capitan or Sierra, too, somehow? Switching the monitor is no bother (a click on the remote does it) but having two keyboards and mice is more hassle (although I do like the Mac’s trackpad, and wish I could use it with the Pi…)

having two keyboards and mice is more hassle

One way to avoid that is to use a KVM switch (the nice people in Worthing who always ‘have everything in stock’(!) will help you with that), which is my solution. One advantage over VNC is you get a full-size desktop on both machines, but I agree, the VNC solution is the neatest.

I used to use a KVM switch when I used a PC and a RiscPC – it’s still around somewhere. But there’s that nice trackpad, and the Mac (wireless) keyboard is a lot better than the clunky cheap one the Pi seems to like.

It’s survivable…I should update my deak photo to put both keyboards, the mouse and the trackpad in the picture…but then, it would be nice to be able to split-screen and have the Mac desktop and the RISCOS desktop side by side as an alternative to switching between them…but it’s survivable as is.

The fact that RISC OS uses cooperative, not preemptive, multitasking makes for a much more agreeable user experience IMHO, because the response to user input is immediate.

Has this ever actually been true? RISC OS certainly doesn’t give an “immediate” response when an application blocks for even half a second but fails to put up the Hourglass.

In contrast, one usually gets an instant response out of Linux – even if that response is just the system making it clear that “We saw your click, but Firefox isn’t responding at the moment – please wait”.

One way to avoid that is to use a KVM switch

Do recent versions of the USB stack get on well with KVMs? I’ve always used one, with a RiscPC, then Iyonix and now various Beagleboards, but trying to switch a Titanium using the StarTech KVM that seems otherwise bulletproof just causes the system’s USB to crash out. That’s still the case with RISC OS 5.24.

trying to switch a Titanium using the StarTech KVM that seems otherwise bulletproof just causes the system’s USB to crash out.

Yes. I have found I cannot use a KVM switch with a Titanium. KVM has always been fine from Iyonix through all native hardware up to IGEPv5, but the Titanium is a problem. It has been reported.

Yes. I have found I cannot use a KVM switch with a Titanium. KVM has always been fine from Iyonix through all native hardware up to IGEPv5, but the Titanium is a problem.

Thanks – it’s useful to know that it isn’t unique to this setup. It’s a shame, because otherwise the system now seems pretty stable. Sadly, switching keyboard and mouse to use it is a disincentive to make it the primary RISC OS machine when just pressing a button on the KVM is so much easier.

It has been reported.

Likewise.

I have found I cannot use a KVM switch with a Titanium.

An eclectic mix of bits works well with my Titanium. The KVM is an STD supplied MYhopper KMH4 PS2/VGA job, used KM only into the Titanium. A USB keyboard and USB wireless mouse connect to the KVM via USB to PS2 adapters, with Y-lead PS2 to USB adapters to the Titanium, RPi3B+ and Iyonix.

Otherwise I would concur with previous comments, the Titanium’s USB can be an issue.

Oh – yes – my KVM switch didn’t do USB at all. PS2 connections…

In contrast, one usually gets an instant response out of Linux – even if that response is just the system making it clear that “We saw your click, but Firefox isn’t responding at the moment – please wait”.

Linux and Windows both – you should prefix your comment with “if you get a response at all…” and modify with “and the click may be queued and delivered with the positional data for the pointer at the time the queued click is delivered”
I don’t think I’ve ever seen RO do that trick.

Steve said:

RISC OS certainly doesn’t give an “immediate” response when an application blocks for even half a second but fails to put up the Hourglass.

The default Hourglass_On behaviour is to switch on after a short delay (1/3s), to avoid flickering the pointer over titchy delays. If you know you’re going to be busy for a significant amount of time, one can switch on the hourglass instantly with Hourglass_Start.

when an application blocks for even half a second but fails to put up the Hourglass.

As nemo mentions, there is a delay before the hourglass appears. This is so software can turn it on and off, and it will only actually appear if the system stalls for more than a third of a second. That applications don’t show an hourglass while they time up the machine is not a fault of the OS.

In contrast, one usually gets an instant response out of Linux

I can’t speak for Linux as I rarely use it (and my forays with Ubuntu were not positive); however I was quite used to Windows 98SE icon clicks doing nothing for a moment, plus being able to move the mouse to where the dialogue will appear awaiting the click.
Windows XP took this to new heights by splitting the message box code into a UI part and a sound part. Quite frequently even now on a 2.8GHz box I have been able to do something, dismiss the prompt, and then the “ding!” happens. It’s quite distracting.
Also there can be serious lag when doing the first of something, such as writing text and then using a hotkey to switch to italics, then keep on typing and the machine will catch up a few seconds later.
I would imagine this happens to Linux to a degree too; and is part of the fact that tasks are only partially paged in, so doing an action that hasn’t been done before may require something to be paged out to make space for that bit of the program to be paged in (which may happen a few times until all the bits necessary have been loaded). Remember, unlike RISC OS the others swap out to disc which is inherently slower.

Another problem I see from time to time is that my XP box more or less freezes up for a time (may be 5s, may be a minute) with the HDD lamp on solidly. Running Process Explorer doesn’t indicate anything using all of the processor time. Rather, this time simply ceases to exist (the activity counter stalls, then resumes as if the stall never happened). I’m guessing XP is doing some low level messing around with its paging file or something, but to just block the entire machine like that with no indication of why, not exactly user friendly.
My box has something like 1280MB onboard. It really ought to have more but it’s done weirdo Intel chipset that needs some special kind of DIMM rather than the normal dirt cheap kind you can get anywhere. I do have, in the shed, a slightly later model and the memory modules in that aren’t the same! Great…

Anyway, ignoring applications blocking the machine, on RISC OS it is pretty much always the case that clicking an icon has an effect. You aren’t left hanging wondering if the click was even noticed by the machine. How many dupe postings here do you imagine have been as a result of clicking on the Post button, waiting, waiting, then trying again, then finding two messages got posted…? I know it’s happened to me…

one can switch on the hourglass instantly with Hourglass_Start.

Not so.
A delay of zero blocks the hourglass off, so the smallest value possible is 1, for a delay of 1 centisecond before the hourglass appears.
Way better than a third of a second, but not instantly (in bold and all). ☺️

https://www.riscosopen.org/wiki/documentation/show/Hourglass_Start

The default Hourglass_On behaviour is to switch on after a short delay (1/3s), to avoid flickering the pointer over titchy delays.

Assuming that the application in question knows that it’s going to block the multitasking, and the author remembers to call the Hourglass module, and…

Remember, unlike RISC OS the others swap out to disc which is inherently slower.

The others, unlike RISC OS, can also handle much bigger applications and data sets.

Anyway, ignoring applications blocking the machine, […]

So, if we ignore the problem that we’re talking about… Yes, I can see how that would help RISC OS in the comparison… :-)

[…] on RISC OS it is pretty much always the case that clicking an icon has an effect.

…if we ignore the occasions when it doesn’t.

Like yesterday, when the RO box here locked up for 10 seconds or so precisely every 30 seconds (on 20 and 50 seconds past on Organizer’s clock). Mouse still moved; no other interaction and no hourglass… A reboot was eventually required.

So, if we ignore the problem that we’re talking about…

The big difference being that an application stalling the machine is arguably an application fault (no hourglass or insufficient/no polling, etc). When tasks are running smoothly (as is the normal state), responses are immediate to user input. You press F12 you get a command line. Right away.

The design of Windows (XP, as that’s the one I’m familiar with) means that all too often this is not the case. And it isn’t a lack of responsiveness due to faulty applications, it’s the OS itself causing the lag. If you’re running Firefox and you have a bunch of tabs, clicking Start will have a noticeable lag before the menu opens (as Windows pages in the start button stuff). Click on command line (it’s in the base menu on my XP as I use it a lot) and there’s a delay as more disc chugging happens and eventually the console in a window starts.

Now press Ctrl-F12 and see if you can count the seconds before TaskWindow opens even if you need to load Zap first and I think you’ll find it’s a number approximating zero. RISC OS, in normal use, is just responsive. Click icons, press keys, stuff happens now, not when the OS is good and ready to deal with it.

A reboot was eventually required.

Did you find out what was causing the problem? I’ve never had my machine lock up for 10 secs every 30, and given that RISC OS doesn’t preempt, that would drive me nuts so I’d want to know what was causing it…
Did you try Alt-Break to kill the task that was current at the time of locking up?

Do recent versions of the USB stack get on well with KVMs? I’ve always used one, with a RiscPC, then Iyonix and now various Beagleboards, but trying to switch a Titanium using the StarTech KVM that seems otherwise bulletproof just causes the system’s USB to crash out. That’s still the case with RISC OS 5.24.

The multimedia buttons on the pi-top caused a similar issue until I wrote a driver Module to handle them, I suspect the KVM is sending data that RISCOS doesn’t know how to deal with, which ends up blocking the USB stack.

Print the data coming from the keyboard USB Device to screen (example code in this post), then plug the KVM in and switch inputs to see what data it’s sending. Once you know what it’s sending its a case of handling it in a keyboard driver. The source for my pi-top utilities Module is available, so could be stripped back and modified to fix the issue.

The multimedia buttons on the pi-top caused a similar issue

Does your module deal with multimedia keys using regular key codes, or multimedia keys using the extended HID interface?

I tried your test program on my keyboard (has a Power / Sleep / Wake Up key triplet) and there was no data sent at all. Another keyboard (with many more keys) and no data sent.
nemo mentioned some suitable key codes ages ago, but since these comes from a different endpoint/stream/protocol than regular keypresses, it seems that the standard keyboard driver just can’t see them.

I was just wondering, therefore, if your module might help or if you have any plans for extending it in this direction?

[I don’t use !HID, I’ve found it … quite unstable]

A delay of zero blocks the hourglass off, so the smallest value possible is 1, for a delay of 1 centisecond before the hourglass appears.

Well actually you’re right that this isn’t ‘instant’, I doff my cap.

What it actually does is allow the TickerV claimant to switch on the hourglass the next instant it is called. So the actual delay must be less than 1cs and on average will be 0.5cs – or 65 times faster than Hourglass_On.

Clearer? ;-)

Does your module deal with multimedia keys using regular key codes, or multimedia keys using the extended HID interface?

Multimedia keys are HID and the cause of the issue as RISCOS doesn’t know how to deal with them. As a consequence the buffer isn’t cleared down, blocking further USB data. I don’t believe regular keys will cause the issue, they’re just ignored by RISCOS.

I tried your test program on my keyboard

Probably a daft question, but did you modify the HID interface string to your keyboards HID interface? It was written for the pi-top, so won’t work as-is.