Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8867
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Flow of keystroke messages in a UI |
| Date | 2015-10-04 16:36 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <murgth$uhm$1@dont-email.me> (permalink) |
| References | <mulmv6$1hv$1@dont-email.me> <op.x5wde9jfyfako5@localhost> |
On 02/10/2015 22:17, Rod Pemberton wrote: > On Fri, 02 Oct 2015 06:42:34 -0400, James Harris > <james.harris.1@gmail.com> wrote: > >> Any of you guys come up with a good way to handle keystrokes in a UI >> when multiple elements of that UI may be 'interested' in receiving them? > > I'm wondering when that would occur. AIUI, usually one app or window > at a time has focus for the keyboard which is selected via mouse or > the tab key, etc. That's true but even when a widget has focus there are some keys or key combinations which should be handled by something else. As an example of that, say you are typing into a text-entry field. You might want: * V and Shift+V to be passed to the text-entry field * Control-V to trigger a Paste operation * Alt+V to be passed to the window to pull down the View menu * Windows+V to start an app That requires the different key combinations to be handled in different places, not just the widget which has focus. The component which receives the keystroke event will differ depending on what the event is. I was asking how a UI should control which events go to which components. >> If you have not come up with your own idea are you aware of any good >> standards or recommendations? ... > Also, with Windows, I was used to just moving a mouse over a Window or > hover for it to become the active window for the keyboard. However, > with Linux I keep typing into the wrong window, app, or terminal, > because I must click the window to select it. You mean the other way round? AIUI Windows uses Click to select a window whereas X allows you to chose whether to Click or just to Move to that window. That said, I have seen Windows interpret the mouse scroll wheel strangely - such as scrolling a background window rather than the one on top with the focus. ... >> I just tried the above test on a few application windows. Notably, the >> problem exists in this PC's (Win7) version of Task Manager and Notepad >> but not Thunderbird. With the latter, even if the File menu is >> highlighted (as described above) the Windows key is still obeyed by the >> Windows GUI shell. IMO that is better. But the difference in effects is >> obviously an inconsistency. > > So, is this a gui messaging problem or a software app issue? Maybe both. I guess I was asking if and how a GUI's messaging should be set up so that an app could not take over keys that the user might want to use for the GUI's windows. >> It is also indicative of what may be happening. It seems that keystrokes >> (all keystrokes?) are delivered first to the app window or the focussed >> widget and that the OS windowing system only gets to see those that the >> widget and the app pass along. ISTM that that's a bad idea as it allows >> such keys to be captured by the app. A poorly or maliciously written app >> could cause them to be ignored or, worse, perhaps choose to do things >> which look right but are not as expected or do something devious in the >> background (e.g. keystroke logging). > > So, you'd recommend doing what? Split the keyboard stream into visible > characters plus space which the app could use directly, and keyboard > sequences converted to window messages by the gui? I don't know what the best approach is - hence the question. It seems that the traditional approach is to allow widgets to receive any and all keys if they want to. That doesn't seem right and causes the problems mentioned initially. >> To confirm that interpretation of events, note this comment from >> Microsoft: "If your window procedure must process a system keystroke >> message, make sure that after processing the message the procedure >> passes it to the DefWindowProc function. Otherwise, all system >> operations involving the ALT key will be disabled whenever the window >> has the keyboard focus. That is, the user won't be able to access the >> window's menus or System menu, or use the ALT+ESC or ALT+TAB key >> combination to activate a different window." >> >> That's not good. The quote is from >> >> [link] > > So, you're thinking about the reverse. I.e., a broadcast message for > the ALT key to all open windows but then only the active focus window > should take action for the broadcast. That would probably require > splitting the keyboard stream into text and non-text. I doubt you > want to pass text to all windows as that would slow things. No, I am not suggesting a broadcast. Imagine that Alf+F pulled down three of four file menus at the same time.... Not good! ... >> To illustrate potential options: Imagine a chain of UI elements from the >> widget which currently has focus up through each of its parents in turn >> to its window and then up again to the windowing system shell. If >> keystrokes are passed to the lowest level (the focussed widget) first >> then we can get the problems above. If they are passed in the other >> direction, though, would that be better? Or would it mean that things >> like Control+C would be picked up as a Copy command even in windows like >> a terminal where it should generate an ASCII 3? > > Obviously, there needs to be a method to select or filter which window, > app, or widget receives the command sequence. It can be viewed as a > form of "pre-processing," as you're describing, because that goes > directly to where the sequence is needed and only goes to other windows > or widgets or apps if the focused app doesn't need it. Or, it can be > viewed as a form of "post-processing," such as every app, window, or > widget receiving the message or sequence and those which don't need > it selectively rejecting it, i.e., not focused. Yes. > You're familiar with ungetc(), yes? I.e., the focused app/widget/window > could poll the keyboard stream while the non-focused ones don't. If the > focused app doesn't use the sequence, it could push it back into the input > stream, temporarily yield focus and wait for some other task to take the > sequence from the stream. This would cascade down through the chain as > far as is needed with the OS at the end of the chain. The OS would be > required to grabs the sequence, if reached, even if unneeded. Once a > task has popped the sequence, then the focus returns to the app which > yielded. So, this could be thought of as a sequence of > pop-accept-restore-focus or pop-reject-push-yield-focus. I.e., probably > two stacks: stream and focus. I think the existing systems I mentioned work in that sort of way, i.e. the widget with focus can register to receive all events and, if it receives an event it is not interested in, it can 'unget' the event allowing it to be passed 'up' to a parent. Unfortunately, that allows apps to take over keys that would appear to be for window control. >> Some alternatives: >> 1) pass keystroke info down instead of up, i.e. from the UI shell >> down a step at a time until something absorbs the keystroke info >> or we get to the focussed widget, >> 2) pass keystroke info down then back up - i.e. where each UI >> element gets two distinct chances to choose whether to absorb >> it or not, >> 3) let the windowing shell get first dibs for the really important >> keys and then pass from the bottom up, etc. > > 4) broadcast to all and each either accepts or rejects, with only the > focused widget/app/window accept > 5) active or focused window polls, conditionally rejects to pass info up OK. What do you mean by polling. >> In each case I am thinking that the first UI element which [has] an >> 'interest' in the keystroke basically getting the first chance either >> to absorb it or to ignore it. > > Even in a multi-tasking, multi-process OS, the user can only work on > a single app at a time, but they can switch through many of them > quickly as needed. So, there is only a single app/widget/window/menu > which is active or has focus at any point in time. Not sure if it's what you mean but whichever widget has the focus sits in a window, and the window exists in a 'desktop'. Any of those three might want to process a certain event. (Widgets may also exist within a container and the container within another container and that within a window - so the chain up may have more than just the three levels widget, window, and desktop.) > Personally, > I would attempt to poll from the item granted the keyboard focus, with > the mouse or tab key etc selecting a new focus for the keyboard. Sorry, I don't understand what you mean there. > AISI, the problem with most of the solutions is that they pass around > too much information or pass information between too many layers when > that's not required. I.e., I'd probably also attempt to go for the > one that minimized information passing (if it works), e.g., polling, > pass-back if rejected. OK. Would that stop widgets from trapping things like Alt+Tab? James
Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-02 11:42 +0100
Re: Flow of keystroke messages in a UI Bernhard Schornak <schornak@web.de> - 2015-10-02 20:43 +0200
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-04 15:23 +0100
Re: Flow of keystroke messages in a UI Bernhard Schornak <schornak@web.de> - 2015-10-05 17:38 +0200
Re: Flow of keystroke messages in a UI "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 17:17 -0400
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-04 16:36 +0100
Re: Flow of keystroke messages in a UI "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-04 21:27 -0400
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-05 15:01 +0100
Re: Flow of keystroke messages in a UI "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-05 21:57 -0400
Re: halting Adobe Flash videos with Mozilla Firefox, was [Re: Flow of keystroke messages in a UI] "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-26 04:35 -0400
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-12-27 12:40 +0000
Re: Flow of keystroke messages in a UI "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-12-27 15:51 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-03 12:08 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-03 14:55 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-13 17:58 +0000
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-15 11:32 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-16 03:29 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-16 13:44 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-16 12:55 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-16 19:55 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-18 07:39 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-18 22:45 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-19 22:28 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-27 13:27 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-27 17:20 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-28 11:03 +0000
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-22 17:43 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:17 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-27 13:42 +0000
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-04-08 09:14 +0100
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-14 09:56 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-14 09:11 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-14 15:58 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-15 05:55 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-15 15:57 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-16 05:33 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-24 06:16 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-24 18:03 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-28 06:25 +0000
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-02-28 00:21 -0800
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-28 08:45 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-28 20:40 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-03-02 14:49 +0000
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-02 21:50 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-03-05 06:09 +0000
OT politics was Re: Flow of keystroke messages in a UI "Kerr Mudd-John" <admin@127.0.0.1> - 2016-03-05 12:40 +0000
Re: OT politics was Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:11 -0500
Re: OT politics, was [Re: Flow of keystroke messages in a UI] Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:11 -0500
Re: OT politics, was [Re: Flow of keystroke messages in a UI] James Harris <james.harris.1@gmail.com> - 2016-03-17 16:35 +0000
Re: OT politics, was [Re: Flow of keystroke messages in a UI] Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-17 21:02 -0400
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-24 20:09 -0500
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-02-25 14:55 +0000
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-02-16 03:56 -0800
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-17 04:21 -0500
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-02-24 02:12 -0800
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-24 18:03 -0500
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-02-28 02:53 -0800
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-28 20:15 -0500
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-03-27 20:37 -0700
Re: Flow of keystroke messages in a UI Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-28 18:23 -0400
Re: Flow of keystroke messages in a UI "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-03-27 21:10 -0700
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-15 14:34 +0000
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2016-01-15 15:10 +0000
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-05 15:39 +0100
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-10-03 12:48 +0200
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-04 17:00 +0100
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-10-04 23:32 +0200
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-05 14:05 +0100
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-05 15:17 +0100
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-10-06 10:35 +0200
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-06 16:28 +0100
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-10-06 19:14 +0200
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-10-06 20:02 +0100
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-10-06 10:46 +0200
Re: Flow of keystroke messages in a UI "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-07 01:16 -0400
Re: Flow of keystroke messages in a UI James Harris <james.harris.1@gmail.com> - 2015-12-27 12:50 +0000
Re: Flow of keystroke messages in a UI "wolfgang kern" <nowhere@never.at> - 2015-12-27 23:22 +0100
csiph-web