key down / up events to wimp?

Chris asked

Surely the use of characters other than the permitted ASCII A-Z a-z 0-9 and a few others like ‘!’ and ‘.’ in filenames is prohibited.

There are very few characters that are not permitted in filenames – "$%^&*@#. I think. If your alphabet is set to UTF8, then the entire Unicode repertoire (minus those bits of punctuation) is at your disposal.

If they can’t be typed in the command line

Ah, well there’s the rub. And that’s why Rick should have written a keyboard handler. Using an appropriate keyboard handler you can type all those characters at the command line.

Rick persevered with

Said module will have a name

There is no requirement (and has never been any mechanism) to register keyboard handler names. Therefore they may all be called InternationalKeyboard for all you know.

There’s no point flogging a dead horse. You’re doing the wrong thing. I’ve explained why.

Firstly, I live in France. Secondly, it was tested

So you did three tests? Oh I take it all back! Logic and reasoned argument defeated by coin flip. I shall take up another career. You can take the boy out of Aldershot…

Do you know what MoreKeys does?

Yes, and unfortunately I now know how too.

I am sorry it appears to clash with your keyboard driver.

It clashes with all keyboard drivers, and I’m sorry you still can’t see why. Ideally you’d reimplement it the way I suggest, and could even add any keypress the driver buffered to the menu you produce.

Surely the use of characters other than the permitted ASCII A-Z a-z 0-9 and a few others like ‘!’ and ‘.’ in filenames is prohibited.

The world has moved on from DFS. Actually, the Unicode filename was a test to see what it would do on the command line, not a serious use.

However, I have used European accents in filenames since RISC OS 2; and here’s a picture of a file I was transferring from XP to Android; so A-Z,a-z,0-9 and some punctuation is a historical artefact:

nemo and I are (still) arguing about the best way to provide extended characters to applications. He appears to reckon a keyboard handler should do it (a keyboard handler doing API stuff?), I’m hijacking the keyboard until I can get around to making something better…

If they can’t be typed in the command line
Ah, well there’s the rub. And that’s why Rick should have written a keyboard handler. Using an appropriate keyboard handler you can type all those characters at the command line.

Really? I can make a directory called “Photos of Tōkyō 2016年07月12日” and have it make sense on the command line?

Let me see if I can make this clear – I’m not interested in extended characters in the command line. It doesn’t work on the DOS command line, and I don’t expect it to work on the RISC OS command line [tech: it might, if you use a TaskWindow set to an appropriate font, but I’m talking the press-F12 command line].

There is no requirement (and has never been any mechanism) to register keyboard handler names. Therefore they may all be called InternationalKeyboard for all you know.

And shouldn’t that be within a module with a unique name? There’s no requirement for keyboard handler names – what about the module they are a part of?

There’s no point flogging a dead horse. You’re doing the wrong thing.

And I’m asking you to explain why you think a graphical UI for extended key selection should be something provided by the keyboard handler. I notice you skipped over that question last time, so I will ask it again.

So you did three tests? Oh I take it all back! Logic and reasoned argument defeated by coin flip. I shall take up another career. You can take the boy out of Aldershot…

Hehe, you won’t let the insult drop will you? That’s okay, it’s only making me pay less attention to you, not more.
Still, that might save you from having to think of what the keyboard handler should be doing to the API. You know, MoreKeys works within the realm of the desktop and pops open a window with the keys available as icons to click on. Do you honestly think that the keyboard handler should be responsible for popping up UIs? What if the user is playing a game or in MODE 7? Come on!

It clashes with all keyboard drivers, and I’m sorry you still can’t see why.

I can see that it wouldn’t be nice to swipe keys from the handler, but when said keypresses have no actions and for some of them there is no method other than mucking around in !Chars (or worse – given !Chars is not Unicode aware)…
Again, I understand quite well that it is not the most optimal solution and I am looking at FilterManager for the next incarnation.

But, you know, there’s a ton of interesting characters in LatinX (where X > 1), how to get to them all from keypresses? Oh, yes, I forgot. You can’t…

But, then, you seem to think I’m just a braindead jerk from Aldershot, so what possible interest could I have in characters with wibbles and squiggles stuck on top? :-P

