Shared Mime spec: overriding globs locally

[David Faure]

On Wednesday 25 March 2009, Alexander Larsson wrote:
> On Tue, 2009-03-24 at 18:20 +0100, David Faure wrote:
> > On Monday 23 March 2009, Alexander Larsson wrote:
> > > On Sat, 2009-03-21 at 13:02 +0100, David Faure wrote:
> > > > If a user wants to modify the globs for a given mimetype, I generate
> > > > a local ~/.local/share/mime/packages/<mimetype>.xml file with 
> > > >  <glob pattern="..."/> in it, run update-mime-database, and then the parsing 
> > > > of the generated ~/.local/share/mime/globs file is supposed to *override*
> > > > the system definitions with the local ones (not "add to"), right?
> > > > (This particular behavior isn't fully defined in the spec, it doesn't explicitely
> > > > say what happens with local overrides)
> > > 
> > > Yeah, thats not really specified. I don't know what the gnome code does
> > > in this case even. Lemme look... back. They are all added.
> > 
> > Ah, bad (not as useful as "replacing", and incompatible with the KDE implementation, then).
> > Do you agree with specifying and implementing that local definitions replace global ones?
> 
> I don't know if its really not as useful as replacing. Isn't it useful
> to allow adding just a single glob to a mimetype. 

You're right. It's not useful for a GUI (which lets the user work on the entire list)
but it's useful for hand-written packages/*.xml files, and actually I needed just that
for KDE at some point.

> Otherwise you'd have
> to duplicate the global ones first, which means if they later change
> (due to shared-mime-info update, or XDG_DATA_DIRS changing) then you
> won't get the new values.

Yep.

> Wouldn't it instead be nicer to say globs are added to the global ones,
> if you want to override you could do something like:
> 
> application/x-mimetype:__NOGLOBS__ 
> application/x-mimetype:*.newextension

Excellent solution!

> > > > P.S.: While we're at it we could do exactly the same for "magic" bits: specify that
> > > > local definitions *override* global ones (not "add to"), and that a custom
> > > > entry means "remove all global definitions for this mimetype". Not that I provide
> > > > any GUI for editing magic bits, but this would make it possible to do the equivalent
> > > > of "deleting" a system mimetype altogether: if it has no magic and no globs,
> > > > it is effectively unused for local files, even if its name keeps existing (which is good,
> > > > for the case of e.g. getting a mail with that mimetype name for an attachment).
> > > 
> > > I don't see why not.
> > 
> > OK, great.  So, <magic deleteall="true"/> ? But we also need a way to express that
> > in the generated binary "magic" file. Well, maybe just [90:image/x-eps] is enough
> > (an empty group).
> 
> Similar to the above, I think it would be nice to be able to mark when
> to override or not so you can either add to or replace the global magic.

That's more tricky then, syntax-wise.
[90:image/x-eps:__NOMAGIC__] ??

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