Shared Mime spec: overriding globs locally

[David Faure]

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?

> > But the main problem is: this only works when adding or modifying globs for a mimetype
> > (more precisely when the mimetype has at least one glob in the end)
> > What if the user wants to *remove* all globs for this mimetype?
> > (use case: first 3 paragraphs in https://bugs.kde.org/show_bug.cgi?id=184181)
> 
> Didn't we make things work with conflicting globs? It should fall back
> to sniffing and if that doesn't work then use the weights to decide
> which one is the default?

Yes, but you're missing the point. Those are solutions for the spec to be correct.
It doesn't help end users who want to make changes themselves -- e.g. because no
magic is available for either mimetype. End users can define new mimetypes with
patterns, but not magic. So it's a perfectly valid use case for a user to say "I want
to modify or remove the globs for a given mimetype".
I agree that in the case of bug 184181, the video/mpeg magic might do the job,
but maybe in some cases it doesn't, and we can't really ask end users to fix
magic matching rules. OTOH they understand much more easily "adjusting patterns"
(and we provide a GUI for that). Except that it only works when adding/modifying patterns,
but not when removing them all...

> > Then it doesn't work, because in that case the local globs file contains
> > nothing about the mimetype, so the system-wide globs are still used, which
> > is not what the user requested.
> 
> I'm not sure exactly what you mean here. 

Assuming we agree on "local definitions replace global definitions", then the problem is
when the local definition is "no globs for mimetype xyz".
In such a case, the local "globs" file says nothing about xyz, so the globs from the
system-wide globs file are still used, and the user didn't succeed in clearing the
globs for xyz.

> > Solutions?
> > 
> > I can think of only one: extending the spec to contain something like <glob deleteall="true"/>,
> > and letting update-mime-database generate a line that says
> > mimetype:__NOGLOBS__
> > in the local globs file.

(In fact the deleteall="true" is not strictly necessary, we could simply generate __NOGLOBS__
for any mimetype that doesn't define globs, but that would bloat the globs file greatly,
so the point of the new attribute is to only do this where necessary -- and it's our job, not
update-mime-database's job, to only do this in local dirs and not in /usr; update-mime-database
doesn't necessarily have the full picture about what's global or local anyway, since it is always
called with a single dir as argument.)    Conclusion: I still agree with my initial suggestion, but 
at least now I thought a bit more about it :-)

> > What do you think? Any other solution?
> 
> For the reported case, can't we just handle the conflict and pick the
> glob weights according to the preferences of the user?

Before I add a GUI for adjusting glob weights (which seems a little bit overkill here,
and is harder to explain to users), I would rather make the existing GUI for
adding/removing globs weights work in all cases.

> Although in general that doesn't solve the issue, so maybe we could add
> the delete feature. 

Yes.

> If so, what is the order of directories being searched? (I assume
> __NOGLOBS__ expire things from all previously read dirs.
> 
> i.e. if XDG_DATA_HOME=~/.local/share and XDG_DATA_DIR=/foo1:/foo2
> 
> which order are they searched? XDG_DATA_HOME last probably.

~/.local/share has precendence over /foo1 and /foo1 has precedence over /foo2,
so if this is implemented as a bottom-up approach with replacing/deleting previously
read stuff, then the search order is /foo2, /foo1, ~/.local/share.

In my setup:
$ kde4-config --path xdgdata-mime
/home/dfaure/.local/share/mime/:/d/kde/inst/kde4/share/mime/:/usr/share/mime/

with the following env vars set:
XDG_DATA_DIRS=/d/kde/inst/kde4/share:/usr/share

This works a bit like PATH, i.e. first match is used.

> > 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).

-- 
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).