There are very few characters that are not permitted in filenames

Perhaps I should have said deprecated rather than prohibited. I may need to copy files to a Windows machine and to use the DOS prompt to process them with something like ‘sort’ or ‘fc’ (file compare) or even to put them on a CD (which, by default, even strips out lower case letters).

Really? I can make a directory called “Photos of Tōkyō 2016年07月12日” and have it make sense on the command line?

Yes.

I’m talking the press-F12 command line

So am I.

And shouldn’t that be within a module with a unique name?

It will probably be in a module. The module name doesn’t need to be unique. It is likely to be InternationalKeyboard, as I said.

And I’m asking you to explain why you think a graphical UI for extended key selection should be something provided by the keyboard handler.

At no time have I suggested that. An on-screen keyboard is one thing, a keyboard driver is another. Breaking the keyboard driver so that one can have an on-screen keyboard is the wrong approach.

Do you honestly think that the keyboard handler should be responsible for popping up UIs?

No. Nor do I think your module should be preventing the keyboard driver from doing its job. I do think you should have written a keyboard driver so that all those characters could be typed from the keyboard, but I have also explained how your key detection code can be fitted around the existing handler without breaking it.

I can see that it wouldn’t be nice to swipe keys from the handler, but when said keypresses have no actions

You mean had no action in the three you tried. I flipped a coin three times… they always come up heads.

and for some of them there is no method other than mucking around in !Chars

By ‘them’ I presume you mean ‘characters’, in which case there is a way: use a better keyboard handler.

But, you know, there’s a ton of interesting characters in LatinX (where X > 1), how to get to them all from keypresses? Oh, yes, I forgot. You can’t…

Yes you can, with a suitably capable keyboard driver. Would you like me to make you a screenshot to prove it to you?

what possible interest could I have in characters with wibbles and squiggles stuck on top? :-P

I know you’re very interested and I welcome that.

there’s a ton of interesting characters in LatinX (where X > 1), how to get to them all from keypresses? Oh, yes, I forgot. You can’t…

This is a MODE 0 screenshot of a RO4 machine. Note that if you have a UTF8 alphabet one wouldn’t need to switch to get more characters, but you did specifically ask about the various Latins.

Edit: I’m still a bit vague about what Google Drive does and doesn’t allow one to do with one’s own files, but embedding images in other sites seems to not work. Sorry.

Putting aside the thrilling programmer-cage-match, am I any closer to being able to get wimp events for key up and downs (etc)? I have code being demoed in public at BigBangFair that can’t do all the stuff we want because of the lack; the demo has to be shown in unix (belch) to get that bit working. We Can Not Let This Stand, Mr President! We cannot allow a key press event gap to develop!

Putting aside the thrilling programmer-cage-match,

(^_^)

am I any closer to being able to get wimp events for key up and downs (etc)?

Was KeyWatch (link in middle of first page) not of any use?

At no time have I suggested that.

Which implies that you either didn’t really understand what MoreKeys does at first or you preferred to have a Daily Mail style rant anyway.
Did you ever consider:

• The average keyboard handler is not user configurable
  and:
• Maybe some people don’t want to remember dozens of arcane keypresses.

When I first started, I used to remember all sorts of Alt-Numkey combinations. Then it was AltGr-plus-modifiers-then-key. Now Android has shown me there can be an even simpler way…

Really? I can make a directory called “Photos of Tōkyō 2016年07月12日” and have it make sense on the command line?
Yes.

Screenshot? Of RISC OS 5 displaying Unicode in the command line, please…

I may need to copyfiles to a Windows machine and to use the DOS prompt to process them with something like ‘sort’ or ‘fc’

It’s the same thing with SMPlayer. It fails when trying to load a file with a name like “????????.avi”. How does it work? Simple, it uses the old style 8.3 filename.
DIR /x ought to show you these.

Was KeyWatch (link in middle of first page) not of any use?

Actually I skipped over that in the excitement of all the blood and sputum flying around. But yes, it does look rather like it was intended to do what I need. I wonder if it actually does…

If not, the one I’ve just written will.

