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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
