Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> +This function is called with no arguments when Emacs notices that a
> +frame may have gotten or lost focus.  Focus events are delivered

"the focus may have moved to or from the frame." is how it usually
written in X documentation, and I think that is a little clearer.

Also, why not add the following as well:

  when no window manager is running, or inside child frames, the focus
  can also be set "implicitly" by the mouse pointer entering a frame.

WDYT?

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Gregory Heytings]

>> +This function is called with no arguments when Emacs notices that a
>> +frame may have gotten or lost focus.  Focus events are delivered
>
> "the focus may have moved to or from the frame." is how it usually 
> written in X documentation, and I think that is a little clearer.
>
> Also, why not add the following as well:
>
> when no window manager is running, or inside child frames, the focus can 
> also be set "implicitly" by the mouse pointer entering a frame.
>

There are other cases, though, such as window managers using a 
focus-follows-mouse policy.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>>> +This function is called with no arguments when Emacs notices that a
>>> +frame may have gotten or lost focus.  Focus events are delivered
>>
>> "the focus may have moved to or from the frame." is how it usually
>> written in X documentation, and I think that is a little clearer.

Hm...  I'm not sure that's clearer...

>> Also, why not add the following as well:
>>
>> when no window manager is running, or inside child frames, the focus
>> can also be set "implicitly" by the mouse pointer entering a frame.
>
> There are other cases, though, such as window managers using a
> focus-follows-mouse policy.

The original text was longer and tried to explain too much, I think --
it made it all sound very complex, scary and difficult to deal with.  So
I tried to make it short and purposefully vague instead of enumerating
all different things that may and may not have happened, because that
didn't seem helpful.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Gregory Heytings]

>
> The original text was longer and tried to explain too much, I think -- 
> it made it all sound very complex, scary and difficult to deal with. 
> So I tried to make it short and purposefully vague instead of 
> enumerating all different things that may and may not have happened, 
> because that didn't seem helpful.
>

Agreed, I don't think it's useful to give a more detailed list of cases 
there.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> There are other cases, though, such as window managers using a
> focus-follows-mouse policy.

Do people still use those?

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> There are other cases, though, such as window managers using a
>> focus-follows-mouse policy.
>
> Do people still use those?

I do on my desktop machine.  (Which uses twm. 😳)

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> There are other cases, though, such as window managers using a
>>> focus-follows-mouse policy.
>>
>> Do people still use those?
>
> I do on my desktop machine.  (Which uses twm. 😳)

Interesting, personally I think twm and uwm are obsolete window managers
lacking even the most basic Unicode support.

So things like _NET_WM_NAME do not work.  Oh well.

How about saying "under some situations, moving the mouse pointer into a
frame may also cause the @dfn{implicit focus} to move to that frame"
instead?

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Gregory Heytings]

>> There are other cases, though, such as window managers using a 
>> focus-follows-mouse policy.
>
> Do people still use those?
>

Yes.  IIRC Eli configured Windows to work that way.  Martin uses such a 
window manager (but I don't remember which one it is).  And myself.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Eli Zaretskii]

> Date: Wed, 21 Sep 2022 10:58:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> 
> >> There are other cases, though, such as window managers using a 
> >> focus-follows-mouse policy.
> >
> > Do people still use those?
> >
> 
> Yes.  IIRC Eli configured Windows to work that way.

Yes.  I actually don't understand how can people use some other
policy, when moving focus to another frame or a different application
requires that you click on its window.  That basically means yopu
never work with more than one frame/window.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes.  I actually don't understand how can people use some other
> policy, when moving focus to another frame or a different application
> requires that you click on its window.  That basically means yopu
> never work with more than one frame/window.

Interesting.

In the X world, we have mostly switched to "some other strategy",
because that is what MS Windows does by default (and people are as a
result used to.)

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  emacs-devel@gnu.org,
>   larsi@gnus.org
> Date: Wed, 21 Sep 2022 19:56:25 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes.  I actually don't understand how can people use some other
> > policy, when moving focus to another frame or a different application
> > requires that you click on its window.  That basically means yopu
> > never work with more than one frame/window.
> 
> Interesting.
> 
> In the X world, we have mostly switched to "some other strategy",
> because that is what MS Windows does by default (and people are as a
> result used to.)

Bad habits of people who don't necessarily know something better is
possible.

On every new Windows machine where I need to do something for more
than 5 minutes, I always configure it to implicitly give focus to a
window where the mouse pointer is (but not raise it), because that's
the only way to type into one window while reading something in
another (unless you have a huge display where both windows can be
shown side by side).

RE: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Drew Adams]