Screenshot? Of RISC OS 5 displaying Unicode in the command line, please…

First let’s have the acknowledgement that you were wrong about the Latins.

Then I’ll go to the trouble of writing a Japanese IME and making a BFont-compatible kana font just to prove you’re wrong about that too.

I can’t help feeling technical explanation would be easier, but if it must be show and tell, it must.

First let’s have the acknowledgement that you were wrong about the Latins.

Thank you for the correction. I was wrong. Using a non-standard keyboard driver with an older version of RISC OS, you evidently can enter a wide variety of foreign characters.

Now please demonstrate the same thing using the standard keyboard driver supplied with RISC OS 5 in, uh.. RISC OS 5…obviously enough. In other words, the OS as supplied from this very website, can it do this? If not, the fancy keyboard driver you use, can we all download and use it?

What I actually said was:

But, you know, there’s a ton of interesting characters in LatinX (where X > 1), how to get to them all from keypresses? Oh, yes, I forgot. You can’t…

And I believe that still holds true. That c-with-horns, the d-with-a-big-dong, Shrek, the l-with-a-slash – I’ve switched to the appropriate LatinX and I tried all sorts of Alt-key combinations but nothing seems to work above and beyond the usual selection of dead keys (when the character is available – ç é ì ô ü etc). If you happen to know something I don’t, please enlighten me.

The reason I asked about LatinX is purely because !Chars doesn’t support Unicode, and there’s already plenty of stuff in there that you don’t seem to be able to reach with the standard keyboard driver.

As for the Japanese, I asked:

I can make a directory called “Photos of Tōkyō 2016年07月12日” and have it make sense on the command line?

You replied:

Then I’ll go to the trouble of writing a Japanese IME and making a BFont-compatible kana font just to prove you’re wrong about that too.

Which essentially translates to “you can’t”. Well, sure, you can once the software is available, just like RISC OS could load and execute Windows .EXEs or Linux .so modules. All it needs is some clever software. RISC OS itself is just a big wodge of instructions after all, just like any software.
However, for all intents and purposes – RISC OS currently cannot display “Photos of Tōkyō 2016年07月12日” in the command line; and I’m wondering if it should even try…
Of course, if you’d prefer to write a Japanese IME and Bfont to further “prove me wrong” instead of admitting you yourself were wrong on that point, then please, go for it. But make sure it is entered into the official repository – it won’t count if it isn’t in the standard RO distribution.

Though, frankly, a more capable keyboard handler might be preferable. Probably not a big deal to you, you already have one. We do not, and that is part of what MoreKeys was designed to address.

Oh, and just to clarify – holding Alt and typing codes on the numeric keypad is not a viable solution. Just thought I should mention that…

If not, the one I’ve just written will.

