[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Default Program | File Association

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]