Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8880
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Flow of keystroke messages in a UI |
| Date | 2015-10-05 21:57 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x52adnz7yfako5@localhost> (permalink) |
| References | <mulmv6$1hv$1@dont-email.me> <op.x5wde9jfyfako5@localhost> <murgth$uhm$1@dont-email.me> <op.x50ebanoyfako5@localhost> <mutvnl$9h9$2@dont-email.me> |
On Mon, 05 Oct 2015 10:01:16 -0400, James Harris <james.harris.1@gmail.com> wrote:
> 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.
Isn't all of this just an issue of how you want to split the keyboard's
stream or filter it?
I.e., send it forward and filter as it goes, send it backward and filter
as it goes, send it directly to the appropriate object or item, allow
multiple objects to access or not, etc.
>>>> 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 don't know yet and have yet to look. I've only been using Linux
consistently for a year ... Or, is it two, now?
<OT>
I spent much of Sunday trying to find out why after updating Firefox to
the current version, it would halt the video portion of Adobe Flash videos
after a few seconds, unless the mouse was being moved constantly. I never
found an answer for that. It seems to affect many people with many different
versions of Firefox. Next, I spent more time trying to get html5 video
working with Chrome and Firefox. I thought I was missing a video driver
or the browsers didn't support something or newer protocols weren't enabled
in their settings. Html5 video would play way too fast, like on fast forward,
and without any sound. The problem was that the alsa and pulse audio drivers
needed updating. The clue was found on some random website via Google Search
in a post by some guy saying his too fast, soundless html5 videos played at
normal speed once he killed the pulse audio process.
However, after updating them, Linux wouldn't boot into the XFCE's GUI. It
complained of a missing library. So, I tracked that down and installed.
Then, it complained of another. Ad ifinitum. I began wondering how an
install managed to delete numerous library files without wiping out the
entire library directory. It turns out that the updated files installed
XFCE components for a more recent version of the OS which uses a different
XFCE build and many more libraries ... So, I had to uninstall all of that,
reinstall the base XFCE files for my version of the OS.
Once that was done, I couldn't get the updated version of Chrome to start.
Apparently, older versions of Chrome would work as both user and root, but
the newer version has some type of sandboxing which won't work if logged
in as root such as when installing Chrome and testing it out ... Apparently,
this was "lockout" mechanism for root was done intentionally by the Chrome
developers but without them telling anyone. Unbelievable. Everyone who knows
anything about OSes know that *everything* is supposed to run and function
as root. Otherwise, there is no point to having a root account. The user
account is supposed to be restricted for safety. I'm spewing many
derogatory words in my mind in the direction of Chrome developers right now.
A week or two ago it is was a Windows 7 corrupted component base store,
which is apparently impossible to fix without reinstalling the entire OS.
None of the half dozen M$ recommended fixes work, and one online util
only partly fixed the issue. This is the conclusion I came too after
spending a few days worth of time attempting to do so. So, it remains
corrupted.
Now, I need to figure out why my supposedly IPV6 capable Linux kernel
seems to have absolutely no IPV6 functionality and why the OS has
no IPV6 modules.
None of this includes my own attempted programming pursuits ...
<EOT>
>>> 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?
Does the OS control all the ways the "app the browser is running" can use
those keys? If yes, i.e., if the OS controls the input boxes/fields even
though the app is using them, then there is nothing more to do. If no,
then the stream would need to be filtered or split so that the "app the
browser is running" won't receive them.
>>>> 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.
Only one element has focus. So, if the element with focus receives the
entire keyboard stream, then Alt-V, used for it's parent window, say,
will be passed to it. It would need to reject it since it can't use it.
Of course, in the hierarchy or chain of items for that window, there
are other items inbetween the one with focus and the parent window.
So, the key sequence would be passed from child, back through other
parent/children, until it reached the parent window, where it could
be used. This was a pass back method, instead of pass forward, or
pass directly.
Of course, this more along the lines of an object-oriented design
where each element has code associated with it that operates
somewhat independently of each other. If an app is all inclusive,
then the app would control each menu, tab, sub-window etc from the
same code. So, the app would see everything in the text-field and
Alt-V type sequences. The app would then have to decide when to
and when not to filter.
>>>> 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.
Sure, but preemptive multitasking already "wakes up" each element
periodically in a round-robbin style fashion.
I.e., instead of an alarm clock waiting for a rooster to crow (event)
once in the morning, the alarm clock goes off every nine minutes due
to only the snooze button working.
If you aren't going to use preemptive multitasking, perhaps prefering
cooperative multitasking instead, then you could wait for the event.
> 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.
With an interrupt driven processor and preemptive multitasking, the
code doesn't need to wait to be notified of an event. It will find
out within a few milliseconds of being given execution control if
there is anything for it to do by simple polling the buffers for
the data streams. Although it could pause or yield etc to reduce
wasting processor cycles doing "nothing" except polling. The loop
simply needs to poll if there any data is present or not.
loop
check if there is input data
if (input data is available) then handle data
pause or yield
The x86 hardware interrupt routines for the keyboard or mouse
would fill a buffer, which each loop polls for the data, i.e.,
checks to see if any is present.
This would be like using CHECK KEYSTROKE Bios Int 16h, Ah=01h.
If there is no keystroke, the code can do something else or
or check again or wait or halt or yield etc. If there is a
keystroke, it would call GET KEYSTROKE Bios Int 16h, Ah=00h.
If you called GET KEYSTROKE without calling CHECK KEYSTROKE
first, GET KEYSTROKE will wait until there is a key to return,
i.e., this waits for an event before proceeding.
> > 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.
As pointed out, with interrupt-driven hardware and preemptive
multitasking there's no need to wait for an event.
The interrupt routine isn't going to wake up the code and drive the
app's data input routine directly. It's going to stuff that data into
a buffer somewhere which is shared by the OS and the app.
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