On 1/6/10 1:41 PM, Adam Jackson wrote:
> On Wed, 2010-01-06 at 17:32 +0000, Andrew Haley wrote:
>> On 01/06/2010 05:00 PM, Adam Jackson wrote:
>>> On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote:
>>>> I'd go with "don't let a different app steal focus". Windows for the
>>>> same currently focused app are allowed to. This works pretty well under
>>>> Mac OS X. Might depend on some of the stuff being done by the
>>>> gnome-shell folks though, to be able to group windows together as
>>>> belonging to the same process/application to be able to do it Right
>>>> under a Linux DE...
>>>
>>> Now make that work for the (not uncommon) case of clicking a link in evo
>>> or control-clicking one in gnome-terminal and expecting firefox to pop
>>> forward with that page.

Well, this works right in Mac OS X too...

>> Er, why would you want Firefox to be holding focus when it pops up? I can't
>> think of any reason.
>
> To pick an example from my daily life: Someone pastes a bugzilla URL at
> me on IRC, and I need to go scroll through it to see what they're
> talking about.

But that's a requested "please change focus" event, vs. something that
happened in the background and decided to pop over the top of what you
were doing while you were in the middle of typing. Please bear in mind
that I have absolutely no clue how hard it is to distinguish between
these sorts of things in X/Gnome/Linux... All I know is that other
operating systems manage to get this right (or at least, righter than we
do).

--
Jarod Wilson
jarod@redhat.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 01/06/2010 01:27 PM, Fulko Hew wrote:



On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax@redhat.com
<mailto:ajax@redhat.com>> wrote:

