iPhoto 9.3 / Aperture 3.3

[Houdah - ML Pierre Bernard]

Hi!

A customer has reported that iMedia fails to load his iPhoto 9.3 library. This library is jointly used by iPhoto and Aperture.

Looking at AlbumData.xml, I find the following structure:

Aperture (AlbumId 1, Album Type 98)
| Aperture Library (AlbumId 2, Album Type 99)
| Library (AlbumId 3, Album Type 5)
| Projects (AlbumId 4, Album Type 97)
| Flagged (AlbumId 5, Album Type Flagged)

- [IMBiPhotoParser shouldUseAlbum:images:] prevents the root "Aperture" node from being loaded as it has no KeyList.

But even when I force that node to be loaded, I can't get iMedia to load the child nodes. More precisely: I am under the impression, that - [IMBiPhotoParser addSubNodesToNode:albums:images:] does load one subnode, but this does not show in the interface.

The full AlbumData.xml file is at https://dl.dropbox.com/u/2381634/AlbumData.xml.zip

I hope for someone more knowledgable in the iPhoto parser to have better luck figuring out what is going on.

Best,
Pierre

[Rimas Mickevičius]

Hello everybody,

I am wondering - where did you get this entitlement (com.apple.security.temporary-exception.shared-preference.read-only) from? It is mentioned in sandboxed version branch. I haven't seen it in Apple documentation (maybe missed?), so I am not sure if it is legal to try using in App for Mac App Store?

Regards,

Rimas M.

[Mike Abdullah]

On 28 Jun 2012, at 09:49, Rimas Mickevičius wrote:

> Hello everybody,
>
> I am wondering - where did you get this entitlement (com.apple.security.temporary-exception.shared-preference.read-only) from? It is mentioned in sandboxed version branch. I haven't seen it in Apple documentation (maybe missed?), so I am not sure if it is legal to try using in App for Mac App Store?

According to the guys at the WWDC lab:

- It was introduced in 10.7.3
- They haven't gotten around to documenting it
- It's fine for us to use it for iMedia and tell other people about it (i.e. it's not private)

That branch isn't quite finished still though. The file watcher is watching too much for the sandbox's liking. I am working on it.

[Daniel Jalkut]

I'm curious if this branch is part of the same sandboxing effort that the Boinx folks are working on, or is it completely separate?

Daniel

[Mike Abdullah]

On 28 Jun 2012, at 14:05, Daniel Jalkut wrote:

> I'm curious if this branch is part of the same sandboxing effort that the Boinx folks are working on, or is it completely separate?

Very different. I'm working to patch up the existing codebase to play nicer within the sandbox. The Boinx work is to move iMedia out to an XPC process so that the host app needs fewer entitlements.

[Daniel Jalkut]

Thanks for the clarification! It sounds like different folks will differ from either solution, assuming both will meet approval by app review.

I seem to recall that the XPC approach was what Ivan at Apple recommended a year ago when we were all first asking about iMedia's viability. I wonder if he will recommend approval of a solution that doesn't involve XPC. Any hints on that front?

Daniel

[Peter Baumgartner]

Hi everybody,

As Mike already mentioned, he is patching the 2.x branch to make sandbox compatible, whereas the new version that Jörg and I have been working on (with a lot of help from Mike, Pierre, and now Christoph) is based on a new completely asynchronous architecture, with the parser classes living in XPC service bundles. These XPC services have the necessary broad entitlements (often temporary entitlements), while the app itself has barely any entitlements.

By dragging a media object from iMediaBrowser to the host app, a (temporary) hole is punched into sandbox, giving the app access rights to this file (much like the Powerbox is doing).

BTW, our upcoming FotoMagico 4 release is using the new iMedia 3 architecture. We'll soon find out what the app store reviewers have to say about it. I'll let you guys know.

Peter

[Rimas Mickevičius]

Thank you for replying. Sounds like this is nice temporally solution for accessing iApps preferences.

I also trying to patch our old (early 2.x, checked out last autumn, I think) browser version to work with sandboxed app without "//" entitlement. For custom folder access I am using security scoped bookmarks. Now I need to to the same with iPhoto/Aperture libs, that are outside ~/Pictures.

P.S. Looks like there is some parsing problems with updated Aperture (3.3) libraries?

Rimas M.

[Mike Abdullah]

On 29 Jun 2012, at 08:36, Rimas Mickevičius wrote:

> Thank you for replying. Sounds like this is nice temporally solution for accessing iApps preferences.
>
> I also trying to patch our old (early 2.x, checked out last autumn, I think) browser version to work with sandboxed app without "//" entitlement. For custom folder access I am using security scoped bookmarks. Now I need to to the same with iPhoto/Aperture libs, that are outside ~/Pictures.

Is that work up on github too? I need to do bookmark support soon and it would be convenient to just pull in yours!

>
> P.S. Looks like there is some parsing problems with updated Aperture (3.3) libraries?

Yeah, should be fixed in latest pull request I merged from a few days ago.

[Rimas Mickevičius]

On 2012.07.01, at 02:08, Mike Abdullah wrote:

> On 29 Jun 2012, at 08:36, Rimas Mickevičius wrote:
>
>> Thank you for replying. Sounds like this is nice temporally solution for accessing iApps preferences.
>>
>> I also trying to patch our old (early 2.x, checked out last autumn, I think) browser version to work with sandboxed app without "//" entitlement. For custom folder access I am using security scoped bookmarks. Now I need to to the same with iPhoto/Aperture libs, that are outside ~/Pictures.
>
> Is that work up on github too? I need to do bookmark support soon and it would be convenient to just pull in yours!

No, it isn't. The reason is that we are using browser only for images and it is very customized. For this reason we are still based on outdated browser code - more than 6 months I think.
As for security scoped bookmarks, they are straight forward - when user adds something, I create a new bookmark and save its data to NSUserDefaults, when I am going to use it after relaunch (loading custom parsers), I am resolving URL from saved data. Thats it.

>>
>> P.S. Looks like there is some parsing problems with updated Aperture (3.3) libraries?
>
> Yeah, should be fixed in latest pull request I merged from a few days ago.

Great. Looks like the day browser code MUST be updated in our app is coming...

[Mike Abdullah]

Hi Pierre, just wanted to check: this is fixed for you now, yes?

[Mike Abdullah]

I figure Peter and others would be interested to hear why you needed to customise in the first place. One of 2.0’s design goals was to make it much easier for clients to customise the browser, or build their own from supplied pieces without having to resort to editing the framework itself. Perhaps there’s a use case we haven’t accounted for.

[Houdah - ML Pierre Bernard]

Hi Mike,

For some odd reason the AlbumData.xml file in the customer's iPhoto library followed the Aperture XML format.

Neither Jörg nor I were able to reproduce a similar situation.
When the customer deleted the AlbumData.xml file, iPhoto re-created it following the expected format.

For now, I think we should ignore this one-time event.

Pierre