> On every new Windows machine where I need to do something for more
> than 5 minutes, I always configure it to implicitly give focus to a
> window where the mouse pointer is (but not raise it), because that's
> the only way to type into one window while reading something in
> another (unless you have a huge display where both windows can be
> shown side by side).

Is that something done easily, e.g. by a standard
setting somewhere?  I'd be interested in turning
that on, if it's easy to do (e.g., no programming
or registry fiddling).

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "gregory@heytings.org" <gregory@heytings.org>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>,
>         "larsi@gnus.org" <larsi@gnus.org>
> Date: Wed, 21 Sep 2022 16:19:42 +0000
> 
> > On every new Windows machine where I need to do something for more
> > than 5 minutes, I always configure it to implicitly give focus to a
> > window where the mouse pointer is (but not raise it), because that's
> > the only way to type into one window while reading something in
> > another (unless you have a huge display where both windows can be
> > shown side by side).
> 
> Is that something done easily, e.g. by a standard
> setting somewhere?

 Control Panel > Ease of Access > Change How Your Mouse Works

RE: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Drew Adams]

> > Is that something done easily, e.g. by a standard
> > setting somewhere?
> 
>  Control Panel > Ease of Access > Change How Your Mouse Works

Thanks.

I just tried that, but it also seems to raise
the focused window, which I'm not keen on.

Very good to know that this is available, though.
Thx.

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "gregory@heytings.org"
> 	<gregory@heytings.org>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>         "larsi@gnus.org" <larsi@gnus.org>
> Date: Wed, 21 Sep 2022 17:23:48 +0000
> 
> >  Control Panel > Ease of Access > Change How Your Mouse Works
> 
> Thanks.
> 
> I just tried that, but it also seems to raise
> the focused window, which I'm not keen on.

There should be a setting to disable that, AFAIR.

If not, try this applet, it surely can do one without the other:

  https://joelpurra.com/projects/X-Mouse_Controls/

RE: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Drew Adams]

> > >  Control Panel > Ease of Access > Change How Your Mouse Works
> >
> > Thanks.
> > I just tried that, but it also seems to raise
> > the focused window, which I'm not keen on.
> 
> There should be a setting to disable that, AFAIR.
> 
> If not, try this applet, it surely can do one without the other:
> 
>   https://joelpurra.com/projects/X-Mouse_Controls/

Thanks, Eli.  I'll hang onto this info.  I doubt
I'll try using the applet, but I appreciate knowing
about it.  By now I'm used to clicking to focus,
but I do miss having the focus follow the mouse,
which I recall from UNIX/X Window behavior long ago.

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> Thanks, Eli.  I'll hang onto this info.  I doubt
> I'll try using the applet, but I appreciate knowing
> about it.  By now I'm used to clicking to focus,
> but 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.

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[chad]

[-- 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 --]

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Eli Zaretskii]

> 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.

Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

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.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Gregory Heytings]

>
> I actually don't understand how can people use some other policy, when 
> moving focus to another frame or a different application requires that 
> you click on its window.  That basically means you never work with more 
> than one frame/window.
>

The focus-follows-mouse policy is indeed superior for advanced users, but 
I think it must be admitted that it isn't appropriate for regular users. 
It breaks the "desk" mental model, with which you always act on the 
topmost element, which is the one that is fully visible.  With the 
focus-follows-mouse policy you can act on any element that is partly 
visible, but that means that you can e.g. type on the keyboard without 
seeing any visible effect on the screen.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Andreas Schwab]

On Sep 21 2022, Gregory Heytings wrote:

> The focus-follows-mouse policy is indeed superior for advanced users, but
> I think it must be admitted that it isn't appropriate for regular
> users. It breaks the "desk" mental model, with which you always act on the
> topmost element, which is the one that is fully visible.  With the
> focus-follows-mouse policy you can act on any element that is partly
> visible, but that means that you can e.g. type on the keyboard without
> seeing any visible effect on the screen.

Though this is the raise-on-focus option, which is independent from
focus-follows-mouse vs. click-to-focus.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Gregory Heytings]

