TaskWindow could do with some improvement

It’s weird that there’s a call to claim ownership of the screen palette (Message_DeviceClaim,3), but not the whole screen.

It’s weird that there’s an OS call to read the mouse position and button status (OS_Mouse) but there’s no matching means to write the same parameters.
Just to rub salt in the wound you can get the same info as a data block instead of data passed in registers Wimp_GetPointerInfo and yet again no matching write.

I think most people could put together an extensive list quite quickly.

I will quote a wiser person than me “It’s missing functionality.”

I think most people could put together an extensive list quite quickly.

Oh yes.

Question is – if ten people made a list, would there be overlap or just a large number of irritations?

Question is – if ten people made a list, would there be overlap or just a large number of irritations?

Two questions for you

1. What is your top ten niggles about missing quick calls into whatever
2. How many of the things you’d like are sometimes easier because you now have the source and it’s just a tweak instead of re-inventing the wheel but then some become a pain again because someone has done an insane mess of %FT10 and cousins.

What is your top ten niggles about missing quick calls into whatever

My big two, enough to be getting on with, are:

• Keyboard handling – nominally a mess of OS_Byte calls to present an API unable to distinguish certain keys from each other, not to mention difficulty with any method of using Unicode because function keys (leading to the current Wimp method of multiple keypress events to send UTF-8 byte by byte).
• There are various calls to read VDU attributes that lack equivalent calls to set them, instead requiring incantations to be sent to the VDU directly. Let’s not even discuss VDU23….

now have the source and it’s just a tweak

Depends upon the thing. Right click switcher to config, boost IIC speed, etc – yes those are source tweaks. But some stuff I’d like would require a new API (and everybody else to be using such).

Keyboard handling – nominally a mess -of OS_Byte calls to present an API unable to distinguish certain keys from each other, not to mention difficulty with any method of using Unicode because function keys.

Some add-ons actually utilised¹ the International Keyboard elements and generated new keyboard maps in order to use some relatively simple key combinations. Others did things a little differently like DeepKeys

There are various calls to read VDU attributes that lack equivalent calls to set them

Read but not set, you see you are but a user and of no great importance unless you know the mystic incantations.

¹ Past tense because they tend to be 26bit.

Keyboard handling

Ahem Deepkeys ahem.

leading to the current Wimp method of multiple keypress events to send UTF-8 byte by byte

UTF-8 is always sent byte-by-byte. :-)

Amusingly, the Wimp uses an internal UCS-32 format when operating in UTF-8 mode, so it’s forever transcoding back and forth between the two. I’m sure you would want that exposed via Wimp_Poll if you’d Initialised with an appropriate version number, but that would require fixing the keypress queuing code which, oh yes, I did just the other day… and absolutely no one was even slightly interested.

However, the reality of RISC OS’s patchwork nature is that it is impossible to work entirely in UCS-32 – it’s too ambiguous. For example, a program might do the equivalent of FX 138,0,163 confident that it will enter a £ at the cursor, but another program may do VDU23,163,189,126,219,255,126,195,102,0 so that its PRINTCHR$(160); produces an even more terrifying plummeting icon. You can tell them apart in UTF-8, you can’t if it’s 32bit.

You can arrange for something else to do the translation to and from a 32bit representation, but that has to be through separate interfaces – WrchV, InsV, RemV etc HAVE to stay resolutely non-UCS-32.

UTF-8 does make some things (a little) more work… but the hard reality is that Unicode makes things a lot more work, and if people can’t cope with the first bit they’re definitely not going to do the second.

Ahem Deepkeys ahem.

A third party module to patch deficiencies in the OS.

Now that source is available, I’m awaiting the crowds of code warriors to ride in upon their pretty multicoloured unicorns to help fix the stuff that’s been varying degrees of facepalm for decades.
Shall I hold my breath?

UTF-8 is always sent byte-by-byte. :-)

But not as separate keypress events!

so it’s forever transcoding back and forth between the two

Just like VB5/VB6 (UTF16 internally, calls ANSI API, WTF?).

but that would require fixing the keypress queuing code which, oh yes, I did just the other day… and absolutely no one was even slightly interested.

I must have missed that. Did you submit a patch?

