Bug 72597

Summary: detect Apple Keynote package format too
Product: shared-mime-info Reporter: David Tardon <dtardon>
Component: freedesktop.org.xmlAssignee: Shared Mime Info group <shared_mime_info>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: patch
updated patch
updated patch

Description David Tardon 2013-12-11 12:57:06 UTC
Keynote 5 is the only version of Keynote that produces single files (at least by default). Previous versions saved a package (IOW, a directory) and Keynote 6 does that again.

I use the same mimetype for all versions, even though they are three different formats, as that is what Apple does too. (That is, Keynote 6 installation lists the same mimetype as 5 in Info.plist. Versions prior to 5 had not had any mimetype associated with them.)
Comment 1 David Tardon 2013-12-11 12:58:15 UTC
Created attachment 90605 [details] [review]
patch
Comment 2 Bastien Nocera 2013-12-11 13:25:37 UTC
This is good, but don't the keynote "directories" have a stable suffix?

Eg. OSX apps use ".app". This would make the detection much easier, directories with "*.keynote" would be keynote packages, without the need to dive into the tree (which could be quite expensive on remote filesystems).
Comment 3 David Tardon 2013-12-11 16:24:04 UTC
(In reply to comment #2)
> This is good, but don't the keynote "directories" have a stable suffix?
> 
> Eg. OSX apps use ".app". This would make the detection much easier,
> directories with "*.keynote" would be keynote packages, without the need to
> dive into the tree (which could be quite expensive on remote filesystems).

Yes, they all have suffix ".key". If you think the matching for internal files is not really necessary, good. I will send an updated patch shortly.
Comment 4 Bastien Nocera 2013-12-11 16:30:06 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > This is good, but don't the keynote "directories" have a stable suffix?
> > 
> > Eg. OSX apps use ".app". This would make the detection much easier,
> > directories with "*.keynote" would be keynote packages, without the need to
> > dive into the tree (which could be quite expensive on remote filesystems).
> 
> Yes, they all have suffix ".key". If you think the matching for internal
> files is not really necessary, good. I will send an updated patch shortly.

I think that matching directories with ".key" should be enough. I'm not sure how well it works in practice, but now's the time to get bugs fixed :)
Comment 5 David Tardon 2013-12-11 16:51:06 UTC
Created attachment 90615 [details] [review]
updated patch

Okay, here is an updated patch. But I have no idea how to add the new "files" to the testsuite to make it work.
Comment 6 Bastien Nocera 2013-12-11 16:53:43 UTC
(In reply to comment #5)
> Created attachment 90615 [details] [review] [review]
> updated patch
> 
> Okay, here is an updated patch. But I have no idea how to add the new
> "files" to the testsuite to make it work.

Add a dummy file inside the directory.
Comment 7 David Tardon 2013-12-11 18:01:05 UTC
Created attachment 90617 [details] [review]
updated patch
Comment 8 David Tardon 2013-12-11 18:05:23 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 90615 [details] [review] [review] [review]
> > updated patch
> > 
> > Okay, here is an updated patch. But I have no idea how to add the new
> > "files" to the testsuite to make it work.
> 
> Add a dummy file inside the directory.

That is actually a good idea, but it is not what I meant (I had nearly complete content in the .key dirs). I cannot get the test to succeed. When I add the .key dirs to tests/tree-list, nothing is matched. And the tests/list test apparently always tries to open the tested path as a file, so it fails also.
Comment 9 Bastien Nocera 2013-12-11 18:13:20 UTC
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Created attachment 90615 [details] [review] [review] [review] [review]
> > > updated patch
> > > 
> > > Okay, here is an updated patch. But I have no idea how to add the new
> > > "files" to the testsuite to make it work.
> > 
> > Add a dummy file inside the directory.
> 
> That is actually a good idea, but it is not what I meant (I had nearly
> complete content in the .key dirs). I cannot get the test to succeed. When I
> add the .key dirs to tests/tree-list, nothing is matched. And the tests/list
> test apparently always tries to open the tested path as a file, so it fails
> also.

Yeah, I guess this is going to be a problem for most implementations of this specification. We'll have to discuss this...
Comment 10 Bastien Nocera 2014-04-01 12:09:03 UTC
This won't work. The spec says that matching is only done on files, not on directories. The specification would need to be changed to allow a separate directory glob.

Something like this:
+ <!ATTLIST glob type (file|directory) #IMPLIED>

with file being the default implied value. This would also require loads of fixes in the stack. I'm not personally going to implement this, but patches would be accepted.
Comment 11 GitLab Migration User 2018-10-13 10:37:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/26.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.