RE: User interface suggestions

[David Grega <webmaster overtech zzn com>]

I was looking at KDE.org and the installation procedure for KDE 2 - I hope 
Gnome 2.0 will be much easier to install, if not we should make it as easy 
to install as a Windows Service Pack.

- Dave

----------
From:  thristian atdot org
Sent:  Sunday, December 03, 2000 2:32 AM
To:  gnome-gui-list gnome org
Subject:  Re: User interface suggestions

On Sun, Dec 03, 2000 at 05:35:43AM +0100, Guillermo S. Romero / Familia 
Romero wrote:
> thristian atdot org (2000-12-03 at 1425.52 +1100):
> > The problem with naming the files with a regular extension is
> > that the people come along, extract them, then try and figure out what
> > to do with the resulting shrapnel.
>
> I forgot, add a dir, so they do not uncompress in ./ directly
> (gnome-terminal.iconpack.tar -> gnome-terminal.iconpack/) and inside
> multiple gnome-terminal-w_h_b.png as you say (I would also put the
> base name), maybe even with a README or something.

It's beginning to look like we'll need some kind of automatic
packaging program. I believe there's already a GNOME icon-editor, but
I tend to just use the GIMP.

> > The usual method of making
> > user-opaque packaging is to make an un-compressed .zip file - I'm
> > thinking WinAmp skin files, WinImage compressed images, Java .jar
> > packages, Mozilla .xpi files..
>
> I am not very pro magic, Sawfish uses the non magic approach, and it
> seems to work, the worst I have seen is "what I do with the archive?"
> which is easy to answer: "put it or the contents here for your single
> user, and there for global install".
>
> On the other hand, yes hiding solves the problem above, cos users do
> not mess with those files. But I do not see why hiding is so nice,
> IMHO it just adds to the magic factor, and people start to be scared,
> maybe not about this, but I think you get the idea: add N water drops,
> with N big, and you get a full glass. If users learn how / why, the
> water is of the "coders think I am stupid" or "coders like the hard
> path" classes.

Well, we have magic here because there *is* magic. With a Winzip skin,
a JAR file, a Mozilla skin, or even a Quake .PAK file, the extracted
version is just as good as the original, because the file is a
collection of multiple, independant pieces of information. For an
icon, on the other hand, is a collection of the *same* piece of
information, but at different sizes and color-depths. If you tell the
panel you want the gnome-terminal icon to be "terminal.iconpack", it
can rummage around inside and come up with the image you want for your
12x12 panel. However, if you untar the file, you wind up with a whole
bunch of little files, and using any one of them as an icon is not
going to work properly (as far as multiple-icon-sizes go).

> I think .iconpack.tar extension should be a big clue: it is a tar, so
> users can look inside, but iconpack says that it is not a normal tar.
> Use an icon of an open box with a icon (?) inside and users should get
> it. The README.icons could also have a nice comment explaining what is
> this, plus authors and such. Sawfish always have README + theme.jl,
> once you see a SF theme, you recon all.

I'm not sure what you mean by "recon all", but that sounds fair enough
- or maybe ".taricons", so that people will recognise it's a tar-like
file, but it won't be accidentally recognised by existing programs. Or
maybe we should think of something shorter and easier to type.

> In conclussion two ways of thinking, hide vs show. I guess the tar
> with obligatory dir and names is a must and we can agree, it is code
> reuse and helps organization, but the other is more complex, I always
> try to explain the basic ideas, with simple or complex words (each
> person one approach), others do not want people messing arround at all
> like if the most basic knowledge was restricted to experts. Knowing
> why a car moves is very different to being a mechanic or car designer,
> but it does not hurt.

True. If I was making an icon set, I'd definitely be wanting to use a
specialised packager (anyone used Microangelo for Windows?), but being
*able* to get one's hands dirty if a special extractor is not
available, is certainly a Good Thing.

> > Another thing that occurs to me is that KDE might already be dealing
> > with this sort of thing, and if they've got a standard, it wouldn't be
> > a bad idea to copy them..
>
> I dunno, but IIRC they had various icon sets already.

Hmm.. I might have to spy out the land 'round www.kde.org. :)

--
,------------------------------------------------- ------ ---- -- -  -   -
| Screwtape | Reply-To: is munged on Usenet | members.xoom.com/thristian
|--------------------------------------------- ---- ---- --- -- - - -  -
|
| "Spoons may be an evolutionary dead end." -- Chiggy
|

_______________________________________________
gnome-gui-list mailing list
gnome-gui-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-gui-list