Uno Engborg wrote:
John Summerfied wrote:
Uno Engborg wrote:
Larry tb skrev:
When using shortcut ctrl shift N, to open a new shell, the new shell
is opened BEHIND the actual one.
Is it a new fonction ?
Not very useful is it ?
Every new window is opened behind the shell. Try to type open
sabayon, by typing the
command from a shell, and you will find that the sabayon window is
completely covered
by the shell from which it was opened. In fact it made me think
sabayon was broken
as nothing seamed to happen.
I think that they did it this way to prevent opening windows from
grabbing the user input,
something that could be serious if the user is typing a password.
However that situation is very rare and I think this should be
regarded as a bug.
With the old behaviour it's disturbingly common for a dialogue to pop
up and steal keystrokes. It's perfectly possible for a dialogue to be
dismissed (by the user pressing the space-bar) before it's read - that
has happened to me, and depending on the dialogue perhaps to result in
other wrong actions.
KDE has been doing this for years, and once I became accustomed to it,
I think I've only found it inconvenient once or twice. The time I can
remember is running tsclient on FC3 to run a remote desktop to a
Windows box; when the session ends, the tsclient login dialogue pops
up and is disabled by a (meaningless) modal error dialogue behind it.
No, KDE is not doing this. E.g try type sabayon from a gnome-terminal
managed by metacity
and typing sabayon in a ktermial running in Kwin. In the Gnome case the
entire sabayon window is totally covered by the gnome-terminal in the
Gnome/metacity case. In KDE the sabayon window opens on top.
I know you think you understand what you think I said but in fact what I
said may lack some clarity:-)
KDE has been opening behind for years. I can click an icon to start
something, such as Mozilla, and it opens behind everything.
Further checking shows that, when I start kwrite in a konsole window, it
opens in front if konsole has focus, behind if not, and very cleverly,
"kwrite&" followed by further typing has kwrite opening behind.
I can't repeat this with gvim, but that may be a timing issue.
Probably the goal in Gnome was similar, but always there will be
implementation details that differ and corner cases where different
implementors make different choices - or completely overlook that a
choice can be made.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list