Description of problem:
If I launch system-config-network from gnome-terminal, it appears behind the
gnome-terminal window. If I launch it from the Gnome System menu, it appears in
front of the gnome-terminal window.
Version-Release number of selected component (if applicable):
Always, but gimp and openmotif applications (xephem) seem immune.
Steps to Reproduce:
1. type system-config-network from a gnome-terminal that covers more than 50% of
The system-config-network window is place behind the gnome-terminal window.
The system-config-network window is place in front of the gnome-terminal window.
With the exception of gimp, it seems that if I start a program from a
Gnome menu it gets placed in front, but if I start the same program from
gnome-terminal (or any other program) it gets placed behind (gnomines,
gnome-sudoku, and gweled, abiword, kjumpingcube, and bittorrent). I also
tried about a half-dozen of the system-config-* tools (some allow the
window manager to float the window to the side so it can be seen when
hidden like system-config-lvm) and they all do it.
Program's like sylpheed seem to carry this throughout. Opening the config
or filter settings from the summary window and then closing it, the
summary window gets placed in back of the message view and folder view
Openmotif programs like xephem seem immune, but both kde and gnome
applications get hit by this.
The might be gtk2 bug instead. I'm not sure.
This actually isn't a bug; apps launched from terminals are intentionally being
denied focus (whereas apps launched from gnome panel menu, desktop icon
launchers, panel launchers, run dialog, global keybindings, etc., do get focus
as normal). This may need to be made a preference as some apparently use
terminals for basic launching behavior instead of more advanced usage. (Also,
for some fun reading, see http://lwn.net/Articles/148007/)
"This may need to be made a preference as some apparently use
terminals for basic launching behavior instead of more advanced usage."
That seems like particularly binary reasoning. Isn't it more likely that most
people who use the terminal heavily are more likely to just do *more* things in
general with it? Breaking it down into "advanced usage" and "basic launching
behavior" seems awfully simplistic to me.
If you're already in the terminal, it makes sense to keep your hands on the
keyboard and use it as a launcher too rather than change your workflow metaphor,
grab the mouse, and hunt around for an icon on the desktop.
(In reply to comment #3)
> That seems like particularly binary reasoning. Isn't it more likely that
> most people who use the terminal heavily are more likely to just do *more*
> things in general with it? Breaking it down into "advanced usage" and
> "basic launching behavior" seems awfully simplistic to me.
Would you care to explain usage scenarios and desired behavior? You seem to be
suggesting that there are a lot more different desired behaviors out there than
just a couple, yet seem to be simultaneously dismissive of a suggestion to
provide a preference that would handle two such desired behaviors instead of
just the current one. I'm really not following you. While I'd personally
really love to use libmindread to determine whether the given user happens to
want a specific launched window to have focus, unfortunately libmindread and
other mind reading API doesn't yet appear to be available. ;-)
> If you're already in the terminal, it makes sense to keep your hands on the
> keyboard and use it as a launcher too rather than change your workflow
> metaphor, grab the mouse, and hunt around for an icon on the desktop.
Sure. So? The whole point is that there are very different usage scenarios for
terminal users. In fact, the "not change the workflow metaphor by having to
grab the mouse" is exactly the reason that many terminal users hated having
windows launched by the terminal gain focus.
I work in a scientific reasearch lab and I have installed Fedora on about two
dozen desktops. The users are a mixture of Linux newbies and power user /
programmer types. /opt is on NFS and contains a large number of graphical
scientific and command line apps. Nobody bothers configuring them into their
panels or menus. People use command line terminals all the time and probably
launch apps as or more often from the command line than they do using the menus
or panels. This includes things that are in the panel, like OOo, browsers, PDF
viewers and especially text editors. 99 % of the time they expect to see a
window appear, with focus, when they launch from the command line.
I personally do not have the 'Window List' -type selector (evil POS invented by
Microsoft IMHO) on my desktop. I use 'Window Selector' instead. The apps lauched
from command line and buried under the current window appear blinking in Window
List, which makes sense, I guess. What about people who use 'Window Selector'? I
actually thought for a while that the apps I launched had hung, because the
window was nowhere to be seen. Alt-Tab will bring it up, but surprisingly few
people are aware of that key combination.
I use the command line almost exclusively to launch everything, and I admit
there have been times when I wished the focus would stay on the terminal when
launching, but these instances are very, very rare. The pop-under thing should
be configurable if it is going to go in FC5. The current implementation will
drive people nuts.
Would this attachment be a solution:
It's from http://bugzilla.gnome.org/show_bug.cgi?id=326159
They're not planning on putting this in GNOME 2.14.
There is an updated patch in the GNOME Bugzilla which addresses some issues
raised by the Metacity developers. The attachment referenced in comment #6
should not be used.
*** This bug has been marked as a duplicate of 186308 ***
(In repl(In reply to comment #4)
> (In reply to comment #3)
> > That seems like particularly binary reasoning. Isn't it more likely that
> > most people who use the terminal heavily are more likely to just do *more*
> > things in general with it?
> Would you care to explain usage scenarios and desired behavior? You seem to be
> suggesting that there are a lot more different desired behaviors out there than
> just a couple, yet seem to be simultaneously dismissive of a suggestion to
> provide a preference that would handle two such desired behaviors instead of
> just the current one.
Sorry, I think you might have misunderstood my point. I was simply saying that
I don't think you can break down terminal usage patterns into "basic launching"
and "more advanced usage". Simply put, the terminal is such a flexible tool
that it's inevitably going to be used differently by virtually everyone who uses
it. Over that large a scale, you're probably going to find as many people who
support the "new window under" behavior as hate it.
My message was in *support* of making the behavior configurable based on the
preference of users; what I objected to was the idea that one preference was
more "basic" than the other.