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

[Rudolf Kastl]

2006/2/1, Rudolf Kastl <che666 at gmail.com>:
> 2006/2/1, Miles Lane <miles.lane at gmail.com>:
> > On 1/31/06, Rudi Chiarito <nutello at sweetness.com> 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
> > window.
> >
> > > 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
> > window.
> >
> > > 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?
> >
> >          Miles
> >
> > --
> > fedora-test-list mailing list
> > fedora-test-list at redhat.com
> > To unsubscribe:
> > https://www.redhat.com/mailman/listinfo/fedora-test-list
> >
>
> i am sure that if you have really good arguments a single person has
> influence aswell.
>
> regards,
> rudolf kastl
>
> p.s. i think such a setting requires a trainable ai... when do we get
> trainable ai for the gnome desktop behaviour?
>

features that would get more usability out of metacity in my eyes:

per application removable (close) buttons (windowmaker has that)..
this way you cant accidently close <insert important app here> with a
big window mess on the screen.

for people that want to have the terminal in foreground theres already
an option for it.. right click on the metacity top windowdecoration...
instead of creating a function that can remember application wise
settings enforcing a setting on one application sounds like a bug to
me with no gain but only loss of functionality.

instead the metacity devs could integrate features that would get more
usability out of metacity in my eyes:

per application removable (close) buttons (windowmaker has that)..
this way you cant accidently close <insert important app here> with a
big window mess on the screen.

regards,
Rudolf Kastl

p.s. i am a terminal freak... but i prefer customizabilty towards hardcoded bugs