main extension for a mimetype
dfaure at trolltech.com
Fri Jan 30 15:41:26 PST 2009
On Wednesday 02 July 2008, David Faure wrote:
> On Wednesday 02 July 2008, Bastien Nocera wrote:
> > On Tue, 2008-07-01 at 15:46 +0200, David Faure wrote:
> > > The concept of the "main" extension for a mimetype is missing in
> > > shared-mime-info,
> > > (which constitutes a regression compared to our earlier system).
> > <snip>
> > > I see two solutions:
> > > 1) fixing update-mime-database to respect the order of the globs [but
> > > this is a bit of an undocumented use of that order]
> > I'd go for this one, and documenting it. It would avoid a revup of the
> > mime cache version, and unbreak your application for free.
Do you have any hints on how to implement that?
How could we ensure that the generated globs file respects the order of the globs defined in the XML?
I wanted to implement it rather than bug you about it, but I admit that I don't really
understand the way it's done now; why is there a pattern -> mimetype hash?
It isn't really used as a hash (except when inserting into it), right? I think this is what
would need to be changed into a simple list of Globs?
I gave it a try (type safety is really difficult with glib...) but it turns out that write_map expects
a hash and there's no variant with a list, so I'm stumped (it compiles, against expectations,
but it crashes, obviously). Well, it explains why it's a hash in the first place, but....
Can you confirm the approach and finish the patch, or provide a better approach?
[maybe it should be a mimetype->glob_list hash, if it has to be a hash?]
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6762 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090131/f2010a97/attachment.diff
More information about the xdg