Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8870
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Flow of keystroke messages in a UI |
| Date | 2015-10-04 21:27 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x50ebanoyfako5@localhost> (permalink) |
| References | <mulmv6$1hv$1@dont-email.me> <op.x5wde9jfyfako5@localhost> <murgth$uhm$1@dont-email.me> |
On Sun, 04 Oct 2015 11:36:08 -0400, James Harris <james.harris.1@gmail.com> wrote: > 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. Well, I suggested a few later in the post. Even here, I think the accept or reject, and pass-back upon reject method would work. Of course, the widget loses focus to it's text field when it's text field is activated. I.e., the text-entry field has the focus. It can accept V and Shift-V. It rejects Control-V, Alt+V, Windows+V as unusable and passes back up the chain. >> 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. No. It may have been a system tweak for Windows 98/SE. For XFCE on Linux, I currently have to click everything. >>> 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. Perhaps, don't let the app have any access. I.e., a text field is a part of the OS, a widget is a part of the OS, a menu is a part of the OS, etc. If the app can only call a function for each of the menuing elements, then the OS keeps control. You're a strong propoent of modularity anyway. So, this should fit right in with your values. :) >>> 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! Well, only the active or focused menu would use that info. Yes? The non-active menus would reject it because they're not active, i.e., the info isn't for them. >>> 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. Let's say you have preemptive multi-tasking. Microprocessor time or clocks is being divided amongst various pieces of code which are executing. The OS sets a variable to the process ID for the current process, where the current process is the focused text-field, menu, tab, window, etc. The active item - the one receiving processor time - has a loop which checks if the focused ID is the same as it's ID. If it is, then it can use the keyboard stream. If not, then it can't. If it can and doesn't want the info, it passes the info back so something else can use it when it receives some processing time. >>> 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.) Well, all of of them can't handle ALT-F. Can they? ... AFAIK, only one of them can be allowed to handle ALT-F on a "permanent" basis. So, the info is either filtered out or rejected by some of them. AISI, it's just a matter of whether you want the higher-level items to obtain the info first, or whether that info goes to the focused item and it rejects what it doesn't need. When multiple layers need to handle ALT-F, usually there is some sort of escape sequence to allow the layer to receive an ALT-F, e.g., VI editor for CTRL-M you must type CTRL-V then M. >> 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. E.g., your text-field. When you're typing into it, it has the focus. It's receiving the keyboard input. It gained the focus by tab-ing to it or by mouse clicking upon it. The text field could have a polling loop to check to see if it's the item granted focus. If it's not active, then it shouldn't attempt to use the keyboard stream. If you're using preemptive multitasking, the code for your text-field, menu, widget, etc will all be receiving processor time in a round-robbin or time slice method, which they must yield when they're not active. Or, you would need to have a scheduler which caused everything which isn't active to not receive any processing time until activated. Semi-permanent "sleep" would, of course, prohibit that code from checking on various events, timers, counters, etc. So, AISI, everything which is executing, must get some processor time, even if they mostly yield their time. >> 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? Rejection. If a programmer can inject their own code here, then they could code whatever they want and trap them. If the parts and pieces of all widgets, menus, apps etc which access keyboard stream are under the OS control, then they couldn't, e.g., when the text-field is not user programmable but a system function which was programmed to reject Alt+Tab. 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