Well thanks very much but unfortunately it doesn’t do the most important part of my needs :-(

Reading the raw key state is certainly something of interest for various uses but I really need those events properly integrated. Either as part of the normal key press stuff (which I appreciate is fraught with complications for interacting with other users) or as a new event stream that carries all the same info as key presses plus my up/down stuff. I can’t make much use of a parallel stream of events where they may not be properly ordered wrt the key presses – it has to work in co-ordination. The frustrating thing is that we know all the info is there waiting to be made use of…

How can I get there from here?
Given that we have suitable raw events, how is it best to process them into something similar to key events – keyboard map, language & territory settings, how is the window handle in a key event worked out, how do they get sent to the wimp handling system?

Well thanks very much but unfortunately it doesn’t do the most important part of my needs :-(

Have a look at KeyWatch (linked to earlier (page #1)). In the “doc” subdirectory is an API/description document.
Take a look at the document – does that offer what you’re looking for?

keyboard map, language & territory settings,

I think Wimp/keyboard handler/InternationalKeyboard/Territory all work together to make that work. In reality you are shorting out two contacts on a matrix of wires. All the smarts are done at higher level, so if you tell your computer that you have a French keyboard, the top row will begin “AZERTY” even if the keycaps read “QWERTY”… Plus it allows for dead-key functions and stuff like Alt-[ and then “e” to make an accent.

how is the window handle in a key event worked out,

I’d imagine that’s dead simple. You don’t get a keypress event until one of your windows has input focus. Only one window can have input focus. Ergo…

how do they get sent to the wimp handling system?

Most likely the Wimp hooks into the various events and vectors, performs its own translations (like Fkeys being key codes >256) and then passes this to the application.
I would rummage around the Wimp sources for the hell of it, but this time I’m afraid I’m going to have to apologise and duck out. It’s 02h54 here. I should have been asleep long ago…

I’ve been peering at the KeyWatch module code and it does seem to at least intend to do what I need. Right now I can’t quite work out whether or not it will deliver mapped keys or raw key numbers, and the event type it delivers is a bit hard to work out. I particularly like that the doc explains what to do about gaining/losing focus, though I think it would probably be smarter to have a suspend SWI rather than add/remove every time.

The other problem is working out if the dam thing will build ok. I suppose I must gird my lions (or even my loins) and try it.

I can’t make much use of a parallel stream of events where they may not be properly ordered wrt the key presses

<Gnashes teeth> I wish I had understood that fully before writing the module.

Given that we have suitable raw events, how is it best to process them into something similar to key events

I really have to flag up a warning – your requirement is ill defined. You really haven’t considered what happens when keys are held when your application loses or gains focus. In many ways the ideal would be an event with the entire current state in it, rather than only one transition at a time.

The problem, and it’s a big one, is that keypresses are buffered, and key transitions are not.

If you want your key transitions to be delivered in the same chronology as keypresses, then they will (in effect) have to be in the same buffer. As it’s the Wimp that removes codes from the keyboard buffer and decides whether and which application to deliver them to, it would appear that my earlier suggestion of a special DeepKeys key code to represent the transition would be necessary, with a filter to morph the resulting keypress into a new transition event.

My point is that though I haven’t looked at KeyWatch, I’m pretty certain it won’t be doing what you appear to require it to do. Think about the relationship between the keyboard buffer and the event queue… they are not the same thing at all. I doubt it can arrange the chronology you think it will, sorry.

keyboard map, language & territory settings

They are the responsibility of the keyboard driver and you shouldn’t need to worry about them. User presses buttons, application gets keypresses. Quite which ones are beyond your application’s control.

how is the window handle in a key event worked out,

When the Wimp removes a code from the keyboard buffer and an application has the focus, it packages it into a keypress event and adds it to the event queue. However, the application may have keypress events masked out so won’t get it until it’s ready.

In particular, there is a disconnect between the moment that a code enters the buffer (when the focus could be in one window) and when the Wimp constructs the keypress event (when the focus could have moved). Synchronising different types of event, when some can be masked and hence delayed, is not trivial in a messaging system without timestamps!

how do they get sent to the wimp handling system?

Note that because a keypress can cause the focus to move (cursor keys for example) only one keypress event is queued at a time. All the rest of your keypresses are sitting in the keyboard buffer and may not be delivered to the application that had the focus when they were pressed…

So how do you think your key transition messages are going to work?

Well back on 6th March I wrote -

I need something similar to what we get from both X & fbdev on linux, from OSX and even windows (even frikkin windows!) which is to say some kind of event for a key-down and another for a key-up.
Windows & OSX seem to do a triplet of down (with fairly raw key data) + key press (with processed key values) + up (with raw data again). The linux fbdev provides just down & up so far as I can see. I don’t mind either way.

There’s no problem with the current key event along with deepkeys telling me the key pressed and the modifiers in use at the time of pressing (and thanks for the explanation a few messages back. I wish that had been clear in anything I read when I started using it); what I need to get is some subsequent event that
a) arrives after the key press event (duh)
b) has enough info to tie it to the relevant preceding key press of the same key
c) arrives before any following key press, if the earlier key was released before the next was pressed.

So if the user types a b c I should get keydown ‘a’, keyup ‘a’, key down ‘b’, keyup ‘b’, keydown ‘c’, keyup ‘c’.
If the user types a (hold it down) b (release a) c, then I should get keydown ‘a’, keydown ‘b’ keyup ‘b’ keyup ‘a’ keydown ‘c’ keyup ‘c’.

If a key is held down long enough to trigger auto-repeat I guess there should be another keydown sent. If the shift-keys have altered then they should be included, so dddddddDDDDDddddd might be entered. i.e. keydown’d’, {wait for it…} keydown ‘d’, ….keydown ’d’+shift, keydown ’d’+shift… keydown’d’,….. keyup ‘d’.

I think the definition in KeyWatch for handling changes in focus is pretty sensible; if you lose it, make sure to read any remaining events and deal with them before relinquishing focus and suspending any special driver, if you gain it, deal with any already waiting events before activating driver. I think that probably allows apps with multiple windows to handle cases where key (or several) is held down while the focus is moved from one window to another.

Oh – and thanks to everyone that is taking an interest in this. I know you have a wide choice of strange arcane things to think about and hope that you will fly with us again soon.

So if the user types a b c I should get keydown ‘a’, keyup ‘a’, key down ‘b’, keyup ‘b’, keydown ‘c’, keyup ‘c’.

Ok, well you’ve answered your own question really – since they have to be interleaved with keypresses the key ‘ups’ will need to be in the keyboard buffer. You also only seem to be interested in key ups corresponding to keypresses, or do you want key-downs for non-buffered keys too?

We seem to have gone full circle and the solution seems awfully familiar:

Something must sit on KeyV/EventV and InsV, and use DeepKeys to buffer a magic keypress for any transition that does not buffer something. Then a filter morphs those keypresses into a different event.

The problem will come outside the desktop, for programs that do the equivalent of

PRINT"Press Y or N"
IFGET=ASC"N":PROCno:ELSEPROCyes

If non-bufferables are delivered as keypresses, then pressing Shift in order to produce ‘N’ would cause a magic value to be delivered to GET – there’s no Wimp Filter there.

As it happens INPUT (or the command line for example) wouldn’t be affected. Brownie points to anyone who can work out why.

You also only seem to be interested in key ups corresponding to keypresses, or do you want key-downs for non-buffered keys too?

Ah, I fear I slipped into imprecise terminolology. I’d like events for any and all presses of keys that could imaginably represent a character being input; so alt-ctl-shift-fn-{some alphanumeric or math symbol or currency wotsit etc, including the general cursor type keys} but probably not alt-ctl-shift itself. Themselves? If it isn’t plausible to get events for those presses that wouldn’t normally buffer a key, then I’ll cry into my latte but be thankful for getting up events.

I don’t much mind how one retrieves the events; if it can fold tidily into wimp_poll that would be nice and simple and easy to explain to other potential users etc, but a poll word would be fine, as would any other way of fetching them when I am in the general region of handling input events. As long as I can find out that a key was pressed with whichever modifiers, and then find out that it was released later, and can extract the key/character, modifier state and work out the window handle – I’ll be able to make use of it.

This was all a lot simpler 25 years ago when I could sit on keyV/eventV directly in my application, knowing there was only one window, no wimp_poll to worry about etc….

Just a random musing…

What about a helper module? When a key has been pressed that you are interested in, you register this with the helper module (it will have a buffer of known keys). It sits on KeyV and when that key is released, it will flag this in a poll word.

In this way, you get notification of a keypress via the normal Wimp key event; and you get notification of a key release via pollword (the pollword itself will hold the value of the released key) regardless of who owns the focus at time of key release.

The only complication I can forsee is KeyV works with internal key numbers.

There isn’t, as far as I can tell, an Event for Key Down/Key Up using ASCII codes (ie after the keyboard driver has done its stuff). Maybe this is a candidate for something to be added to RISC OS? …given key up doesn’t normally insert anything into the buffer; and auto-repeat means key downs don’t necessarily have matching key ups.

Just thinking out loud.

In this way, you get notification of a keypress via the normal Wimp key event; and you get notification of a key release via pollword (the pollword itself will hold the value of the released key) regardless of who owns the focus at time of key release.

What a great idea.

There isn’t, as far as I can tell, an Event for Key Down/Key Up using ASCII codes (ie after the keyboard driver has done its stuff).

The combination of DeepKeys (tells you the physical key number of the key that generated the keypress) and KeyState (tells you when that key is released) will do this.