Hi Michael, Eric is correct, but I'd like to expand on some of his comments.
First, I played with libdmapsharing a few months ago with this very project in mind. I didn't scratch too deeply, so some of what follows may be from inaccurate assumptions of mine. You don't want to use Alien DB for this; that subsystem is for pulling photos out of other photo manager apps by perusing their databases (or whatever store they use). It's a one-shot deal, not something to be dynamically or interactively used. Although Eric is correct that the photos must be in the database to be manipulated in meaningful ways, that doesn't mean we need to rearchitect the program to support DPAP. It would simply be another subsystem available through the sidebar. I would think of DPAP like a camera device; that is, an external source of photos that may be imported into the database. If you want to attack this project, I would recommend building it in three steps: browsing, importing, and sharing. One important set of pages you should be aware of: http://trac.yorba.org/wiki/ShotwellArchitectureOverview Also: Although I'm the architect of Shotwell, I am no longer the tech lead. I'm just tossing out a game plan that may be tweaked or discarded by Adam and Lucas. They're the final word on how to run the ball. Browsing: 1. Build a "sharing" unit (see http://trac.yorba.org/wiki/ShotwellArchSourceOrganization) 2. In Sharing.init() and Sharing.terminate() call any DPAP code you need to start/end the discovery service. 3. Build a Sidebar.Branch populated with share points discovered by DPAP. See the Tags branch for a simple model. Note that it pulls Tags from an in-memory DataCollection; you'll be adding and removing them from the DPAP service. Since (as I recall) the DPAP object uses signals to notify of additions and removals of services, the model is almost a perfect match. 4. Attach the Branch to the Sidebar in LibraryWindow's ctor. At this point the Sidebar should display all DPAP share points on the local network. The next steps are to display the photos for each share when the user clicks on the name. 5. Build a DpapPage that inherits from CheckerboardPage. Each DpapPage represents a share point. A simple example to follow would be FlaggedPage. 6. Subclass SourceCollection and PhotoSource -> DpapSourceCollection and DpapSource. These represent the shared photos on the other machine. 7. Subclass CheckerboardItem -> DpapItem. This is the object that paints the thumbnail on the screen and displays its title and whatnot. 9. Each page should instantiate it's own DpapSourceCollection (like CameraPages do, one SourceCollection per camera). 10. Each Page has its own a ViewCollection (available via get_view()). Use ViewCollection.monitor_source_collection to automatically populate the ViewCollection when photos are added/removed to the DpapSourceCollection via DPAP. 11. The page should then query DPAP for photos from its share point, create DpapSource's, and add them to its DpapSourceCollection. The page will display the DpapItems accordingly. When this happens is open to debate; a simple place to put it would be the first time DpapPage.switched_to() is called. At this point Shotwell will be able to browse all DPAP servers on the network. I know that looks like a lot of steps, but they (roughly) fulfill the MVC model. Your DpapPage can be generically examined by other subsystems. For example, by implementing PhotoSource, the Basic Information pane should be able to show details about each photo when the user clicks on it. The usual view features (sorting, filtering, selection) will just work as well. Importing: This is where things are murky to me. Shotwell, like iPhoto, is a non-destructive editor. Does DPAP allow for transformations to travel with the pristine photo, or do the shared photos travel on the wire in their transformed state? I suspect the latter, since it's far easier. Like CameraPage, the photo files should be copied from the server to the local disk. A BatchImportJob should be created for each one and handed to a BatchImport object. This in turn is given to LibraryWindow, which changes to the ImportQueuePage and runs the import from there. See CameraPage and BatchImport for more information. Sharing: I think the use model here is to create a Share folder, drag photos into it, and then DPAP offers them on the local net. The coding steps in "Browsing" would be similar here, but instead of displaying photos from DPAP, they would be drawing from the LibraryPhotoSourceCollection. Presumably there's a database table that lists each share point and the MediaID's of the objects being shared. (If you get this far, I suspect you'll know the code well enough to finish the job, which is why I'm not laying it out step by step.) Once again: I'm not the tech lead, all this should be discussed and agreed upon with Lucas and Adam. But this is how I would do it, with what I know of DPAP. -- Jim On Wed, May 25, 2011 at 11:47 AM, Eric Gregory <[email protected]> wrote: > On Wed, May 25, 2011 at 11:39 AM, W. Michael Petullo <[email protected]> > wrote: > > > I am the maintainer of libdmapsharing; I am investigating the idea of > > adding DPAP (iPhoto network browsing) support to Shotwell. I would like > to > > be able to browse photographs made available using DPAP (e.g., using > dmapd > > or iPhoto). Should I be focusing on learning the alien_db interface? I > > see the existing F-Spot implementation. Does this copy photographs into > > the native Shotwell database or operate on them in place? The latter is > > similar to how a DPAP database implementation would work. > > > > Is there any other code I should focus on reading? > > > > This is something we've talked about doing, but there's really no code in > place that you could easily hook this up to. The Alien DB code was created > for doing imports from other applications (namely F-Spot.) > > Now that said, the way Shotwell works is that all photos it knows about are > in the database. So without re-architecting too much, the simplest way > would likely be to store the remote photo information in the database, > presumably with some kind of new marker column so you know that it's remote > and can clean it up when the client disconnects. Perhaps the Alien DB > interface could be expanded to allow for this, or maybe you'd want to > create > a new interface from scratch. > > Anyway, I'm afraid I can't offer any advice that's too detailed because I'm > not super familiar with the way DPAP works. But it would be great if you > could look into adding this to Shotwell, and certainly a killer feature. > > - Eric > _______________________________________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
