RFE: Never, ever steal focus.
Sam Varshavchik
mrsam at courier-mta.com
Wed Jan 6 23:58:18 UTC 2010
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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100106/221eb076/attachment.bin
More information about the devel
mailing list