Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8864
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Flow of keystroke messages in a UI |
| Date | 2015-10-02 17:17 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x5wde9jfyfako5@localhost> (permalink) |
| References | <mulmv6$1hv$1@dont-email.me> |
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. > If you have not come up with your own idea are you aware of any good > standards or recommendations? No, but I will B.S. with you on the topic. Some C.S. terminology comes to mind: preemptive multitasking cooperative multitasking consumer-producer problem polling > I say "good" above because AFAICS even popular implementations don't > necessarily get it right. For example, with some apps under Windows > pressing Alt and releasing it highlights the first drop-down menu item - > usually File. If you then press the Windows key (the key based on > Control+Esc) it may seem to be inhibited; instead of opening the Windows > Start menu nothing happens. IMO the windowing system should always > intercept keys like that one and Alt+Tab. Similar issues exist in Linux, e.g., Notepad won't drop down the first menu by pressing the ALT key. You must press ALT-F etc or mouse click a menu. ALT-G ... ALT-R ... ALT-D ... Argh! Where is ALT-F? ... The ALT key is in different position on every keyboard and not easy to find or type either. Ok. Thumb the left ALT key and hunt-and-peck the F with my other hand. Sigh, 15 seconds later, menu ... That's from someone who can (supposedly) type well. A gamer would probably map ALT-F to one of their mouse buttons. 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. I suspect the first is an app coding issue and the second is a coding issue with the user interface. > 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? > 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? > 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. > Other examples are viewing Youtube videos or reading Yahoo mail in a > browser. Such sites can prevent a user typing Alt+F from getting the > File menu and, instead, interpret such keystrokes in the web page. > That's a similar problem to the one mentioned above. As you may recall, I believe in TUC, total user control. IMO, preventing the user from doing what they want violates TUC. One reason I believe in TUC is because of the menu items being selectively enabled and disabled in gui apps. Many years ago, someone made a coding mistake on the Apple Macintoshes. Instead of explicitly setting a bit to enable the menu item and explicitly clearing the same bit to disable the menu item, they toggled the state of the menu item. Unfortunately, sometimes the state would be or become reversed somehow. That meant I couldn't select the menu item when needed. So, I don't care for paternalistic behavior from the OS or apps. I want them to do exactly what I "tell" them to do, when I "tell" them, and nothing more, nothing delayed. I don't care that the OS is in the middle of copying 100GB worth of files. I said "cancel". I don't want to "wait"... I.e., don't disable or enable any menu items for me. Make sure all menu items are always present, not hidden, and enabled. Let me select it. If the app can't perform the operation at that point, give me a warning and an understandable reason as to why. Over the years, Windows has become better at not auto-hiding and not auto-enabling so much, but M$ still periodically slips up and reverts to the minimalist, lets-hide-everything-so-no-one-can-ever-find-it menatlity so that their user complaints go away. "The less they know about, the less they can complain about being broken! He he. They can't even find it to complain about it!" > ISTM that there has to be a better design than that. Hence this post. ... > 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. 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. > 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 ... > 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. 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. 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. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
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