Default Program | File Association

[David Faure]

On Friday 25 January 2008, Alexander Larsson wrote:
> 
> On Fri, 2008-01-25 at 11:21 +0100, David Faure wrote:
> 
> > After discussion with Alexander on IRC we came to the following adjustement:
> > 
> > * being able to add an application to a mimetype in defaults.list even if the application
> > .desktop file does not mention this mimetype. This removes the need for making local
> > copies of desktop files.
> > 
> > * being able to remove associations, in the defaults.list file, using a separate group like this:
> > [Removed Associations]
> > image/x-xwindowdump=kview.desktop;    
> > 
> > This way the app-mime association list is fully editable (you can add and remove),
> > and no duplication of system settings is done (so if the sysadmin updates his higher-level
> > defaults.list you'll still get those changes, except for the associations that have been
> > explicitely removed this way).
> 
> I've just implemented this in glib svn. It works very nicely. 
> 
> However there is one small issue. If you add an association (as opposed
> to setting the default) via the users defaults.list that will
> automatically override the default in the system defaults.list. It can
> be worked around by copying the list from the system defaults.list into
> the user defaults.list when doing this operation, but thats suboptimal,
> as it means the user won't see order changes happening in the system
> defaults.list later.

But I would say that when the user adds an association, either
1) he/she only sees that association (e.g. the "remember this application" checkbox kind of GUI)
and then making it the default makes sense.
2) or he/she is seeing the full list of applications associated with that mimetype, and when
adding the new application to that list, he/she is deciding where it goes in that list (top, bottom, middle);
and then saving the whole list to defaults.list isn't so wrong, it saves exactly the order that user just chose.
Changes happening to the system defaults.list later on (by a sysadmin) will still respect the
default app seen by the user when adding the application...

I do see your point of course, I'm not against a fix for it, I'm just saying that the current
situation is "good enough" for me given the GUI we offer for this.

But maybe it means that we are simply mixing two things: associations, and "defaults"
(better called "preferred application" IMHO).
We are reusing defaults.list for more than just defaults; the proper fix might be to split it
or to split its contents into "changes to the associations made by the desktop files"
(adding/removing), and "what is the default for this mimetype". By splitting we can add
an association without changing the system-wide default.

=> if you want a fix for this I suggest:

[Default Applications]
# unchanged, but now really only used for picking the preferred application

[Added Associations]
mimetype=app1;app2;

[Removed Associations]
mimetype=app3;

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).