[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xdg
Subject: Re: shared-mime-info questions
From: David Faure <dfaure () trolltech ! com>
Date: 2007-02-02 21:58:32
Message-ID: 200702022258.33501.dfaure () trolltech ! com
[Download RAW message or body]
On Friday 02 February 2007, Thomas Leonard wrote:
> On 1/28/07, David Faure <dfaure@trolltech.com> 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, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[Attachment #3 (text/html)]
<html><head><meta name="qrichtext" content="1" /></head><body \
style="font-size:9pt;font-family:Sans Serif"> <p>On Friday 02 February 2007, Thomas \
Leonard wrote:</p> <p>> On 1/28/07, David Faure <dfaure@trolltech.com> \
wrote:</p> <p>> > Hello,</p>
<p>> > I'm starting to implement shared-mime-info for KDE4.</p>
<p>> > I hadn't read the spec for a very long time, so I did it again, and: I \
still like it very much :)</p> <p>> > I just have a few questions.</p>
<p>> </p>
<p>> (note: I'm not the maintainer any more, but I'll try to answer some of</p>
<p>> this anyway)</p>
<p></p>
<p>Thanks. You probably have best insight into why things were specified this way \
;)</p> <p></p>
<p>> > First question: user overrides.</p>
<p>> > > 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.</p> <p>> > > 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).</p> <p>> > The first \
sentence puts XDG_DATA_HOME first; the second sentence puts ~/.local in the directory \
list;</p> <p>> </p>
<p>> That sentence doesn't say what order should be used. Normally, reading</p>
<p>> the lowest-priority files first is desirable, although it depends how</p>
<p>> you want to implement it, of course. </p>
<p>Of course, that's not what I meant. To apply precedence correctly, one can \
read</p> <p>from global to local (and add at every level) or from local to global \
(and skip already seen stuff).</p> <p>What matters is to define which directory has \
more precedence than which other.</p> <p>OK I agree that it's probably obvious which \
one has precedence, it just reads strangely</p> <p>when two sentence seem to \
contradict each other.</p> <p></p>
<p>> > However, how does that allow the user to remove a pattern->mimetype \
association?</p> <p>> > For instance, /usr/share/mime/globs says \
application/msword:*.doc</p> <p>> > but since this gives a wrong mimetype to \
e.g. /usr/share/doc/cvs/contrib/intro.doc</p> <p>> > how can I, as a user, \
remove the "application/msword:*.doc" association?</p> <p>> </p>
<p>> You'd have to define a higher priority rule to match them.</p>
<p>Well, if the user assigns *.doc to another mimetype then indeed that one will have \
precedence.</p> <p>But if you just want to remove the rule, you can't.</p>
<p></p>
<p>> You can't disable rules in the current spec.</p>
<p>I think this removes control from the user. And it makes for a bad GUI too: a user \
can define his</p> <p>own mimetype, so the GUI must allow to edit globs for \
mimetypes. But then for some mimetypes</p> <p>(those he created), he can add/remove \
globs, whereas for other mimetypes (those defined globally),</p> <p>he can't remove \
globs. Well, he can, if he added them himself, but not otherwise. Argl ;)</p> <p></p>
<p>> I'm not sure the example is very realistic... most .doc files are Word</p>
<p>> documents so I don't think you'd want to disable the rule completely.</p>
<p>Well the example is very realistic, it's exactly what kde has been doing for \
years,</p> <p>for the reason I mentionned.</p>
<p>What's more, it's just an example :)</p>
<p></p>
<p>> ~/.local/share/mime/packages/Override.xml</p>
<p>> ~/.local/share/mime/packages/*.xml</p>
<p>> /usr/local/share/mime/packages/Override.xml</p>
<p>> /usr/local/share/mime/packages/*.xml</p>
<p>Yes, this is what I understood. That part is quite flexible, but the generated \
output isn't.</p> <p>If in ~/.local/share/mime/packages/Override.xml I redefine a \
mimetype, that redefinition</p> <p>should indeed override the one from /usr/local/... \
But it can't do that, since the generated</p> <p>files are concatenated together, so \
the ~/.local stuff only adds stuff.</p> <p></p>
<p>Solution 1 would be to generate a ~/.local/share/mime/allglobs (and allmagic, \
allaliases etc.)</p> <p>which would contain all globs/magic/aliases definition; the \
merged view of global and local.</p> <p>Applications would only need to read those \
files, which would have all the info so they would</p> <p>be able to \
"remove" stuff that is defined in the global files. The added \
"all" suggested here</p> <p>is for compatibility reasons, to avoid changing \
the meaning of the existing local files.</p> <p></p>
<p>Solution 2 would be to add syntax for removing in the local globs, magic and \
aliases files.</p> <p>Like, starting a line with a "-" or something.</p>
<p></p>
<p>However in both cases it means the general meaning of "what's defined in \
~/.local" would</p> <p>change compared to the current spec. I wonder how much \
people currently have in ~/.local</p> <p>though, other than entirely new mimetypes, \
though, since no gui can really be done on top</p> <p>of the current spec imho ;)</p>
<p>Defining new mimetypes in ~/.local would work the same, re-defining existing \
mimetypes</p> <p>would work with much more flexibility: really redefining instead of \
merely adding rules.</p> <p></p>
<p>-- </p>
<p>David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,</p>
<p>Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).</p>
<p></p>
</body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic