Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8872
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Flow of keystroke messages in a UI |
| Date | 2015-10-05 15:01 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <mutvnl$9h9$2@dont-email.me> (permalink) |
| References | <mulmv6$1hv$1@dont-email.me> <op.x5wde9jfyfako5@localhost> <murgth$uhm$1@dont-email.me> <op.x50ebanoyfako5@localhost> |
On 05/10/2015 02:27, Rod Pemberton wrote:
> 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:
...
>> 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.
It would work but, unfortunately, it leads to the problems I have been
speaking about where keyboard navigation controls can vary depending on
which window has focus. As I just wrote to Wolfgang that has the
potential to be very confusing for a user of the UI as the apps behave
inconsistently.
This may be heading towards something like the following.
* Certain specific controls being defined for the UI itself: switch
application, launch a new app, close a window etc. Perhaps specific key
combinations. Top priority. These keystrokes reserved for the UI.
* A certain type of control being used for the framework of a window:
pull down menus, pop-up menus, move the focus etc. Perhaps Alt+key, Tab,
Shift+Tab, etc.
* Another certain type of control being passed to the widget or
application running in a window. Perhaps all the rest.
A scheme like that would give apps plenty of scope for shortcut keys if
they wanted them but also give a user a consistent way to control the UI
and elements therein.
I don't know if that can be done completely, however. For example, if a
browser is passed the Alt+key keystrokes for its own menus then AFAICS
there is nothing to prevent it passing those on to JavaScript apps that
run in the browser's windows. Some web-based email clients work that
way: with the browser's permission or complicity they take over some or
all Alt+key combinations to control navigation within the email system.
That means that those keys no longer control the browser.
Such an embedded app could take over something like Alt+T so that,
instead of it pulling down the browser's Tools menu, it sends the
current message the the Trash. Yuck! That's especially bad when the
browser shows its Tools menu with T underlined. The underline is
normally taken as a hint that that's what Alt+T leads to but the
embedded app would have been allowed to take over that keystroke and
thus cause a disconnect between what the user sees and what happens.
>>> 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.
Is there no option in XFCE to change the behaviour to what you prefer?
...
>> 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. :)
That sounds good but is it possible for the OS to keep control? Take the
example above. If the OS launches a web browser and passes it things
like Alt+ keystrokes for its own menus how can it prevent the browser
then passing those keystrokes to an app the browser is running?
...
>>> 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.
It may be best for them simply not to receive it. Maybe I am missing
your point but I cannot see any good reason to pass a key combination to
elements which do not have focus - and then expect them to reject it.
...
> 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.
Yes, that is an approach taken by a number of systems: reserve a
keystroke but if the user really wants to send it to a child then allow
that too. That may be less convenient for the app but it still allows
the control and keeps the UI more convenient for the user.
Of course, apps can still be controlled by a mouse. None of this
discussion affects that so none of that control is lost.
>>> 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.
I think an element can be "woken up" when an event occurs so there's no
need for polling.
Event-driven apps such as UIs often have a main event loop which is a
single thread which operates as follows.
loop
wait for next input event and assign to E
switch (E)
case 0:
process type 0
break
case 1:
process type 1
break
etc.
The processing cases would really be formed dynamically rather than the
static choices shown above but they could refer to different event types
and message destinations.
> So, AISI,
> everything which is executing, must get some processor time, even
> if they mostly yield their time.
As I say, with event-driven programs there's no need to poll. Such
programs normally sit quietly in the event loop waiting until something
happens.
>>> 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.
That is possibly written with your broadcast and polling model in mind
which as mentioned I don't believe is necessary. It may be better not to
pass the Alt+Tab to a window in the first place. The UI can at least
control what messages it sends to the windows it is hosting.
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