9 a.m.
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 :)
9:20 a.m.
On Wed, Jan 6, 2010 at 9:00 AM, nodata <lsof(a)nodata.co.uk> 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 :)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I'm pretty sure there are a number of window managers that will do
this, and metacity might even have this option but just doesn't do it
by default.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
9:43 a.m.
Le 06/01/2010 16:20, Adam Miller a écrit :
I'm pretty sure there are a number of window managers that will do
this, and metacity might even have this option but just doesn't do it
by default.
-AdamM
If i remember well, focus stealing prevention was a Fedora Core 4/GNOME
2.10 feature (bz #138453) .
I think t's still enabled by default in Metacity, but maybe there are
some regressions.
H.
10:19 a.m.
On 06/01/2010 15:43, Haïkel Guémar wrote:
If i remember well, focus stealing prevention was a Fedora Core
4/GNOME
2.10 feature (bz #138453) .
I think t's still enabled by default in Metacity, but maybe there are
some regressions.
Works here, but only if desktop effects are not enabled.
-Phil
10:38 a.m.
Le 06/01/2010 17:19, Philip Heron a écrit :
On 06/01/2010 15:43, Haïkel Guémar wrote:
> If i remember well, focus stealing prevention was a Fedora Core 4/GNOME
> 2.10 feature (bz #138453) .
> I think t's still enabled by default in Metacity, but maybe there are
> some regressions.
Works here, but only if desktop effects are not enabled.
-Phil
D-E enables either compiz or gnome-shell since F-12, the first one is a
different windows manager, the second is based on Mutter a fork of
Metacity (therefore, focus stealing prevention should work).
11:41 a.m.
ons 2010-01-06 klockan 17:38 +0100 skrev Haïkel Guémar:
D-E enables either compiz or gnome-shell since F-12, the first one is
a
different windows manager, the second is based on Mutter a fork of
Metacity (therefore, focus stealing prevention should work).
I've considered suggesting that Mutter be added to the Desktop Effects
settings. It's better than Metacity with compositing enabled. The catch
though is that it's also slower than compositing Metacity on some
hardware. Need to figure out why...
/abo
10:07 a.m.
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 :)
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.
- ajax
10:36 a.m.
On 1/6/10 11:07 AM, Adam Jackson wrote:
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 :)
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...
--
Jarod Wilson
jarod(a)redhat.com
11 a.m.
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.
- ajax
11:17 a.m.
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
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
3:01 p.m.
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.
5:58 p.m.
nodata writes:
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.
I think this is an application's responsibility. An application should
properly specified when it pops up a window whether it should take user
input focus.
If something improperly steals focus from another application, I would
consider that an application bug,
11:20 a.m.
On Wed, 2010-01-06 at 12:00 -0500, Adam Jackson wrote:
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.
That suggestion also fails for the PolicyKit dialog, and anything
similar. (And, unsurprisingly, I've been seeing that dialog pop-up
behind the window that caused it...)
Tim.
*/
11:23 a.m.
Quoting Adam Jackson (ajax(a)redhat.com):
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.
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 :)
-serge
12:08 p.m.
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
Quoting Adam Jackson (ajax(a)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.
- ajax
12:27 p.m.
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax(a)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.
1:24 p.m.
On Wed, 2010-01-06 at 13:27 -0500, Fulko Hew wrote:
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)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.
- ajax
2:21 p.m.
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(a)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
2:32 p.m.
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
3:12 p.m.
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
4:05 p.m.
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
10:07 p.m.
On Wed, Jan 06, 2010 at 02:24:17PM -0500, Adam Jackson wrote:
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.
Not absurd at all. I certainly wouldn't want any app I launch from a panel
to start focused.
-Toshio
2:06 p.m.
On 01/06/2010 01:27 PM, Fulko Hew wrote:
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)redhat.com
<mailto:ajax@redhat.com>> wrote:
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax(a)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
12:35 p.m.
Quoting Adam Jackson (ajax(a)redhat.com):
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax(a)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.
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.
-serge
12:42 p.m.
On Wed, 6 Jan 2010 12:35:03 -0600
"Serge E. Hallyn" <serue(a)us.ibm.com> wrote:
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.
You are actually asking for configuration options ?
That's not possible in the new order, where people is actively trimming
out any word^woption that is redundant and deviates from the norm (the
norm being what someone else like not necessarily what works best).
/me bis bis bitter ;-)
--
Simo Sorce * Red Hat, Inc * New York
1:07 p.m.
Quoting Simo Sorce (ssorce(a)redhat.com):
On Wed, 6 Jan 2010 12:35:03 -0600
"Serge E. Hallyn" <serue(a)us.ibm.com> wrote:
> 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.
You are actually asking for configuration options ?
Haha, no :) I was just answering his question ("come up with a way to
identify windows to not pop up"). When I get annoyed enough by it I'll
either hack it in myself, or finally hack zoom into evilwm to use with
xcompmgr and really be happy.
That's not possible in the new order, where people is actively
trimming
out any word^woption that is redundant and deviates from the norm (the
norm being what someone else like not necessarily what works best).
/me bis bis bitter ;-)
Shut up and rm that libfoo.a :)
-serge
1:15 p.m.
On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote:
Quoting Adam Jackson (ajax(a)redhat.com):
> On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> > 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.
Ahh, I see the misunderstanding here: I'm not arguing point three. I'm
not even really arguing point 2, as you phrased it; it's not _too_
complicated, it's merely complicated.
I'm arguing that there exists an implementation that tries to prevent
focus stealing, and trying to illustrate why that's a hard problem. And
thus, why the OP's RFE as stated, is either not achievable, or not
desirable.
I mean, in some sense, this is all academic anyway. It's trivial to
write an X app that steals focus, regardless of what the window manager
attempts to implement. But even assuming you're running relatively
well-behaved applications, it's still not an easy problem.
- ajax
1:32 p.m.
Quoting Adam Jackson (ajax(a)redhat.com):
On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax(a)redhat.com):
> > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> > > 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.
Ahh, I see the misunderstanding here: I'm not arguing point three. I'm
not even really arguing point 2, as you phrased it; it's not _too_
complicated, it's merely complicated.
I'm arguing that there exists an implementation that tries to prevent
focus stealing, and trying to illustrate why that's a hard problem. And
thus, why the OP's RFE as stated, is either not achievable, or not
desirable.
I mean, in some sense, this is all academic anyway. It's trivial to
write an X app that steals focus, regardless of what the window manager
Haha - yes, that's why it's tough to care much, there are certain apps
I'm forced to run that will always steal focus :) sigh.
attempts to implement. But even assuming you're running
relatively
well-behaved applications, it's still not an easy problem.
-serge
3:08 p.m.
On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote:
Quoting Adam Jackson (ajax(a)redhat.com):
> On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> > Quoting Adam Jackson (ajax(a)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
9:43 p.m.
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> 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.
Some people what that.
Many other people want the focus change to happen in a _few_ limited
cases where it makes sense.
Current behaviour fails to accurately predict those cases (no doubt
because, in part, the limited acceptable cases differ from person to
person), and so you get unexpected focus theft. This is bad for
everyone.
I think most people are actually in (2), in that a focus steal
directly in response to an action by the user an instant ago isn't
usually considered bad. Detecting that seems impossible (since you
really need to measure intent, did I intend a new window to come up?).
And even some people don't want that: I always prefer to load URLs in
the background ... click-click-click pipelining up tabs which load in
the background hiding the page load display. Fortunately that works
*fine* for me using my hacked up configuration, /except/ when firefox
pops up an alert box of any kind.
I think people are generally more comfortable with the computer when
it is highly predictable. _Never_ stealing focus wouldn't be optimal
for everyone, but at least it wouldn't be surprising. If you cant get
it right, at least be predictable.
On Wed, Jan 6, 2010 at 4:01 PM, nodata <lsof(a)nodata.co.uk> wrote:
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.
In the never-steal case you can learn (through trial and error :( ) to
always click before typing a password. In the (sometimes or always)
focus stealing case you can't even be conditioned to work with it,
unless you consider visceral terror between each keystroke that the
computer will do something unexpected causing you to type
v.e.r.y.s.l.o.w.l.y.
Both fail, one fails in a more predictable way.
If nothing else, a configuration option would be good. Though I still
hold that the state least likely to continually produce surprise
should pretty much always be the default.
On Wed, Jan 6, 2010 at 1:41 PM, Adam Jackson <ajax(a)redhat.com> wrote:
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.
Thats pretty much the opposite of how I work. I'd rather the link
loaded in the backround so that my flow isn't interrupted waiting for
it to load.
2:29 a.m.
On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote:
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)redhat.com>
wrote:
> On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
>> 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.
Some people what that.
Many other people want the focus change to happen in a _few_ limited
cases where it makes sense.
Current behaviour fails to accurately predict those cases (no doubt
because, in part, the limited acceptable cases differ from person to
person), and so you get unexpected focus theft. This is bad for
everyone.
The problem is that the "automatic focus change only when intended by
user" will never be done 100% correctly. This is just impossible to do.
So the actual better user experience case would be to always require the
user to press some (easy) key combination to transfer the focus from the
currently focused window. The user would quickly learn it.
Then the problem shifts to whether the newly created windows should be
opened in the background or not. It would be also easy to teach the
user. I can for example imagine that the new window would first appear
on the top overlayed with a semi-transparent text like:
"Press Ctrl-Tab to send the window to background, press Alt-Tab to start
typing into the window, press Esc to close the window"
The other keypresses would still go to the previously focused window.
With the compositing WMs it would be also easily possible to make the
new window semitransparent over the old window so the user would still
see that he is typing into the old window.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
8:56 a.m.
On Thu, Jan 7, 2010 at 3:29 AM, Tomas Mraz <tmraz(a)redhat.com> wrote:
... snip ...
The problem is that the "automatic focus change only when
intended by
user" will never be done 100% correctly. This is just impossible to do.
So the actual better user experience case would be to always require the
user to press some (easy) key combination to transfer the focus from the
currently focused window. The user would quickly learn it.
You wouldn't need a 'new' (easy) key combination... your window manager
already
defines a way to 'set focus'
Then the problem shifts to whether the newly created windows should
be
opened in the background or not.
... snip ...
Thank you...
There is a big difference between auto-raise, and auto-focus.
I would complain about auto-focus on pop-ups (that should be my
configuration choice)
but auto-raise isn't (as) anoying. Its a visual distraction, but then
again, thats why
its called a 'popup', but at least it didn't cause me to type the wrong
thing into
the wrong window.
5:53 p.m.
On Thu, Jan 07, 2010 at 09:29:55AM +0100, Tomas Mraz wrote:
On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote:
> On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax(a)redhat.com> wrote:
> > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> >> 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.
>
> Some people what that.
> Many other people want the focus change to happen in a _few_ limited
> cases where it makes sense.
>
> Current behaviour fails to accurately predict those cases (no doubt
> because, in part, the limited acceptable cases differ from person to
> person), and so you get unexpected focus theft. This is bad for
> everyone.
The problem is that the "automatic focus change only when intended by
user" will never be done 100% correctly. This is just impossible to do.
So the actual better user experience case would be to always require the
user to press some (easy) key combination to transfer the focus from the
currently focused window. The user would quickly learn it.
Having to click into every window when it opens (especially if it
was intentional) can become quite tiring - I had to do this while working on
MPX when the proof-of-concept WM didn't have any auto-focus capabilities. It
is predictable, but _really_ annoying.
Anyway, it's a simple cost/benefit question. Does the cost of the unintended
focus changes outweigh the cost of clicking into new windows for your
workflow? If so, how about the person next to you? How about your partner,
uncle, grandma, neighbour's son, boss?
So the actual better user experience case [...]
"better user experience" is really hard to quantify. TWM has a predictable
interface for displaying new windows and could thus be labelled as "better
user experience" based on this premise. No other popular window manager uses
the same approach though. It all depends on your definition of "better",
"user" and "experience".
Cheers,
Peter
11:32 a.m.
On 01/06/2010 05:00 PM, 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.
Er, why would you want Firefox to be holding focus when it pops up? I can't
think of any reason.
Andrew.
12:41 p.m.
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.
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.
- ajax
1:38 p.m.
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(a)redhat.com
10:46 a.m.
On Wednesday 06 January 2010 10:07:58 am Adam Jackson wrote:
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 :)
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.
- ajax
really the only time i have a big issue with it is when logging in for the
first time. and the session is restored. kde is actually starting to get
pretty good about managing things correctly. you get a popup that an app
wants focus to unlock kwallet I really hate when im unlocking gnome keyring
and something else steals focus. after your logged in things would only take
focus if you started the app by some action of your own.
Dennis
10:53 a.m.
On Wed, Jan 6, 2010 at 10:00 AM, nodata <lsof(a)nodata.co.uk> 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 :)
Firefox's focus stealing constantly drives me nuts. Trigger something
to load things in another tab which later pops up some dialog (like an
htauth dialog), then switch to another workspace ... and BAM, you're
in the middle of typing and firefox has stolen focus. Helps if you're
on a slow network so you have time to really get into your work on the
other window before the theft happens.
I had thought this was a consequence some non-standard window manager
configuration I had... it drives me nuts but I've never seemed to be
able to find the cause.
If you'd like to try it out... go to
http://www.pagetutor.com/keeper/http_authentication/index.html middle
click the secret stuff link and then quickly (via the keyboard) switch
to another workspace. (quickly is only required if your network is
fast and the site is fast... I've had firefox steal focus many minutes
after I last interacted with it)
1:38 p.m.
On Wed, 06 Jan 2010 11:53:21 -0500, Gregory Maxwell wrote:
On Wed, Jan 6, 2010 at 10:00 AM, nodata <lsof(a)nodata.co.uk>
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 :)
Firefox's focus stealing constantly drives me nuts. Trigger something
Sadly this mind raging feature has infected SeaMonkey 2.0 now. I used to
be able to open links in tabs in the background from other apps, now it
happily and proudly pops to the foreground and steals focus. sigh.
2:59 p.m.
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
3:32 p.m.
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.
5:04 p.m.
On Wed, 06 Jan 2010 15:59:14 -0500, Owen Taylor wrote:
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".
Would you (or someone) mind explaining why the following happens and how I
could get pre-F12 behaviour?:
In Fedora 12,
1. start seamonkey
2. start gnome-terminal (be on top of seamonkey window)
3. $ seamonkey -remote "openurl(http://lwn.net,new-tab)"
4. seamonkey pops in front and steals focus.
This used to just load the page in the background without stealing focus.
It seems like there are a myriad of confusing ways this can happen and a
several options to mitigate it... but I'm lost.
6:17 p.m.
On Wed, 2010-01-06 at 23:04 +0000, Zing wrote:
On Wed, 06 Jan 2010 15:59:14 -0500, Owen Taylor wrote:
> 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".
Would you (or someone) mind explaining why the following happens and how I
could get pre-F12 behaviour?:
In Fedora 12,
1. start seamonkey
2. start gnome-terminal (be on top of seamonkey window)
3. $ seamonkey -remote "openurl(http://lwn.net,new-tab)"
4. seamonkey pops in front and steals focus.
This used to just load the page in the background without stealing focus.
It seems like there are a myriad of confusing ways this can happen and a
several options to mitigate it... but I'm lost.
(A caveat here is that I can't speak to Compiz or Kwin or XFCE behavior,
I can only discuss the behavior of Metacity. That is, GNOME with Compiz
not selected in the desktop-effects tool.)
In regards to Metacity, there were no changes that I can think of in
this area between Fedora 11 and Fedora 12, so if anything changed it
probably was a change to Seamonkey.
There are two things in the situation that you describe which are
somewhat difficult to handle:
First, when you run a program from a terminal, there's no way that a
launch timestamp will be set on that program, because the launching
isn't done by gnome-panel, or some other GUI program, it's done by bash,
which is ignorant of desktop niceties. So at that point, it's basically
back to a fixed policy of taking focus or not stealing focus. The
default is to take the focus.
Second, when activating an existing app rather than starting a new
application, the focus timestamp, if it exists, has to be passed across
whatever protocol is used (here it is the "Mozilla Remote" protocol
via X messages.)
If I had to guess, I'd guess that prior to Fedora 12, Seamonkey wasn't
worrying about timestamps at all - it wasn't passing a timestamp - so
the new window was created with an old timestamp of the last time you
interacted with Seamonkey. But an updated version now tries to do
something smarter. Since no focus timestamp exists when invoking the
remote command from a terminal, it ends up grabbing the focus
unconditionally.
There's not really a fix for this - either grabbing the focus or not
grabbing the focus will annoy some people. But since it annoys you, you
may find:
gconftool-2 -s -t string /apps/metacity/general/focus_new_windows strict
To be useful - when that's set, new windows never take focus away from
a window that looks like a terminal window. (This is assuming the above
opens a new window. If it changes an existing window, then "focus_new_windows"
won't affect the behavior.)
- Owen
12:58 a.m.
gconftool-2 -s -t string /apps/metacity/general/focus_new_windows strict
To be useful - when that's set, new windows never take focus away from
a window that looks like a terminal window. (This is assuming the above
opens a new window. If it changes an existing window, then "focus_new_windows"
won't affect the behavior.)
Doesn't work. I set this, then started gedit from gnome-terminal. The gedit
window got focus.
D.
9:17 a.m.
On Thu, 07 Jan 2010 07:58:11 +0100, David Tardon wrote:
> gconftool-2 -s -t string
/apps/metacity/general/focus_new_windows
> strict
thanks for that...
> To be useful - when that's set, new windows never take focus
away from
> a window that looks like a terminal window. (This is assuming the above
> opens a new window. If it changes an existing window, then
> "focus_new_windows" won't affect the behavior.)
>
>
Doesn't work. I set this, then started gedit from gnome-terminal. The
gedit window got focus.
Are you sure you didn't have another gedit window open. It seems to work
as Owen mentioned (only if you don't have an existing window open)...
it's so close to what I needed, unfortunately I always keep a browser
open in the background.
12:10 a.m.
On Thu, Jan 07, 2010 at 03:17:45PM +0000, Zing wrote:
On Thu, 07 Jan 2010 07:58:11 +0100, David Tardon wrote:
>> gconftool-2 -s -t string /apps/metacity/general/focus_new_windows
>> strict
thanks for that...
>> To be useful - when that's set, new windows never take focus away from
>> a window that looks like a terminal window. (This is assuming the above
>> opens a new window. If it changes an existing window, then
>> "focus_new_windows" won't affect the behavior.)
>>
>>
> Doesn't work. I set this, then started gedit from gnome-terminal. The
> gedit window got focus.
Are you sure you didn't have another gedit window open. It seems to work
as Owen mentioned (only if you don't have an existing window open)...
it's so close to what I needed, unfortunately I always keep a browser
open in the background.
Definitely not, I use gedit as a test application only. But I see what's
the problem now--it only works from freshly started terminal. So all the
terminals that were running at the moment I set focus_new_windows to
strict didn't pick that setting and continue to open new windows
focused. Isn't that a bug in gnome-terminal (or metacity)?
D.
7:55 a.m.
On Wed, Jan 06, 2010 at 03:59:14PM -0500, Owen Taylor wrote:
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:
I just realised that not only focus stealing when typing, but also when
reading is annoying. E.g. here firefox just crashed, so I restarted it
and while it opened all its tabs and windows, I wanted to read mails.
But then firefox steals the focus several times for its windows.
Is this something that is supposed to happen?
Regards
Till
5247
days inactive
5249
days old
48 comments
25 participants
participants (25)
-
Adam Jackson -
Adam Miller -
Alexander Boström -
Andrew Haley -
David Tardon -
Dennis Gilmore -
Fulko Hew -
Gregory Maxwell -
Haïkel Guémar -
Jarod Wilson -
Matthew Booth -
Matthew Garrett -
nodata -
Owen Taylor -
Peter Hutterer -
Peter Jones -
Philip Heron -
Sam Varshavchik -
Serge E. Hallyn -
Simo Sorce -
Till Maas -
Tim Waugh -
Tomas Mraz -
Toshio Kuratomi -
Zing