On Friday 02 February 2007, Thomas Leonard wrote: > On 1/28/07, David Faure <[EMAIL PROTECTED]> wrote: > > Hello, > > I'm starting to implement shared-mime-info for KDE4. > > I hadn't read the spec for a very long time, so I did it again, and: I > > still like it very much :) > > I just have a few questions. > > (note: I'm not the maintainer any more, but I'll try to answer some of > this anyway)
Thanks. You probably have best insight into why things were specified this way ;) > > First question: user overrides. > > > This specification uses the XDG Base Directory Specification[BaseDir] to > > > define the prefixes below which the database is stored. In the rest of > > > this document, paths shown with the prefix <MIME> indicate the files > > > should be loaded from the mime subdirectory of every directory in > > > XDG_DATA_HOME:XDG_DATA_DIRS. > > > For example, when using the default paths, "Load all the > > > <MIME>/text/html.xml files" means to load /usr/share/mime/text/html.xml, > > > /usr/local/share/mime/text/html.xml, and > > > ~/.local/share/mime/text/html.xml (if they exist). > > The first sentence puts XDG_DATA_HOME first; the second sentence puts > > ~/.local in the directory list; > > That sentence doesn't say what order should be used. Normally, reading > the lowest-priority files first is desirable, although it depends how > you want to implement it, of course. Of course, that's not what I meant. To apply precedence correctly, one can read from global to local (and add at every level) or from local to global (and skip already seen stuff). What matters is to define which directory has more precedence than which other. OK I agree that it's probably obvious which one has precedence, it just reads strangely when two sentence seem to contradict each other. > > However, how does that allow the user to remove a pattern->mimetype > > association? > > For instance, /usr/share/mime/globs says application/msword:*.doc > > but since this gives a wrong mimetype to e.g. > > /usr/share/doc/cvs/contrib/intro.doc > > how can I, as a user, remove the "application/msword:*.doc" association? > > You'd have to define a higher priority rule to match them. Well, if the user assigns *.doc to another mimetype then indeed that one will have precedence. But if you just want to remove the rule, you can't. > You can't disable rules in the current spec. I think this removes control from the user. And it makes for a bad GUI too: a user can define his own mimetype, so the GUI must allow to edit globs for mimetypes. But then for some mimetypes (those he created), he can add/remove globs, whereas for other mimetypes (those defined globally), he can't remove globs. Well, he can, if he added them himself, but not otherwise. Argl ;) > I'm not sure the example is very realistic... most .doc files are Word > documents so I don't think you'd want to disable the rule completely. Well the example is very realistic, it's exactly what kde has been doing for years, for the reason I mentionned. What's more, it's just an example :) > ~/.local/share/mime/packages/Override.xml > ~/.local/share/mime/packages/*.xml > /usr/local/share/mime/packages/Override.xml > /usr/local/share/mime/packages/*.xml Yes, this is what I understood. That part is quite flexible, but the generated output isn't. If in ~/.local/share/mime/packages/Override.xml I redefine a mimetype, that redefinition should indeed override the one from /usr/local/... But it can't do that, since the generated files are concatenated together, so the ~/.local stuff only adds stuff. Solution 1 would be to generate a ~/.local/share/mime/allglobs (and allmagic, allaliases etc.) which would contain all globs/magic/aliases definition; the merged view of global and local. Applications would only need to read those files, which would have all the info so they would be able to "remove" stuff that is defined in the global files. The added "all" suggested here is for compatibility reasons, to avoid changing the meaning of the existing local files. Solution 2 would be to add syntax for removing in the local globs, magic and aliases files. Like, starting a line with a "-" or something. However in both cases it means the general meaning of "what's defined in ~/.local" would change compared to the current spec. I wonder how much people currently have in ~/.local though, other than entirely new mimetypes, though, since no gui can really be done on top of the current spec imho ;) Defining new mimetypes in ~/.local would work the same, re-defining existing mimetypes would work with much more flexibility: really redefining instead of merely adding rules. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