and if people can’t cope with the first bit they’re definitely not going to do the second.

Do you remember the other day I wrote Wapuro Romaji with the macrons over the letters?

Okay. I used MoreKeys to get access to the characters, but…

Write some of the message.
Load MoreKeys
Command line → *Alphabet UTF8
Use MoreKeys (!Chars, etc etc) to select desired character.
Command line → *Alphabet Latin1
Keep on writing.

It’s ridiculous that keyboard handling in the Wimp is so broken that you can’t send a character code that you know the app can cope with without switching alphabet to be able to send it.

Or maybe… It’s ridiculous that text handling in the Wimp is so broken that you can’t just set the system to UTF-8 and have the Wimp do something sensible for older apps.

Because unfortunately UTF-8 and Latin1 are about as compatible as IPv4 and IPv6 once you leave basic English characters. But, wait, that’s another argument too. ;-)

UTF-8 does make some things (a little) more work…

I’d settle for UTF-8. I don’t expect miracles.

that would require fixing the keypress queuing code which, oh yes, I did just the other day… and absolutely no one was even slightly interested.

Quite a few people are interested in such things, but it’s sometimes difficult to track.

I think you need to put together a diary noting what was fixed or added when.
Would half day slots suffice or does it need refining to hourly updates? ¹ :)
Then one of us could remind you at, say weekly, intervals to send the patch code to ROOL

¹ Nemo standard operating mode = hyper :)

Nemo standard operating mode = hyper :)

Am I allowed to ask……what’s the status of the BASIC assembler?

Then one of us could remind you

Not me – I’m losing track of it all. So many varied things – are we sure nemo isn’t an alias for a group of people?

So many varied things – are we sure nemo isn’t an alias for a group of people?

A front for a group based in a hidden lair deep under the sea. We had no clue…

I always enjoy Rick’s responses because they’re usually only one Planck’s Length from being actually right.

But not as separate keypress events!

Well, ‘keypress’ is <waves arms about>. I have a different view because I wrote DeepKeys partially to enable the use of virtual ‘keys’, that may or may not be generated by an actual button, which may or may not be on something you’d call a keyboard. The ‘scan’ button on a scanner for example. Or conceptual buttons like “Next Album” or “Launch Web Browser” that some users would trigger via their keyboard driver, but others via a USB peripheral (remember the Optimus Maximus keyboard and associated things?).

So I’m not hooked up on that event having to be an atomic character. UTF-8 was designed to go through existing 8-bit interfaces – that’s its entire point.

However, it would be trivial to build a Filter that composed KeyPress events into a single Unicode event, and a Wimp_Extend so that Send_Keypress would accept such a code. Wimp ‘function keys’ and fallback characters would be mapped to the non-Unicode range. (gentle reminder folks: regardless of what’s written in any part of the RO source, Unicode is 21 bit and UTF-8 is never more than four bytes long).

However, all other OS APIs would stay resolutely 8-bit UTF-8, so you’re just moving the transcoding around, which is a bit pointless. The UnicodeSupport module will make life easier for app authors. Let’s see if it’s still painful then.

