Flat gadgets

I installed windows 8 the other day and its the first time I’ve installed an operating system that made me laugh out loud. The window furniture is totally plain flat rectangles, it looks brilliant (never been a pseudo 3d fan and been constantly on the lookout for decent toolsprites), and I immediately thought of the original RISC OS toolsprites which everyone wants rid of in the rom.

So I fired up RPCemu and disabled any changes in toolsprites in !boot only to find that the rom toolsprites are no longer flat – another funny moment in my eyes the toolsprites get changed and the old ones come back into fashion. Anyway having now found the old toolsprites in !themes and have windows and RISC OS looking very similar. It appears that windows will turn into RISC OS before RISCO OS turns into windows :-)

Anyway I’m back on the original toolsprites and was wondering if anything had changed to make it easier to remove the pseudo 3d in the dboxes/gadgets – a flat button would be a good start.

My vote goes to reintate the original toolsprites in rom – maybe with the lines around the buttons removed :-)

Regarding PMT multitasking and riscos I think Windows 8 shows how it could work. It seems to me that in windows 8 you have a tablet OS and windows 7 is just an app in that OS. I think a PMT/multiprocessor RISC OS would have to work the same way with the current OS running independently of new PMT environment apps.

The “PMT environment in CMT OS” approach has actually already been done, on RISC OS. (Wimp2, for the record.)

But, there’s more benefits to the opposite approach, implemented correctly, and it has the same limitations on the PMT programs. I’d read through all of this thread, to understand what’s been talked about with PMT (the thread topic is multicore CPUs, which is slightly different, but many of the challenges are the same, and many of the approaches for implementing multicore support add PMT).

(Also, Windows 8 just looks like it’s Win7 running inside the tablet OS. It’s actually the other way around, implemented through clever graphics tricks.)

I never tried it but didn’t wimp2 try to PMT existing programs and use existing OS commands? I mean run the current RISC OS in its own environment and new programs in a different environment.

Windows 8 may well be as you say – they obviously wouldn’t rewrite it from scratch -but that doesn’t matter, How it feels does in this context. I have read the thread and don’t see how the current wimp programs can possible work in a PMT environment. But I dare say some genius will work it out.

In the meantime talk of changing the RO to pmt discourages development as it may be a wasted effort IMHO.

My vote goes to reintate the original toolsprites in rom – maybe with the lines around the buttons removed :-)

I think a proper theme manager is the answer.

From what I have read, removing the CMT environment in RISC OS would seem a very bad idea. (The ability to get that much control over the system is a bonus for some uses, and we don’t want to break loads of apps). I would like to see PMT available to new programs, but the existing CMT overiding it. (Like wimp2). You use new stuff and it is all smooth, use old stuff and it stalls like at present. (But the things that cause the stalls are the things likely to get moved to the new API anyway.)

Wimp2 provided a PMT environment as a CMT task. It worked quite well as I remember, and Steffen Huber seemed to rate it in previous comments. The big flaw in the system was it tried to patch existing programs to use its PMT, which probably gave it a bad reputation.

I’m not sure it had a bad reputation, but it wasn’t finished. In particular there was a bug regarding handling of null polls that would regularly break BASIC programs.

For reasons too tedious to go into, Wimp2 could deliver a null poll from a Wimp_Poll that had specifically masked out nulls. In a compiled language that probably isn’t going to cause a problem, but for BASIC programs it often produced a “No such variable” error, and as it would do so for every null poll, results were “disappointing”.

Other than that, and the fact that it could do nothing regarding the granularity of OS SWI calls (file, sprite, etc), it was a compelling proof of concept and could have pointed the way to a Windows3-style route to PMT (ie one CMT thread filtering and routing messages to multiple PMT threads – Wimp2’s ‘Message filter’ was the CMT thread in effect).

<troll class=“obvious”>

Regarding PMT multitasking and riscos I think Windows 8 shows how it could work.

Isn’t Windows 8 actually a new CMT wrapper around a PMT environment?

As for the we-must-look-different-to-the-opposition graphic design of Windows8, it is a passing fad as Aero and Luna were before it, and it is one that is specifically designed for the Fat Finger Syndrome of touchscreens.

In particular, the coloured backgrounds are a reaction to Microsoft’s previous misdesign of removing the borders from buttons – that’s acceptable if the extent of the button is unambiguously shown when ‘hovering’ (though you have to find where to hover by trial and error), but you can’t hover with a touchscreen.

So, what goes around, comes around. RISC OS, with its definite button borders and frankly huge and chunky scale is already fairly suited to the FFS. Unfortunately, one needs specifically designed ‘one finger interface’ software or multitouch (with on-screen menu and adjust modifier ‘shifts’) to use existing software.

Keep in mind that I’m not advocating PMTing existing individual programs. That’s not at all practical, Microsoft and Apple went a different route.

I don’t recall the details of how Win95 handled things, but IIRC it was CMT inside PMT in some way.

Mac OS 8.6 and 9.x had a PMT microkernel running everything, and everything running inside the CMT environment (including the GUI) was a SINGLE PMT thread. Every user-facing process was a CMT task (but could spin off PMT threads as needed), and anything that wasn’t thread-safe was restricted to the CMT thread (so, if you wanted to do something that wasn’t thread-safe, you would call the CMT thread (or just call your parent CMT task to do the call for you)).

What this meant is that the whole system could get the benefits of PMT, not just things running inside the GUI, and it was less likely that a CMT task could bring down the entire system (still possible, though, and it can definitely bring down the GUI – you could freeze while sitting on a thread-unsafe call, and then anything else that needs to make that call will block forever, until that CMT task is killed).

A well-designed Mac OS 8.6/9.x application would have a CMT stub that handled anything that needed to make thread-unsafe calls, including be the GUI front-end to the application, and then spin everything else off into threads using Multiprocessing Services.

As far as Windows 8, it’s fully PMT – processes running in the new GUI have the same status in the kernel as processes running in the old GUI. 32-bit x86 versions have a CMT environment running within them, for 16-bit Windows applications (and it’s much more complex to make thread safety less of an issue), but that thing is essentially deprecated, and hasn’t been relevant for a decade or more. As far as user interface goes, it’s simply a new GUI sitting on top of the old GUI (with some graphical tricks to make the old GUI look like an application within the new one).