|
|
|

01-06-2010, 04:46 PM
|
|
|
RFE: Never, ever steal focus.
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 04:53 PM
|
|
|
RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 10:00 AM, nodata <lsof@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)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:00 PM
|
|
|
RFE: Never, ever steal focus.
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:17 PM
|
|
|
RFE: Never, ever steal focus.
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:20 PM
|
|
|
RFE: Never, ever steal focus.
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.
*/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:23 PM
|
|
|
RFE: Never, ever steal focus.
Quoting Adam Jackson (ajax@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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:32 PM
|
|
|
RFE: Never, ever steal focus.
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.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 05:41 PM
|
|
|
RFE: Never, ever steal focus.
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 06:08 PM
|
|
|
RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (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.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|

01-06-2010, 06:27 PM
|
|
|
RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax@redhat.com> wrote:
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (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.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
|
|
|
All times are GMT. The time now is 10:42 PM.
VBulletin, Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org
|