On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax@redhat.com <mailto:ajax@redhat.com>):
> > On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote:
> > > I'd go with "don't let a different app steal focus". Windows
for the
> > > same currently focused app are allowed to. This works pretty
well under
> > > Mac OS X. Might depend on some of the stuff being done by the
> > > gnome-shell folks though, to be able to group windows together as
> > > belonging to the same process/application to be able to do it
Right
> > > under a Linux DE...
> >
> > Now make that work for the (not uncommon) case of clicking a
link in evo
> > or control-clicking one in gnome-terminal and expecting firefox
to pop
> > forward with that page.
>
> And now make that work for the case where firefox decides to take 10
> secs to start up, so you start in another window, then firefox jumps
> up and grabs focus. Thanks.
>
> There is no case where I want a new window or popup to take
focus. Makes
> for an easy algorithm. (hitting r in mutt is not a problem

There is no case where _you_ want this, sure.


I'd say... only take focus if its a child/creation of the window
currently in focus.


Some people also do things like set EDITOR=gvim and set their mail
client to run $EDITOR when composing a message.

There are cases where many people do expect and even desire for pop-ups
to take focus, and they're not necessarily even crazy.

--
Peter

Space, is big. Really big. You just won't believe how vastly hugely
mindbogglingly big it is. I mean you may think it's a long way down the
road to the chemist, but that's just peanuts to space.
-- The Hitchhiker's Guide to the Galaxy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Jan 06, 2010 at 02:24:17PM -0500, Adam Jackson wrote:
> On Wed, 2010-01-06 at 13:27 -0500, Fulko Hew wrote:
>
> > On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax@redhat.com> wrote:
> > There is no case where _you_ want this, sure.
> >
> > I'd say... only take focus if its a child/creation of the window
> > currently in focus.
>
> "creation of" is not something that's particularly well defined in X.
> Child windows are clipped to (wholly contained within) their parent, so
> in the evolution example from earlier, the compose window is a child of
> the root window, not of the mailbox view window. So at window creation
> time, there's no obvious relationship between the compose and mailbox
> windows.
>
> They do happen to have the same WM_CLASS and WM_CLIENT_LEADER window
> properties. But that still only addresses automatic focus changes
> within a single application. Automatic focus changes across apps is
> probably desirable; otherwise, nothing you launch from the gnome panel
> will launch focused, which is rather absurd.

How about making the gnome-panel give away its focus to the newly
created window? Within the gnome-panel, it should be pretty obvious
which actions should give away the focus and which should not. I do not
know, how easy to implement it is, though.

Regards
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 01/06/2010 03:21 PM, Till Maas wrote:


How about making the gnome-panel give away its focus to the newly
created window? Within the gnome-panel, it should be pretty obvious
which actions should give away the focus and which should not. I do not
know, how easy to implement it is, though.


That's pretty difficult for a launcher - how does the panel know that
the launcher is going to create a window vs which is not? And how does
it know what window it is? If you click on the firefox launcher, it
runs a shell script. That script (may) eventually run an X
application, but it in itself isn't one. What's the launcher telling
the wm in that case under your proposed model?

--
Peter

Space, is big. Really big. You just won't believe how vastly hugely
mindbogglingly big it is. I mean you may think it's a long way down the
road to the chemist, but that's just peanuts to space.
-- The Hitchhiker's Guide to the Galaxy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2010-01-06 at 16:00 +0100, nodata wrote:
> I'd like to suggest an enhancement for Fedora 13: nothing should ever
> steal focus from the window I am typing in. If I am typing in a shell
> window, or in a word processor, or an e-mail, nothing should ever take
> keyboard focus away from that window.
>
> Clearly I'm missing something, otherwise we would have this, hence the
> posting to the list

I'm not sure what you are missing, but I know what I'm missing here - a
description of when exactly focus was stolen from you that was a
problem.

In almost all cases, if you are typing into one application in Fedora,
and a window pops up from another application and steals away your
focus, and your typing goes to the wrong place, that's a bug that should
be filed against one of:

- The application that popped up a window
- The application that you are typing into
- The window manager

With the most likely candidate being the first one. If you run into such
problems and you are using GNOME with Metacity (or gnome-shell and
Mutter), please feel free to file bugs against Metacity and I'll help
you figure out where they should be reassigned.

There are also a number of GConf options for Metacity that can be set to
modify the exact behavior; these are mostly, however, intended as
workarounds for people using closed source applications that can't be
fixed properly. When all the applications are under our control, it
should "just work".

- Owen


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Am 2010-01-06 18:17, schrieb Matthew Booth:

On 06/01/10 17:00, Adam Jackson wrote:

On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote:

On 1/6/10 11:07 AM, Adam Jackson wrote:

PGA.

Here's the challenge. To reply to this mail, I hit control-shift-r in
one evo window, and evo opened a new window for me to compose into. Get
it? I typed into one window, and then started typing into another, and
that's exactly what was desired. If the window manager suppressed focus
changes on the basis of "you were just typing into some other window,
this must be a focus steal", then the new compose window would have
mapped unfocused, and I'd have to have alt-tabbed to get to it.

So if you can come up with an algorithm that can reliably classify
focus
change requests as "stealing" or not, then great.


I'd go with "don't let a different app steal focus". Windows for the
same currently focused app are allowed to. This works pretty well under
Mac OS X. Might depend on some of the stuff being done by the
gnome-shell folks though, to be able to group windows together as
belonging to the same process/application to be able to do it Right
under a Linux DE...


Now make that work for the (not uncommon) case of clicking a link in evo
or control-clicking one in gnome-terminal and expecting firefox to pop
forward with that page.


There is one situation where the absolute of $SUBJECT is required:
password windows. I end up typing passwords wholly or partially into
other windows on a reasonably regular basis because of this.

Matt


This is my primary motivation for bringing this up again.

I either start typing a password into a dialog then something steals
focus and the password is in cleartext, or or the other way round: I
start typing something in one apps, a password dialog pops up, and I end
up typing non-passwords there. Ugh. Dangerous and not good.


This must be solvable, not just for password entry.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax@redhat.com):
> > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> > > Quoting Adam Jackson (ajax@redhat.com):

