Please strip out the patch that brings up applications behind gnome-terminal

Miles Lane miles.lane at
Wed Feb 1 05:09:18 UTC 2006

On 1/31/06, Rudi Chiarito <nutello at> wrote:
> On Tue, Jan 31, 2006 at 05:23:20PM -0800, Miles Lane wrote:
> > The most aggrevating example, though, is when I start ANY application
> > from gnome-terminal (emacs, amarok, firefox, whatever).  I now have to
> > click on the application window to give it focus.  I hate this!  I,
> > personally, think it is brain-dead to not give focus to applications
> > when they start (with the exception of dialogs which should be "system
> > modal" in Windows parlance).
> What if you start something in the background in your shell? GNOME has
> no way to know whether you just typed "emacs" or "emacs &". In the
> latter case you don't necessarily want the focus transferred to Emacs.

When I use "emacs &", it doesn't mean I want to continue what I was
doing in the shell and use emacs later.  In my usage, it means that
I want to be _able_ to switch back and forth between emacs and
shell commands, but I want to use emacs immediately.  If I didn't want
to interact emacs immediately, I would wait until later to start it up.

> Anyway, do you do anything with gnome-terminal or any other program
> after you start the application, but before its window actually opens?

I have tried not doing anything until the executed program window is
displayed.  The program window still shows up beneath the terminal

> Metacity's focus-stealing prevention is supposed to kick in only if you
> interact with anything else after you started the application - the new
> window then will not grab the focus.

I am not talking about focus, I am talking about what windows are
shown on top!  Personally, I expect focus to always go to the top

> It's not supposed to be
> unconditional, unless there's a bug that ought to be reported.
> What happens if you enter "emacs" and keep your hands away from the mouse and
> the keyboard?

Are you a FC developer?  Have you checked the behavior?
It is unconditional.  So, I should file a bug, eh?

Again, I think Fedora should reject this change to Metacity.
I know that Redhat maintains custom kernel patches.  Can we
have a Metacity that doesn't implement this nutty window management?

Does Fedora Core have any influence over the development decisions
of the Metacity project?  Are we simply at the mercy of their whims?


More information about the test mailing list