Re: gnome-terminal idea

[Tim Moore <tmoore tembel org>]

On Wed, 23 Sep 1998, David Jeske wrote:

> On Wed, Sep 23, 1998 at 03:04:45PM -0400, Tim Moore wrote:
> 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.

I like the idea of the panel as a graphical, application-global minibuffer
:-)

> > 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.

Dan Kaminsky had a similar proposal:
http://www.best.com/~effugas/Constructs/Minbars/minbars.html

But even better than grouping by app is grouping by task. This is
difficult to do automatically, but it's not to hard to guess that a new
window ispart of the same task as the one it was launched from, and let
the user correct this when it's wrong.

> > 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.

Yeah, that's what I usually do too.

> 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.

Well GNOME has that, too, though I've had trouble getting it to work very
well.

> > 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. :)

Hmmm. I think you're right. In which case I should probably learn
something about each!

Tim