Argumentation on GUI design, was: Re: A few thoughts on Gnome.

[Nils Philippsen <nils wombat dialup fht-esslingen de>]

Hi,

On Mon, 17 Aug 1998, Leareth wrote:

> Well, I've been meaning to do this for quite some time, since Gnome
> was conceived actually. Ahh well, I tend to get distracted.
> 
[snip]
> Ok, well first off I'll start with the file manager, as IMHO it's not
> only a central point of a desktop, it's THE center point.
> 
> 	A: Simple interface, low on area, high on functionality. Example,
> OS/2 & dfm. Simply windows filled with icons, and hotmenu's

Some like icons, some like to have a textual representation like the
original mc (and all sing: "make it configurable" :-) .

> (right-click-hold) attached to all icons & top_back(The background
> window).

A menu bar doesn't rob this much space, trust me (you could make it
configurable, too, but I repeat myself).

> 
> 	B: 100% metadata support, for all apps, not just Gnome apps,
> metadata should not be lost through shell actions, such as "mv" & "cp",
> as if you give most Linux/*nix users the choise between loseing there
> shell, or loseing the most important aspect of there gui, they'll keep there
> shell. I know I would. I belive we can do this with the use of LD_PRELOAD,
> or libc patches on systems that do not support LD_PRELOAD. On system's
> were neither is an option, we should simply let users know that shell operations
> and non-Gnome aweare apps will break metadata, and they should be carefull.
> We should of course support a way to regain broken links in all cases, as
> crashes &(in non preload, orm patched systems) mistakes do happen.

LD_PRELOAD will not work on suid binaries, so you have to come with a
better idea.

> 
> 	C: File individuality. Each file is it's own boss, if you decide
> that out of all other .tex files, you want once single one to have
> it's own icon & wish to associate it with another editor by default,
> you not only can, it should be easily configurable via a options
> menu tied to each file.

Nah. While the different-icon-for-different-file idea is not so bad,
clicking on one TeX file invoking LaTeX and clicking on the other invoking
emacs in TeX is braindead because the user has no indication (read: clue)
of what will happen when double clicking this or that file. When creating
user interfaces you have to adhere to some paradigms and the one that
comes to mind this time is: Follow the way of the least surprise. In this
case you could rather have the different actions (methods) in the
right-click-and-hold menu. One of them is the default and will be executed
when the user double clicks the file. This has been rather well though-out.

> 
> 	D: Neatness. No leavening lots of "." files lying around in
> directory's, just keep it in a database, thats why they exist.

Why do you object dot-files? They are intended for that stuff, and you
(the user) are not supposed to see them by default - they are the hidden
files. One database is one single point of failure, trash you're database
and you trash it all (maybe you should refer to a "registry" rather than a
database so people would be reminded of the drawbacks instantly when
reading:-) just kidding).

> 
> 	E: Memory, mobility & brains. Each file should not only be mobile
> between other directory, but mobile within it's own window as well.
> And when you move it within it's own window, it stays where you put
> it, and remembers that place as well, even if you close the window.

Huh? I guess that's what directories are for. We don't need to reinvent
everything again (reinventing the wheel is someone else's job).

> And when you go putting files in other places, it does not ask you
> every time what it's design should be, it has a default set of
> (configurable) decisions. and is it makes a mistake, you have a undo
> last option, and if it's a long operation, you'll have a cancel
> button to instantly revere your decision. And thats not to say that
> the default will always be right, so if you drag with the right mouse
> button, it goes back to letting you decide. It has brains, and the
> ultimate proof of that being, it knows when to shutup & take orders :)
> 
> 	F: Open new windows by default. Though I do feel that this option
> should be configurable, I also feel that it should fallow the by

<RANT>
IMO this is very sick behaviour. Consider changing to 
/usr/src/linux/Documentation/isdn from your home (say /home/leareth),
which would be ../../usr/src/linux/Documentation/isdn. That's SEVEN new
windows. This is not just sick, it's perverted.
</RANT>

<PROPOSAL>
I'd rather have _no_ defaults in a program - Just ask the settings when
starting the program first (or when it's upgraded, ask for the settings of
the new options), this would have the programs made fit for each
individual user, and no one ever complains again because (s)he doesn't
like the factory set defaults :-)
</PROPOSAL>

> large default of opening a new window on directory open, as opposed to
> changing to sed directory within the originating window.
> 
> 	G: Name change by by left_singleclick_hold(1)sec on name.

This is godd. Indeed much better as the Windows Explorer, where you can't
be sure if you're renaming a file or starting it.

> 
> 	H: Instant highlight  t when rubberbanding files, not highlight 
> after release.

While I find this behaviour nice, it's just cosmetics.

> 
> Next, the all important Panel. Weeee!!!
> 
> 	A: First off, the Panel it self should have it's own
> directory, for storage of config files, droped files on panel, auto
> applet init, and startup folder.

Startup folder? I think we agreed that the W95'ish idea of one single
(special) startup folder was not quite so clever.

> 
> 	B: As to the file drop thing, yes, the panel should in fact be
> able to except actual files, not just fake links. This is for several
> reasons, first off, no more (cut|copy & paste dest) ala w95, and also
> no more copy to desktop and hunt through billions of windows to get
> back to the right place on your desktop. As the Panel has a tendency
> to float above or to the side of other windows, it is less vulnerable
> to such problems.

I'd rather not have all the files/directories sitting on my panel, it's
small enough. You should be able to do it the old way, too (if you insist
on having this functionality (and someone get's the zime to code it)).

[snip]
> 
> 	E: The default menu should be actual directories with real sym
> links contained within, ".<appname> files only created when they
> become necessary.

This would be nice.

> 
> 	F: All options configure able from menus. You wish to have
> ASclock running on your Panel, drag it were you want it, select
> link(though copy would work, why waste space on your system?) and

Nah. I really can't imagine a situation where you would want to have an
actual copy of an executable sitting around in the panel-private
directory. This should happen VERY seldom, so it'd be a loss being asked
every time if this should be a link or a copy (maybe one could have a
"right-drag" (drag with right button) for such weirdo operations).

> goto the options menu & ask for "swallow on" instead of "Normal
> view".

This would be one drawback of your "files on the panel" idea. Without this
you might just drag an app to the panel to achive this (Ok then you have
to indicate the window-id/X-class name of the app in order to be swallowed
correctly, but maybe this could be achieved by starting the app and
telling the user to click on it, maybe with a hacked version of xwininfo,
anyone got ideas or comments on this?)

> 
> 	G: The Panel should have a nice clock/cal running, not just text
> date/time. Like ASclock, hell even ASclock it self. I don't mind
> ripping things off.

You tend to bloat things up, don't you? If any app is swallowable, you
could easily kick the spartanic time/date clock and have ASclock or
whatever you want.

> 
> 	H: A mount applet should be included with the panel, as should

This on does exist already. While you could argue over it's
configurability (with regard to your comments below), it should suffice.
Additional access configuration should be addable to it. 

> several other applets, but mount should usable by non root personal,
> though you would need a settings area, so that root could give
> managed access if desired. But the point being, it would NEED to be
> secure, so it couldn't be taken advantage of. For one thing, it
> should only run on a local display.

This last thing should be configurable to. Don't press the user into
anything.

> 
> 	I: Ok, Sense the Panel also has control of the taskmanager, heres
> that. I believe we should go with something akin to kde's, but with
> submenu's according to creator, eg not all netscapes are on the root
> list, only the ones with different pid's are. Windows with the same
> pid's are listed under a submenu. Other then that, the kde

This sound good at first, but the panel may not have information about the
pid of a window's program (->networked X), so I'm no X guru anyway, but I
think there must be some way to distinct the X apps with their windows
from one another?!

> taskmanager was just about perfect. For me any way.

Someone might say this is stuff for the windowmanager, not the panel
(remember: GNOME doesn't have its own wm, so this point might be offtopic
here, I guess).


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen                  @college: nils@rhlx01.rz.fht-esslingen.de
Vogelsangstrasse 115             @home:    nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart                phone:    +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Wer heute an der Bildung spart,          Those who scrimp on education today,
hat morgen noch bloedere Politiker.      get even dumber politicians tomorrow.
liticians tomorrow.