bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/14/2010 12:50 AM, Lennart Borgman wrote:
> On Sun, Nov 14, 2010 at 12:20 AM, Alain Knaff <alain@knaff.lu> wrote:
> 
>>>
>>> I think you refer to another problem: The sync problem of keyboard
>>> input and window focus.
>>
>> I'm concerned about keyboard focus here, i.e. which window gets the
>> keyboard input events. I vaguely remember having read that there are
>> other kinds of focus than keyboard focus (window focus?), but I'm unsure
>> what they do exactly, and am (for this discussion...) not overly
>> concerned with these.
> 
> I am beeing very imprecise here. What you should distinguish is which
> window/application takes the keyboard input and which window is on top
> on the screen. (The latter means that it will take mouse input inside
> the window.)

ok, I see. Yes, in my case I'm more concerned about keyboard input than
about which window is on top.

>>> When a new program is launched and it is going
>>> to grab focus it is difficult to sync.
>>
>> I think this is exactly the reason why focus changes should be initiated
>> by the user.
>>
>> Keyboard input is context sensitive.
> 
> All input is.

:-)

>> .. Hence the rule that all
>> keyboard focus changes should be initiated (or at least acknowledged) by
>> the user, who is the source of keyboard input.
> 
> Yes, but there seem to be different opinions for what this mean. In
> many circumstances launching an application means you want to use it
> and therefore wants it to have input focus. But not in your use cases
> of course.

Maybe it's dangerous to make too many assumptions, and preferable to
rely on explicit actions rather than second-guessing the user. Maybe the
user was just feeling hot? :-)

>> So, the app only gets keyboard focus when the user gives it keyboard
>> focus. Period.
> 
> Unfortunately that is not clear, see above.

Why does this have to feel like a cheesy rape trial? :-)

>> Sometimes an application may want to get the user's attention (to inform
>> him that they are "done", or that some error condition needs a
>> decision). The proper way to do this is to flash their border, or their
>> outline in the desktop pager, but never to forcefully grab keyboard focus.
> 
> It depends on the window manager what the proper way is. It is
> actually specified for some of them.

Hopefully there is a standardized API for "get user's attention
unintrusively"...

[...]
>> I'm not really sure what background has to do with it... Background only
>> affects which process should get signals if you press Ctrl-C in the
>> terminal window, it doesn't have anything to do with what other windows
>> these programs may spawn, and what they do with these...
> 
> So this means that this part of the semantic does not apply here.

No, not really...

> I do
> not know if there is anything else that can glue things together.
> Maybe the semantic has not been specified clearly.

Why can't the answer to "when is it allowed to grab focus" simply be
"never"?

>>> It would seem natural to me that the window manager respected the
>>> users decision to run a program in the background.
>>
>> How would the window manager even know which program was in the
>> background in the general case? Hint: it may not even run on the same
>> machine. And even in the local case, not all shells may manage
>> foreground/background in the same way. And in many cases, the
>> application might not even have been started by an interactive shell in
>> the first place...
> 
> These are good point, but different people and different situations
> might require different solutions. However I do not know anything
> about what has been done on that level.

Somehow, other apps don't feel the need to mess in a similar way with
keyboard focus.

Now, I understand that it is a windows compatibility thingy. But then,
why is this code activated on non-Windows platforms? Wouldn't it be
possible to make everybody happy by just bracketing it with #idef w32
... #endif, or something similar?

> 
>> And the compilation from my example would probably been have started in
>> the foreground in its shell, in order not to mess up its copious output...
>>
>> And why should it be the window manager's job to police apps?
> 
> I think it is about cooperation and some pieces might be missing, see above.

Yeah, that's the point. Window manager assume well-behaved (cooperative)
apps, but apparently some aren't. Hence the need of "focus stealing
prevention" and similar settings, which unfortunately don't always work
(either they are ineffective, or have undesirable side-effects...)

> 
>>> (But I do not know
>>> if there is enough semantic/syntax for that for the shells. I simply
>>> no very little about the *nix shells. And I even do not know about
>>> this for the w32 shells.)
>>
>> On Linux, the appropriate behavior would be:
>>
>> 1. If the shell's name ends in sh, then do not let the app forcefully
>> grab keyboard focus
>> 2. And for those rare shells whose name doesn't end in sh, do not let
>> the app forcefully grab keyboard focus either :-)
> 
> Simple enough ;-)
> 
> But maybe not flexible enough.

Well, it's simple enough for the 99% of the other Linux applications out
there...

>>>> But apparently, there is more than one method to grab focus, and some
>>>> aren't blocked by this
>>>
>>> Yes. In some situations the users choice must be overriden.
>>
>> Which would these be?
> 
> Urgent messages.

Wouldn't "flashing" the app's outline be more appropriate? Just imagine
emacs wanted to display the urgent message "Disk filling up. Is it ok to
delete file xyz.abc to make space (y/n)", but the user just started to
type "yesterday" into another app?

>>> But on w32
>>> there has been many changes to avoid that this is used when it should
>>> not be used. (In the case of emacsclient it should be used.)
>>
>> Maybe all these Windows specific hacks should be bracketed by #ifdef W32
>> ... #endif so that they don't bother users of other platforms?
> 
> I don't think this is a w32 specific problem at all.

Well, I think it is. According to you, on Windows, most apps grab focus
when launched. From my observation, on Linux almost none do. Shouldn't
that tell you something? Why does emacs want to be the white elephant here?

> See above. There
> are different solutions and your solution tends to be best for a
> programmer, at least it looks so to me. However most users are not
> programmers (and maybe that is part of the problem for GNU/Linux that
> opinions from programmers does not respect other users needs and
> therefore makes the platform unnecessary impopular).

We have a saying here in Luxembourg: "Mir wölle bleiwe wat mir sin" ("We
want to stay what we are"). What good is a popular Linux if it has had
to sell its soul in order to become so? If I want Windows, I can go out
into a shop and buy it right now. I don't need to transform Linux into
Windows.

If popularity means becoming flaky and unreliable, I prefer to live
without it.

... and if you are really concerned about pandering to Windows users
that migrated to Linux, then bracket the offending code with

if(getenv("WINDOWS_COMPATIBILITY")) {
  ...
}

instead. So those users who really want this can set the
WINDOWS_COMPATIBILITY environment variable to 1...

Hey, maybe we can even get a standard rolling to agree on a same
environment variable for all applications that might feel the need to
transform Linux into Windows :-)

> 
>> In simpler words: we chose to use Linux because we prefer the way it
>> works. Please don't make it behave like Windows :-)
> 
> There are bigger issues than this. The whole platform GNU/Linux exists
> because people want a free platform. Whether it should behave like w32
> is something that should be evaluated mainly against this.

IMHO, solidity, usability and reliability played as big a role in the
popularity of Linux (amongst its primary audience) than its freeness (be
it as in beer or as in speech). Why do we have to throw away our
advantages to pander to the masses?

Alain