>> The focus-follows-mouse policy is indeed superior for advanced users, 
>> but I think it must be admitted that it isn't appropriate for regular 
>> users. It breaks the "desk" mental model, with which you always act on 
>> the topmost element, which is the one that is fully visible.  With the 
>> focus-follows-mouse policy you can act on any element that is partly 
>> visible, but that means that you can e.g. type on the keyboard without 
>> seeing any visible effect on the screen.
>
> Though this is the raise-on-focus option, which is independent from 
> focus-follows-mouse vs. click-to-focus.
>

It depends on how you look at it, I guess.  I would rather present it as a 
sub-option:

1. click-to-focus (default behavior on Windows and macOS)

2. focus-follows-mouse (traditional behavior on X11)

2.1. raise-on-click (default)

2.2. raise-on-focus

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[tomas]

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

On Wed, Sep 21, 2022 at 03:53:08PM +0000, Gregory Heytings wrote:
> 
> > > The focus-follows-mouse policy is indeed superior for advanced
> > > users, but I think it must be admitted that it isn't appropriate for
> > > regular users [...]

I wouldn't put that in a hierarchy like that. It's just how accustomed
the user is to a set of UI conventions. Besides, that makes your
hypothetical "regular user" identical with the "windows user", which
is a sneaky way of cementing Microsoft's supremacy. Don't let us do
their job for them. They are unfortunately good enough at it without
us helping :)

One could argue that "modern Windows" with its several layers of
UI "languages" is only for "advanced users". You have to know that
the first click on an "old" Windows app does nothing but bring
the focus to that one (e.g. Terminal), whereas a "modern" app (a
browser for example) goes wild on the first click. For me, very
much advanced indeed (I keep looking for harmless places on some
wacky web page to click on to be able to type there).

> > Though this is the raise-on-focus option, which is independent from
> > focus-follows-mouse vs. click-to-focus.

You are right, Andreas -- I do appreciate both.

> It depends on how you look at it, I guess.  I would rather present it as a
> sub-option:
> 
> 1. click-to-focus (default behavior on Windows and macOS)
> 
> 2. focus-follows-mouse (traditional behavior on X11)
> 
> 2.1. raise-on-click (default)
> 
> 2.2. raise-on-focus

Theoretically, of course, one might conceive click-to-focus /without/
raise-on-focus. But I haven't seen that for a long time.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Robert Pluim]

>>>>> On Thu, 22 Sep 2022 06:29:56 +0200, <tomas@tuxteam.de> said:

    tomas> One could argue that "modern Windows" with its several layers of
    tomas> UI "languages" is only for "advanced users". You have to know that
    tomas> the first click on an "old" Windows app does nothing but bring
    tomas> the focus to that one (e.g. Terminal), whereas a "modern" app (a
    tomas> browser for example) goes wild on the first click. For me, very
    tomas> much advanced indeed (I keep looking for harmless places on some
    tomas> wacky web page to click on to be able to type there).

Web browsers are particularly annoying here: clicking in the url bar
will select the entire url, making you click again to place the cursor
where you want to make the edit (does that make me an "advanced user"?
😀)

    >> > Though this is the raise-on-focus option, which is independent from
    >> > focus-follows-mouse vs. click-to-focus.

    tomas> You are right, Andreas -- I do appreciate both.

    >> It depends on how you look at it, I guess.  I would rather present it as a
    >> sub-option:
    >> 
    >> 1. click-to-focus (default behavior on Windows and macOS)
    >>

macOS these days is not strictly click-to-focus, it has hybrid
focus-under-mouse (which actually generally does the right thing,
except when you have two overlapping windows).

Robert
-- 

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> 2.1. raise-on-click (default)
>
> 2.2. raise-on-focus

The default X behavior is to neither raise the window on click, nor on
focus.  In fact, the X server does not implement any default raising
behavior at all.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[Visuwesh]

[புதன் செப்டம்பர் 21, 2022] Po Lu wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> There are other cases, though, such as window managers using a
>> focus-follows-mouse policy.
>
> Do people still use those?

Yes.  I'm a happy user of focus-follows-mouse=t and
mouse-autoselect-window=t.

Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation

[tomas]

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

On Wed, Sep 21, 2022 at 06:51:31PM +0800, Po Lu wrote:
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > There are other cases, though, such as window managers using a
> > focus-follows-mouse policy.
> 
> Do people still use those?

I very much do. Fvwm (currently I'm forced to half-use Windows and
it drives me nuts).

Among other things I do appreciate that a window can have focus
while not being on top (limited screen space).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]