unofficial mirror of emacs-tangents@gnu.org
 help / color / mirror / Atom feed
* Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation
       [not found]                           ` <87sfkkdspw.fsf@yahoo.com>
@ 2022-09-22 16:16                             ` chad
  2022-09-22 16:24                               ` Eli Zaretskii
  2022-09-23  0:36                               ` Po Lu
  0 siblings, 2 replies; 3+ messages in thread
From: chad @ 2022-09-22 16:16 UTC (permalink / raw)
  To: emacs-tangents; +Cc: Drew Adams, Eli Zaretskii, gregory, larsi, Po Lu

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

Moved to emacs-tangents.

On Wed, Sep 21, 2022 at 10:54 PM Po Lu <luangruo@yahoo.com> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
> > [...] I do miss having the focus follow the mouse,
> > which I recall from UNIX/X Window behavior long ago.
>
> Interesting.  Personally, I don't miss that behavior at all, having
> spent a lot of time on older X setups running uwm/twm in the past, one
> complaint being the input focus randomly moving to other windows while
> typing upon accidental mouse motion (typically caused by dirty mouse
> balls.)
>
> It is also rather painful to program for, especially when your program
> uses window nesting liberally.
>

Back in the day, X programs knew how to distinguish between windows
appearing/disappearing on their own and the window under the mouse being
changed by the window manager, and focus could be managed appropriately.
WM's of the time also had (configurable) thresholds for whether such
accidental movements would trigger focus changes or not.

It was a more complicated, much more powerful model, but then the Windows95
"look and feel" took over roughly everything, Apple fused Mach, FreeBSD,
and NeXTSTEP together into a workable alternative OS (from a UI
perspective), and GUIs moved strongly away from power towards
approachability. Then higher-level window/display/GUI systems started
stomping out any possible diversity in capability in the name of some
combination of "easier UI for less experienced users" and "put those
expensive GPUs to use".

As near as I can tell, this is how, for one glaring example, Gnome got to
its current state, spawning things like XFCE, Cinnamon, and MATE along the
way. Much like how Google, Microsoft, and a handful of others have made it
practically impossible to run a private email server these days, GNOME,
Wayland, and "choose: Win95 or Mac OS appearance" have made the days of
things like gwm and exwm all but numbered. While there are
definitely upsides, this is definitely not a strictly better world.

~Chad

[-- Attachment #2: Type: text/html, Size: 2585 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation
  2022-09-22 16:16                             ` [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation chad
@ 2022-09-22 16:24                               ` Eli Zaretskii
  2022-09-23  0:36                               ` Po Lu
  1 sibling, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2022-09-22 16:24 UTC (permalink / raw)
  To: chad; +Cc: emacs-tangents, drew.adams, gregory, larsi, luangruo

> From: chad <yandros@gmail.com>
> Date: Thu, 22 Sep 2022 12:16:59 -0400
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>, 
> 	"gregory@heytings.org" <gregory@heytings.org>, "larsi@gnus.org" <larsi@gnus.org>, Po Lu <luangruo@yahoo.com>
> 
> Back in the day, X programs knew how to distinguish between windows appearing/disappearing on their own
> and the window under the mouse being changed by the window manager, and focus could be managed
> appropriately. WM's of the time also had (configurable) thresholds for whether such accidental movements
> would trigger focus changes or not.

Ironically, the MS-Windows implementation of this feature also has
such thresholds.  Like how much time should the mouse hover over a
window before that window gets focus.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation
  2022-09-22 16:16                             ` [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation chad
  2022-09-22 16:24                               ` Eli Zaretskii
@ 2022-09-23  0:36                               ` Po Lu
  1 sibling, 0 replies; 3+ messages in thread
From: Po Lu @ 2022-09-23  0:36 UTC (permalink / raw)
  To: chad; +Cc: emacs-tangents, Drew Adams, Eli Zaretskii, gregory, larsi

chad <yandros@gmail.com> writes:

> Back in the day, X programs knew how to distinguish between windows
> appearing/disappearing on their own and the window under the mouse
> being changed by the window manager, and focus could be managed
> appropriately.  WM's of the time also had (configurable) thresholds
> for whether such accidental movements would trigger focus changes or
> not.

"Appearing" or "disappearing" accidental movements?

The reason it is such a pain to manage is that the focus does not end up
in the toplevel window (with WM_TAKE_FOCUS messages), always follows the
mouse regardless of the value of the input flag in the window manager
hints property, and is delivered in terms of crossing events with the
focus flag set.  A single master device can also have both explicit and
implicit focus at any given time.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-09-23  0:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <166368675497.15121.15081377110947098460@vcs2.savannah.gnu.org>
     [not found] ` <20220920151239.61451C00871@vcs2.savannah.gnu.org>
     [not found]   ` <87czbpihyl.fsf@yahoo.com>
     [not found]     ` <2d1b683c2245a1b1035c@heytings.org>
     [not found]       ` <87v8phgfv0.fsf@yahoo.com>
     [not found]         ` <2d1b683c22ba04ac1445@heytings.org>
     [not found]           ` <83h711ueqo.fsf@gnu.org>
     [not found]             ` <87pmfpeyae.fsf@yahoo.com>
     [not found]               ` <83czbovqfs.fsf@gnu.org>
     [not found]                 ` <SJ0PR10MB5488616B68EE40EB97B05E47F34F9@SJ0PR10MB5488.namprd10.prod.outlook.com>
     [not found]                   ` <83r104u1k3.fsf@gnu.org>
     [not found]                     ` <SJ0PR10MB548837BEDE6B0D5856BBED3DF34F9@SJ0PR10MB5488.namprd10.prod.outlook.com>
     [not found]                       ` <83pmfotyo8.fsf@gnu.org>
     [not found]                         ` <SJ0PR10MB54881B39C26E2D30F14EA6FCF34F9@SJ0PR10MB5488.namprd10.prod.outlook.com>
     [not found]                           ` <87sfkkdspw.fsf@yahoo.com>
2022-09-22 16:16                             ` [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation chad
2022-09-22 16:24                               ` Eli Zaretskii
2022-09-23  0:36                               ` Po Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).