Re: gnome-terminal idea

[David Jeske <jeske home chat net>]

On Wed, Sep 23, 1998 at 03:04:45PM -0400, Tim Moore wrote:
> So, hypothetically, if your window manager supported the BeOS-inspired
> docking tabs interface, would you prefer that or the GNOME notebook and
> why?

I'd prefer the window manager supported method over a single-address
space GNOME notebook because the window manager solution would be: (a)
more stable, (b) allow me to doc non-homogenous windows together.

The GNOME notebook starts to have advantages as it starts to replace
the window manager for docking together all views. For example, I'd
prefer an interface where error dialogs always come up in a 'common'
area, and are handled by my preferred error UI module. This is
something window managers can't easily do, but a GNOME/corba UI
solution could. In the case of this specific example, imagine if every
time any app ever signaled an error, a window would pop up, and then
slide off into the 'error log'. If you wanted to just ignore it, you
could. If you wanted to deal with it, you could. If there was an
action to optionally be taken on the error, you could click on it. If
you hate errors, you could minimize the 'error region' down to just a
little flashing light. Not surprisingly, this conecpt is alot like the
Emacs style interface that people have discussed before.

> Are 10 tabs really more manageable than 12 taskbar buttons? And what if I
> have 20 browser windows open and no other apps on the desktop (which I
> sometimes do)? The problem has shifted from a cluttered taskbar to a
> cluttered row of tabs! 

I think the BeOS again has a much better UI in this area also. They
have a 'taskbar' but they list items by application horizontally, and
then by full document name after you click. As it turns out, Nextstep
4.1 alpha did this first though.

For example, in fvwm, or in Windows95, if you open several web pages
in netscape, all of the taskbar buttons basically have a netscape icon
and a few letters. In BeOS, the taskbar buttons list the application
names (whether it is one copy of the application, or many copies of
the application running in different address spaces). When you click
on the button, it opens a menu going up from the taskbar which lists
all the document names. Because the document names are arranged
vertically, it can include the FULL name of the document.

Ex:

          _______________________________________________
         | AltaVista: Main Page                          |
         | Slashdot: News for Nerds, Stuff that Matters. |
         | 3Dfx Interactive, Inc.                        |
_________|_______________________________________________|___________
<start>  | Netscape   |  xterm   |                           12:00pm |
---------------------------------------------------------------------
               |
               +- here we clicked on Netscape..
              


> What if I'm working with a picture in GIMP, two HTML files in some text
> editor, and previewing the page in a web browser. This two-level grouping
> doesn't correspond to my task in any way, and in fact may get in my way
> when I'm trying to rapidly switch between these four windows, and have to
> go through two different routes. It's even more pronounced if I'm trying
> to work on two tasks at once. Say, in addition to the web page task, I'm
> working on some software. To do that I have another two text files open, a
> debugger window, and a terminal window where I'm compiling stuff. While
> I'm waiting for the compile, I work on the web page. In this situation, I
> want to be able to switch between the two tasks occasionally, and the
> windows within each task rapidly and often. This roughly corresponds to
> the app/document nesting (Alan Cooper calls this kind of two-level nesting
> a monocline grouping) but I don't care about applications -- the HTML
> source and the C source aren't really related in my mind. I care about
> what I'm trying to do.

In this case I tend to use virtual desktops. I had a very similar
situation in a past job using VHDL simulation tools. I just separated
each task into a desktop, and switched between the desktops. The only
thing someone could have done to improve this process was made a way
for me to logout and log back in and keep the tools running and
arranged the way I wanted them.

> However, this has its own problems. Any crashing app could bring down the
> entire notebook. And the notebook-dock itself would have to be perfectly
> stable. And it would have to have all of the notebook-tab management
> commands I would ever need. Essentially, it would take over a lot of the
> task of window management, turning it into notebook-tab management.
> 
> So if the ideal is to have a generalized window-docking feature, I would
> consider this the domain of the window manager (hopefully Raster is
> reading this!) IMO, implementing the BeOS-inspired docking windows will
> solve all of the same problems that GNOME-MDI does, plus some.

It sounds to me like what's starting here is a dicussion over whether
we should use the X ICCCM or a CORBA interface for managing views. :)


-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net