Re: Icons of program

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On Tue, 21 Apr 1998, robert havoc pennington wrote:

> > A mime-types database should be used to associate filename suffices with
> > an appropriate program (eg .jpg with ee), this should be changeable by
> > the user. This would represent the default action associated with
> > double-clicking on a file. It would also set the default icon for that
> > type of file.
> 
> This isn't much different from what gmc does now, I don't think. It's not
> at all mutually exclusive with meta-information or the SimpleVFS idea. 
But it all doesn't solve the problem, that I user may want to use a
different program depending upon the file and not the type of the file.

A general example:
File X of type T, is generally started with viewer for type T.
But if the File X was created by the user or the creating application is
available on the desktop of the user, the file should come up in the
application that created the file.

Additionally, extensions are not a really good idea to determinate the
file type (see Windoof for a proof of this sentence).
Things that can go wrong:
- typo by the user, and a x.html will somewhere be saved as x.htmk.
  Now the user has to rename the file first. That's not intutative: You
  don't relabel things in real life to use them, just because someone made
  a spelling error when labelling it. (Know the joke pistol cigeratte
  lighters? They look like pistols, but they still function as a lighter.)
- a small linear name space. Why does .doc stand for M$ Word? (And for
  which version of the format?) Why not simply for document? It's much
  more logical for an user.

> 
> > The user should also be given the _advanced_ option of providing the
> > document with an info file, which specifies an alternate behavior for
> > that particular document (eg. opening a .jpg file with gimp instead) and
The problem is, that gimp should generate this by default. So images the
user works upon are by default opened by gimp.
And the UI has to deal with ``open default for file'', ``open default for
type'', and ``open with ...''.

> > The above seems to me to be the only way to reconcile the problems
> > between those who want to completly abstract away the standard UNIX
> > filesystem, and those who still want to use the shell, without needing
> > any ELF-specific binary patches etc.
> >
> Then everyone has the choice of: regular Unix fs; Unix fs with guesses
> based on extension, 'file', etc.; Unix fs with some meta-info scheme;
> Simple fs; Simple fs with Unix fs as a subdirectory; Unix meta-info fs
> with Simple fs as subdirectory. You can have various combinations of those
> options, or only one. It's all based on the same meta-info code. Everyone
> should be happy.
It's not that easy. Actually, when we are creating an ``icon store'' for
files used by gmc, why doesn't the programs use this store to fetch their
information? Why limit it to the icons? Why not store the positions and
sizes of the document windows in the icon, so when the user reopens the
file, the program will be in the same state it was when the file was
saved?

> This is what it does, only there's no distinction between the desktop and
> the fs. That's why it's not confusing.
I still prefer to augment the whole filesystem, without shadow trees in
each homedir (just keep the tree synced, when the admin install/erases
packages, moves dirs, etc.)

And the meta info (or resource fork, or icon file, suit your vocabulary
*g*), should be stored in the proximity of the file, so an advanced user
on a non-GNU system (I'm still proposing a configure option for GNU file
utils to make it transparent on the commandline) knows that he has not
only to move file but also file.info (or whatever it is called :) ).

> The problem with the MS approach is that they didn't finish the
> abstraction. It was a half-ass semi-break with the past. You can't really
> live entirely in the old or the new scheme, you're forced to use both.
And we are somehow in the better position, as the huge majority of code in
the Unix world is available in source code. (And yes, I know, most
commercial systems come without GNU tools, but most sane admins begin by
installing gcc (standard compiler, who knows if the system compiler knows
ANSI C?), bash/tcsh, fileutils, etc.)

> The basic trait of any viable solution here has got to be configurability,
> because we have to make most people happy. That's the nature of free
> software. I'm simply suggesting that the meta-info scheme be abstract and
> flexible enough to permit a fs abstraction scheme. My argument is that
Exactly my point. provide an abstract API.
The concrete implementations that come to mind:
- a file (be it .file, file.info, file.data, ...)
- a directory
- in the ELF binary if supported on the platform,
...

The point is, that the scheme should also be flexible and extendible.
(So a HTML editor may store it's configuration for some file.html in it.
 This way, if you transport the file somewhere, your settings are probably
 still intact. And there are filetypes that are standard, nonextendible,
 so the app can't store it's infos in the data file proper.)

Andreas