Disabling certain keys in certain applications

[abhishekmaharana]

Hello.
In my OS,I have certain applications where I need only certain keys to work and in other all keys to work.

Like in my notepad-like application,I want all keys to work.

But in my X and O application, I want only '\t' & '\n' to work.

I had thought of keeping an array corresponding to keyboard scancodes.
When any application starts,I would make all the entries '1' whose corresponding scancodes I would like to accept.

When a keyboard interrupt occurs, I would 'AND' the value with the above array's corresponding entry. If non-zero, I would accept the key else reject it.

Is the above approach fine.
Please point out any problems in the above or any improvements/changes.
Thanks and regards.

[Love4Boobies]

Uhm... Shouldn't you have the applications do something like

Code: Select all

key=get_key();
switch(key)
{
// whatever
}

That would be consistent with other APIs. AND'ing an array would probably seem a bit weird to an application programmer.

[Brendan]

Hi,

Uhm... Shouldn't you have the applications do something like

Code: Select all

key=get_key();
switch(key)
{
// whatever
}

That would be consistent with other APIs. AND'ing an array would probably seem a bit weird to an application programmer.

Yes, but (depending on OS design, etc) providing some way for the application to (optionally) disable certain groups of keypresses could save some overhead.

For some OS's "getkey()" means block the task until a keypress is received; and when a keypress is received the task is unblocked, a task switch occurs, the "switch()" runs, and then the task is blocked again and another task switch occurs. In this case, if (for e.g.) the application could tell the GUI "I don't need to know when a key is released" then you could halve the overhead involved (and halve the number of unnecessary task switches).

However, having a bitmask (one bit per key) isn't really a good idea. Mainly because you'd need a bit for every key for every keyboard (including US keyboards, Japanese keyboards, Arabic keyboards, etc, and all the possible "media" keys on every multi-media keyboard ever produced), which would be a nightmare for application developers and create compatibility problems when new keyboards are manufactured with new keys.

It'd be better to have one bit for each group of keys. That way when someone makes a new keyboard with a new multi-media key, then the existing bit that enabled/disabled sending of multi-media keys would control it; and you could have an "alphabet" group that enables/disables all keys for all "alphabets" (for all locales/languages).


Cheers,

Brendan

[abhishekmaharana]

Hi,

It'd be better to have one bit for each group of keys. That way when someone makes a new keyboard with a new multi-media key, then the existing bit that enabled/disabled sending of multi-media keys would control it; and you could have an "alphabet" group that enables/disables all keys for all "alphabets" (for all locales/languages).

Cheers,

Brendan

Thanks.I think it is a good idea.But it might pose a problem when I want to enable 1 or two key from a group. Because a bit is the control for an entire group.

[Brendan]

Hi,

Thanks.I think it is a good idea.But it might pose a problem when I want to enable 1 or two key from a group. Because a bit is the control for an entire group.

Well, lets take a look at your alternative...

A "standard" keyboard has 102 keys. On top of that there's the windows keys ("start", "menu" and the new "windows flip 3D") so that's 3 more. Then there's multi-media keys - fast-forward, rewind, play, stop, mute, volume up, volume down, cut, copy, paste, undo, email, web, search, sleep, log off, zoom in and zoom out are all fairly common, but you'd better allow space for at least 32 of these. Also, there's keyboards with up to 22 function keys (10 extra). That takes you to 147 keys. For 147 keys you'd probably need about 250 bits, because different keys create different characters depending on things like the state of the shift key, caps lock, number lock, etc.

Next - internationalization. There's plenty of different keyboard layouts - there's a good page on Wikipedia. You could probably add up all the extra keys, but...

For some languages (e.g. Japanese, Korean, Chinese) the keyboard driver talks to an Input Method Editor (see Wikipedia's page) and the IME pretends it's the keyboard and talks to the application. This means you'd need a different bit for each character that an IME could send to the application. I'm not too sure how many characters that adds up to, but it'd be a very large number. To avoid creating your own index of what each bit means, it'd make a lot of sense to just use Unicode. Unicode defines a range of 1114112 "code points".

So, that adds up to 1114112 Unicode code points, plus a little extra (a few hundred) for other keys that don't have any Unicode code point. You'd also want some room for future expansion, so it might make sense to round this up to 1310720 bits.

That works out to 160 KiB of flags for each application, or a total of zero bytes (because no sane application developer is going to set any of these bits anyway)....


Cheers,

Brendan