No more right click terminal

[Paul W. Frields]

On Sat, 2005-07-16 at 02:33 +0200, Daniel Roesen wrote:
> On Fri, Jul 15, 2005 at 08:09:01PM -0400, Paul W. Frields wrote:
> > > People here just want to start a shell window as effectively as
> > > possible, as it's their main tool working with the desktop systems all
> > > day (and no, it's not a very special application like Audio Editing
> > > suite). Asking people to install another package (first they have to know
> > > that it actually exists and how it's named - IIRC someone else pointed
> > > out this very obvious way) for something that simple is ridiculous.
> > 
> > By "effective," don't you mean efficient?
> 
> Yes, sorry. English is unfortunately not my native language. :-Z

No apology necessary, I just wanted to make sure I understood you
correctly.

> > If you wanted to start a shell as *efficiently* as possible, you
> > wouldn't use the GUI at all; you'd be working in a tty all day.
> 
> No. As I need to have several shells visible side-by-side all the time,
> and interact with Firefox and sometimes OpenOffice.
> 
> There is not just black and white. There are shades of grey, too. "Best
> of both worlds" approach.

True.  One size does not fit all.  GNOME tries to fit most "general
users," for example.

> > If you *had* to use the GUI for some other reason, the most efficient
> > way to open a shell would be by assigning a keyboard shortcut.
> 
> No, as that would conflict with the terminals, wouldn't it? So I would
> need to move the mouse out of the application/terminal windows to have
> the desktop getting input focus... OOPS, impossible with metacity! And

Wrong.  But I will admit I typed the wrong key sequence below.  I have a
shortcut assigned to "Ctrl+Alt+T," not "Ctrl+Shift+T," which opens up a
new terminal tab.  No matter what I'm doing -- even in a terminal
already -- Ctrl+Alt+T opens up a new terminal.  I don't need to move the
mouse at all.

> > The amount of
> > time it takes to move your hand away from the terminal -- where you're
> > probably working already, judging by the fact that it's your "main tool"
> > -- and then maneuver the mouse and click it twice is *MUCH GREATER* than
> > the amount of time it takes to hit Shift+Ctrl+T (for example).
> 
> Yes, but I need to grab the mouse anyway to position the new terminal
> window where I need it. So my usual action to open a new terminal is
> to grab the mouse, right-click, move a few pixels to the very first
> option "Open Terminal", left-click, and then drag the window where it
> needs to be. Beat this. You can't.

Ctrl+Alt+T
Alt+F7 (move mode)
Shift+arrow (depending on location, tap a couple of times to shift
terminal to other side of screen)
Q.E.D.

Notwithstanding the above, I am responding only to your claim that the
right-click "Open Terminal" is the most efficient way to *open a
terminal.*  Now you're talking about moving it where you want it, which
has little to do with using nautilus-open-terminal.

> Now if metacity would actually pop the window ready-to-drag under the
> mouse pointer (drop where it should be by left-click... you know, all
> the stuff fvwm had many many years ago already), even that could be
> optimized, as no mouse movement to fetch the newly popped up window (in
> the left upper corner, where the average mouse movement necessariy is
> max) would be necessary anymore.

You keep getting further away from the argument at hand.  What metacity
does has nothing to do with this thread either.

> So opening a new terminal would be:
> 
> - right click
> - move mouse a millimeter
> - left click
> - move mouse to where the term/app should go
> - left click
> 
> => done. THAT is efficient. :-)

See above.

None of this precludes the use of nautilus-open-terminal.  You haven't
responded to the more relevant and important part of my post, which is
about getting nautilus-open-terminal included as part of a new package
combination, say for power users.  I'm sure it would be easier to simply
argue about who has to move their hands less, but it would also
certainly be less constructive and definitely less fruitful.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/60e3e936/attachment.sig>