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.

[Lennart Borgman]

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

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

> So, the app only gets keyboard focus when the user gives it keyboard
> focus. Period.

Unfortunately that is not clear, see above.

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

>> However I would say that the compilation program should not get window
>> and keyboard focus automatically.
>
> Yes, that's my point. No part of, or program spawned by the compilation
> should just grab keyboard focus.
>
>> There should be a way to avoid it.
..
>> And isn't there actually that? Can't you start those programs in the
>> background from most shells?
>
> 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. I do
not know if there is anything else that can glue things together.
Maybe the semantic has not been specified clearly.


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

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

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

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

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

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