On Wed, 2009-04-08 at 12:32 +0200, David Faure wrote: > On Wednesday 08 April 2009, Alexander Larsson wrote: > > On Wed, 2009-04-08 at 11:56 +0200, David Faure wrote: > > > On Wednesday 08 April 2009, Alexander wrote: > > > > I think the reason the globs are a per-glob map is that when the globs > > > > are stored in the mime.cache file some of the items (suffixes, literals) > > > > are stored sorted. > > > > > > Ah. I don't know anything about mime.cache ;-) > > > > You use a similar thing, right? ksyscoca? How does that work, is it also > > mmaped by apps, or is it an ipc thing? > > Yes, ksycoca is mmap'ed by apps (or uses shared memory on Windows). > If mmap or shared-mem fails, we fall back to a plain file (seeking and reading > into it at specific offsets just like we do with the mmap'ed data). > > > > > I can have a go at fixing this. However, there is an issue here with the > > > > ordering. There is a given order for the patterns in the xml files, but > > > > the globs file is sorted by glob weight. With a stable sort this would > > > > only be a problem if a glob that is not the main extension for the file > > > > has a larger weight. Is this a problem? > > > > > > Hmm. The point of glob weights is to choose between two mimetypes that > > > use the same glob; > > > not to order the globs of a single mimetype. But glob weights have that > > > side effect, though, indeed. > > > Let's see. Hmm. Let's say we have, > > > 50:app/foo:foo.* > > > 50:app/bar:*.gbar > > > 10:app/bar:*.bar > > > > > > The lower glob of 10 is there so that "foo.bar" is seen as app/foo rather > > > than as app/bar. > > > If we still want to say that *.bar is the main extension for app/bar > > > rather than *.gbar, > > > then we have a problem. But an easy solution too: changing the weight of > > > *.gbar to 10 too, > > > which only becomes a problem if that glob also conflicts with another > > > glob somewhere else... > > > > > > Given that we only have one use of glob weights right now this seems > > > rather unlikely, > > > but if we want to be on the really really safe side, we could simply... > > > ah yes, we could > > > preserve the <glob> elements in the generated app/bar.xml file? Then I > > > could just > > > read the preferred glob from there, and globs2 can keep its hash-based > > > implementation? > > > > Yeah, I was thinking about that too. Its probably a better idea than > > overloading the glob file order. > > Yeah, seems much simpler. And no overhead for me since kbuildsycoca is > already parsing > the xml files anyway (to read the <comment> tags). > > BTW with reference to our other discussion, this means <glob> and > <glob-deleteall> > nodes should both be written out into the generated .xml files, so that we > don't end > up using a deleted glob as the main extension :-)
I commited these two changes to update-mime-data.c in shared-mime-info. Can you test it and see if it works as you expect? _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
