Re: Default Program | File Association

["Brenden T." <brenden rcsis com>]

I think there are people woking on this, but I like your ideas a lot.  
I'd encourage you to go ahead and get your hands dirty.  More choices in 
this area might improve the quality of the Linux desktop overall.

Some thoughts:

- File types are different than file associations.  Files have only one 
type, e.g. "html", but may have more than one file association, e.g., 
Mozilla, Konquerer, Emacs, vi, and gedit may all be capable of opening 
"html" files.  There is one default association for each file type.  
This is a simple one layer heirarchy; just zero or one single default 
and zero or more other associations. No need for anything more complicated.

- GUIs aren't the only consumers of file types.  Apache can specify the 
mime type of a file it serves up; it currently has it's own seperate 
scheme for doing this, but a single solution that works for both GUIs 
and servers may be good idea. It'll ensure future compatiblity and 
reduce maintanence in the long run.

- GUIs are the only consumers of file associations, that I can think 
of.  This implies that a program to serve up file types, and a program 
to serve up file associations may be two different things.


Tim Ringenbach wrote:

> (Hmm, messed up the quoting here, i should get off the digest and on 
> the real list..) As for as priorities go, I'm thinking what would be 
> better would be to have multiple files. It would effectively be the 
> same thing, but cleaner to manage. This is just a rough idea right 
> now. I'm thinking something along these lines: - A mapping of MIME 
> types to programs (or perhaps actions by those programs),  probably 
> created from the .desktop files, possibly extending the .desktop files 
> to have the right information. The programs are basicly in random 
> order in this file. Well I guess they should be in as sane as order as 
> possible, without trying too hard. On top of that is a series of 
> overrides files. - An override file for each environment. This file 
> could be maintained by, and live in the CVS tree of, the environment 
> it's for, where possible. Such environments would be stuff like 
> "console", "KDE", "GNOME", "OpenStep", umm, anything else that 
> provides its own programs really. The order these are merged in 
> depends on what environment the user is currently in. This is like the 
> priorities idea, but hopefully easier to maintain. - An override file 
> provided by the distro. This isn't any different than the last 
> override files, it's just provided by a different source, and has 
> priority over it. This way distros can cherry pick apps if they want 
> without having to hack the desktop environments' files. - Finally, an 
> override file for user preferences. This is also no different from the 
> last two, except user changes are stored here, and it has final 
> authority. All those files would be the same format, and there would 
> be some scheme to decide which order to merge them in, which would 
> vary depending on which environment the user is in. The files higher 
> up in the chain need only specificy stuff not specified lower down. 
> Perhaps the one I mentioned at the bottom need not exist, and info 
> about KDE programs is merged straight into the KDE file. There would 
> still need to be a catchall X11 override below the DE overrides, but 
> above the console ones, then. There might also be a vender supplied 
> one, between the distro and user specified levels. It would probably 
> be best if most of the lower levels could be generated rather than 
> handmaid, perhaps from a series of smaller files, like the MIME 
> database. --Tim Ringenbach