Re: [Shotwell] shotwell-book: A new project that allows you to create a PDF photo book from your Shotwell library

[Jim Nelson <jim yorba org>]

On Wed, Aug 20, 2014 at 4:08 PM, Norbert Preining <preining logic at> wrote:

In the first step I would implement only *query* support, so no syncronization with a running shotwell is necessary. Doing operations via the cmd line is more advanced and I am not sure if that makes sense.

Yes, I would stick with queries to begin with.  To give a broad overview of Shotwell's database-memory model:

* Shotwell *heavily* caches the database in memory for speed reasons.  Thus, a query for information is probably best served by looking at the objects in memory and returning that rather than an actual SQLite transaction.

* Shotwell only goes out to the database to read information when it does not have it in memory.  There's very little no kept in memory, however.

* Shotwell writes changes to the database as soon as the user requests it.  That is, Shotwell doesn't delay the write in order to do it in the background, a common scheme in these kinds of situations.

I guess the question I have is, what kind of syntax would this CLI have.  One approach would be straight-up SQL syntax, but I would strongly argue against that; the whole point of this is that the database schema should not be exposed to users because it can change at any time.  Just to get the ball rolling, I can imagine a dot schema that works something like this ("shq" is "Shotwell query"):

$ swq event[12345].description event[12345].title event[12345].photo_ids

Returns:

Beautiful Tokyo

Tokyo Trip, 2014

101;102;103;104;110;112;

The command-line accepts attributes that can be queried.  The number in the square brackets is the event identifier.  event.description and event.name return a string.  (We will need to deal with multiline strings, as description supports them.)  event.photo_ids generates a semicolon-delimited list of photo identifiers.  From this a program could then execute:

$ swq photo[101].title photo[102].camera photo[103].orientation

... and so forth.  Note that photo.camera is referring to the EXIF camera identifier, which is not stored  in the database or memory.  In this situation, Shotwell would read the metadata from the photo file and return that to the caller.

I'm just riffing off the top of my head, but this is the direction I'm thinking of.

Anyway, with this said, I am happy to dig (again) into some shotwell features and bugs ;-) One is actually open since long, the comment editing of events feom the event screent jumps to the comment of the first photo instead of the event comment ;-)

Great!  Look forward to seeing it.

-- Jim