Bug 72597 - detect Apple Keynote package format too
Summary: detect Apple Keynote package format too
Status: RESOLVED MOVED
Alias: None
Product: shared-mime-info
Classification: Unclassified
Component: freedesktop.org.xml (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Shared Mime Info group
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-11 12:57 UTC by David Tardon
Modified: 2018-10-13 10:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
patch (152.09 KB, patch)
2013-12-11 12:58 UTC, David Tardon
Details | Splinter Review
updated patch (150.82 KB, patch)
2013-12-11 16:51 UTC, David Tardon
Details | Splinter Review
updated patch (1.94 KB, patch)
2013-12-11 18:01 UTC, David Tardon
Details | Splinter Review

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.