Re: "Official" gnome window manager

[chuck by default <chuck osmos ml org>]

On Fri, 13 Feb 1998, Marcus Butler wrote:

>  Actually, no, it doesn't.  Your argument reminds me of Pascal's Wager,
> which only turns out to be correct if all of his various assumptions turn
> out to be correct.  You assume that everyone using Gnome will be coming
> from Win32, Win16, or Macintosh.  That might not be true.  I think new
> users will be perfectly willing to learn *one* new UI if they want to use
> Gnome.  However, they will not want to use Gnome if one Gmome system looks
> or behaves differently that another.  A very large part of a desktop is
> consistency, that is the bottom line.  Point out a successful desktop
> system that support 3 different window managers.  In spite of all the
> MS-bashing here, in case you guys haven't noticed, MS is doing fine with
> one WM.

You keep ranting about how no new users will want to use gnome if it looks
different from desktop to desktop. I have three points in response (at
least):

1. I work in tech support. I've seen numerous mac and windows users who
get confused moving from one mac/pc to another (of the type they're used
to) and the new machine doesn't have a favorite utility they are used to,
or even is simply on a different network and thus has differently named
printers/servers. A certain amount of change when switching computers is
unavoidable.

The only way we would avoid this is by having a list of official apps, and
stating that every gnome system will have these and *only* these
installed. I know this is a bit extreme, but I'm trying to illustrate a
point - most people are not too confused when switching between mac and
windows platforms if you only ask them to do simple tasks. It's still
click on the menu, select a choice, move the pointer where you want to
type...

I don't think that GNOME's goal is solve every single ease of use problem
for first-time/easily thrown off users. See below for a little on what I
think (one of) the goals should be.

2. It should be (effort should be put into this if necessary, IMHO) fairly
trivial to pack up your configuration files and take them with you to a
new computer, thus keeping nearly everything constant - your wm even if
the same one is installed, your key bindings, etc.

3. Any lab environment using UN*X machines should be set up to allow you
to login to your personal desktop environment/settings from any system in
the lab, possibly even from authorized outside systems. Any lab or similar
type of situation set up this way is not GNOME's problem, IMHO.

4. Some people are actually *impressed* when users desktops running the
same general software look drastically different. One of the things that
hooked me on and has kept me running linux was seeing some of the early
enlightenment screenshots, and then themes came out... :) IMHO, theme
support is no different from supporting different wm's - it just requires
slightly more careful abstraction.

Why doesn't GNOME define a set of standards that a wm should support to
take advantage of all of the integration provided (I guess this should be
handled through CORBA eventually...)

A reasonable list might be:
	wm hints (motif style? for now, seemingly, but why not wrap them
so that if someone comes up with a better, more flexible way, it can be a
compile-time option?
	windowlist intregration
	close boxes (? what wm doesn't have these in some fashion?)
	etc. etc.

I mentioned something above about goals for GNOME. Something I think is a
real possibility with CORBA is a graphical extension of the command line -
not just a nice gui file manager, but an intelligent, intuitive way to
handle things like batch processing and pipes graphically. Here's an
attempt at an example:

You want to combine 100 or so images into a movie or animated gif. They're
not named consistently or the only thing in they're folder. You select all
of them and drag them to a graphical pipe on your desktop which represents
a movie-making utility. Up pops a small dialog (or pop-up menu?) with the
various options, including frame order. You use the frame order option to
sort them how you want them, make a few other settings, and select "OK" or
"Go" or whatever. The conversion starts humming away in the background and
informs the event service of it's progress so the central progress monitor
can tell you how far along it is and what image it's currently on. When
it's done, it either holds the result in memory or writes it out to disk
(in /tmp or wherever) if there isn't enough room, and puts an icon
representing the result(s) just offset from the pipe. When you get around
to it, you drag that icon to wherever you want the final result to be
stored, in which case it gets transferred to disk there permanently, or
perhaps you drag it to another pipe.

Thanks for reading this far. Comments welcome,
-chuck

Charles Hagenbuch   | http://wso.williams.edu/~chagenbu
gnome@earthling.net | "We are plastered against the windshield
osmos.ml.org        |  of the bus that is Time." - Chris