Just like VB5/VB6 (UTF16 internally

Windows suffers from Early Adopter Syndrome – they jumped in at the “Unicode is 16bit!” start, before the Committee decided “We’re going to need a bigger byte” (I’m here all week folks).

It’s ridiculous that keyboard handling in the Wimp is so broken that you can’t send a character code that you know the app can cope with without switching alphabet to be able to send it.

Wimp Message &5327F “Styled Text” carries a string and a font ‘name’ (and hence an encoding). Wimp_KeyPress delivers characters in the current Alphabet, that’s fine. &5327F is for delivering stuff in some other Alphabet.

have the Wimp do something sensible for older apps.

I’ve been pondering this with regard to the horribly broken clipboard handling. Short version (presented without evidence): RO4 ClipboardHolder is better than RO5 Clipboard; ClipboardHolder is badly designed and needs fixing with a new one that works in a different way; Underlying Clipboard Protocol is badly designed but easy to fix; We can then have a Windows-like clipboard that supports multiple formats simultaneously with auto conversion.

Because unfortunately UTF-8 and Latin1 are about as compatible as IPv4 and IPv6 once you leave basic English characters.

Well, obviously UTF-8 is 100% compatible with Latin1, and all other Acorn alphabets. Even BFont. And to facilitate that…

*HELP FALLBACKALPHABET
==> Help on keyword FallbackAlphabet
*FallbackAlphabet with no parameter displays the currently selected fallback
alphabet, used when programs do not support UTF-8.
*FallbackAlphabet <alphabet>  sets the alphabet to be used by programs that do
not support UTF-8.
*FallbackAlphabet <country>  works out the alphabet to use.
*FallbackAlphabet Auto  inherits the current alphabet for fallback.
*FallbackAlphabet None  disables fallback.
Syntax: *FallbackAlphabet [<alphabet>] | <country> | Auto | None

*

Steve suggested

you need to put together a diary noting what was fixed or added when

I’m embarrassed to report that I actually started doing this a few years ago… and then I forget to update it and what I’ve done, so I wrote a *FindBy utility to list files changed in the last n days, so I could update the diary.

Sometimes I scroll through it and wonder who wrote all the entries, because I have no memory of half of this stuff.

Rick enquired

what’s the status of the BASIC assembler?

Well, I wrote the proof of concept, which I’ve demonstrated. That was an old version of BASIC (because I had it lying around) and a toy assembler module. I started analysing current versions of BASIC and was horrified to discover that the NEON support is well over ten times bigger than all of the rest put together. The only passionate response was “Who cares?” so I’ve wasted no more time. It’s been demonstrated, it works, it has many benefits, no one cares. C’est la vie de RISC OS, n’est pas?

I must have missed that. Did you submit a patch?

I wrote:

And decided in a fit of misplaced altruism to fix it… but on the way
there (in fact trying to find where “there” might be) I stumbled upon the
Wimp_ProcessKey code and recalled that I’d previously complained that the
UTF-8 handling of yore broke ProcessKey in annoying and exciting ways (eg
WPK,&101 works fine, but WPK,&100 sends null to the focused task, and it
also trampled on some of DeepKeys’ functionality)… so I’ve fixed it!

It’s slightly too large to be considered a patch and I did it With The
Actual Source (unusually for me), so I should probably send the diffs to
someone to actually try. Volunteer?

To which I got the usual response.

The RISC OS world is much like some dysfunctional companies I’ve worked with – once a state of affairs has continued for long enough, those that would want it changed have moved on elsewhere, and the only people left either don’t care or just want an easy life or benefit from the dysfunction. The inertia is wearying.

The only passionate response was “Who cares?” so I’ve wasted no more time. It’s been demonstrated, it works, it has many benefits, no one cares.

Actually, I think you’ll find that nobody was that bothered by the size of the NEON code, but there was interest (me for a start) in the possibities provided by the assembler.

To which I got the usual response.

Well I got the impression you might have been talking about NEON support in BASIC, which I’m pretty clueless about.
For other stuff when I’m passing time in my current chair I’m at uhcw.nhs.uk, and sometimes I stop paying attention to mails on that (accessible via iPhone – you’re never off duty) and use my own I might look at the btinternet.com (first name n is longer there).

I know I’m a year late, but…

However, less ambitiously, I wonder if TaskWindow should at least try to simulate a “MODE 3” style environment – no graphics, but a simulated cursor position, screen width etc. The host could inform TW of changes to its window width by a message which, if an older TW was present, would be harmlessly ineffective but which in a new TW would enable the “screen width” and cursor position emulation?

I was a bit more ambitious than that and wrote !GraphTask (http:://www.armclub.org.uk/free) which implements a graphical task window. It captures all VDU output from a taskwindow and plots it in to a sprite, so it supports the old numbered modes, palette changes and all VDU graphics output. So it’s great for old BBC B programs and early Archimedes stuff which uses lower resolution screen modes than modern monitors support.

What it doesn’t support is any graphics using SWIs such as OS_ScreenMode, ColourTrans, Sprite, Font or Draw. I did intend when I wrote it 30 years ago, to extend it to do this by redirecting output to the sprite while the task window task was active, rather than just when processing the VDU stream the task window delivers to the registered handler.