> > > There is no case where I want a new window or popup to take focus. Makes
> > > for an easy algorithm. (hitting r in mutt is not a problem
> >
> > There is no case where _you_ want this, sure.
>
> Yes, exactly. You're saying that
> 1. there are cases where you want a window to pop up
> 2. it's too complicated to figure out which windows should pop up
> 3. so windows should always pop up, no point being configurable
>
> and ridiculing us over (2). I'm saying there are no cases where I want
> a popup, so we can easily have 2 configurable options: always have windows
> pop up and take focus, never have them do so.
>
> That's all.

This discussion would make a whole lot more sense if the current
behavior was actually that windows always pop up and steal focus.

It isn't.

We actually have a mechanism that works pretty well for knowing when
focus should be stolen and when not. (Not a Fedora or GNOME method, but
one encoded in the freedesktop.org standards.)

In simple terms, it works by comparing timestamps:

- What was the timestamp of the user action that triggered the
window to pop up?

- What was the timestamp of the last user action with the currently
focused window?

If the timestamp for the user action that triggered the popup is newer
than the timestamp of the last user action with the currently focused
window, then focus is transferred.

This isn't 100% perfect ... it's no substitute for electrodes implanted
in the user's brain.

But it's a pretty darn good method when all the actors are playing by
the rules. So, when things go wrong, our first step shouldn't be adding
a configuration variable, but trying to figure out if there is a bug
that needs to be fixed.

- Owen


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Jan 06, 2010 at 03:32:26PM -0500, Peter Jones wrote:
> On 01/06/2010 03:21 PM, Till Maas wrote:
>
>> How about making the gnome-panel give away its focus to the newly
>> created window? Within the gnome-panel, it should be pretty obvious
>> which actions should give away the focus and which should not. I do not
>> know, how easy to implement it is, though.
>
> That's pretty difficult for a launcher - how does the panel know that
> the launcher is going to create a window vs which is not? And how does
> it know what window it is? If you click on the firefox launcher, it
> runs a shell script. That script (may) eventually run an X
> application, but it in itself isn't one. What's the launcher telling
> the wm in that case under your proposed model?

It could tell the WM, if a new window opens within the next second,
focus it. I guess this should work in many cases. But in a better world,
the launcher could maybe tell the WM if this process or a child of it
creates a new window, then give the focus to it.
Btw. I do not like it in general if a newly started application does not
immediately open a new window and is ready to be used, but instead takes
several seconds to startup and then take away focus if I am already
doing something else then to wait for it. This is also why I propose a
timeout for the focus giveaway.

Regards
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Am 2010-01-06 21:59, schrieb Owen Taylor:

On Wed, 2010-01-06 at 16:00 +0100, nodata wrote:

I'd like to suggest an enhancement for Fedora 13: nothing should ever
steal focus from the window I am typing in. If I am typing in a shell
window, or in a word processor, or an e-mail, nothing should ever take
keyboard focus away from that window.

Clearly I'm missing something, otherwise we would have this, hence the
posting to the list


I'm not sure what you are missing, but I know what I'm missing here - a
description of when exactly focus was stolen from you that was a
problem.

In almost all cases, if you are typing into one application in Fedora,
and a window pops up from another application and steals away your
focus, and your typing goes to the wrong place, that's a bug that should
be filed against one of:

- The application that popped up a window
- The application that you are typing into
- The window manager

With the most likely candidate being the first one. If you run into such
problems and you are using GNOME with Metacity (or gnome-shell and
Mutter), please feel free to file bugs against Metacity and I'll help
you figure out where they should be reassigned.

There are also a number of GConf options for Metacity that can be set to
modify the exact behavior; these are mostly, however, intended as
workarounds for people using closed source applications that can't be
fixed properly. When all the applications are under our control, it
should "just work".

- Owen



I'll start a list and report back.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2010-01-06 at 22:12 +0100, Till Maas wrote:
> On Wed, Jan 06, 2010 at 03:32:26PM -0500, Peter Jones wrote:
> > On 01/06/2010 03:21 PM, Till Maas wrote:
> >
> >> How about making the gnome-panel give away its focus to the newly
> >> created window? Within the gnome-panel, it should be pretty obvious
> >> which actions should give away the focus and which should not. I do not
> >> know, how easy to implement it is, though.
> >
> > That's pretty difficult for a launcher - how does the panel know that
> > the launcher is going to create a window vs which is not? And how does
> > it know what window it is? If you click on the firefox launcher, it
> > runs a shell script. That script (may) eventually run an X
> > application, but it in itself isn't one. What's the launcher telling
> > the wm in that case under your proposed model?
>
> It could tell the WM, if a new window opens within the next second,
> focus it. I guess this should work in many cases. But in a better world,
> the launcher could maybe tell the WM if this process or a child of it
> creates a new window, then give the focus to it.
> Btw. I do not like it in general if a newly started application does not
> immediately open a new window and is ready to be used, but instead takes
> several seconds to startup and then take away focus if I am already
> doing something else then to wait for it. This is also why I propose a
> timeout for the focus giveaway.

We already have ways of distinguishing these cases, and don't need to
invent new mechanisms.

- Owen


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list