[Shotwell] Accessing an alternative database

Tue Jan 4 01:10:50 UTC 2011

Your email touches on a number of features we've been thinking about and/or
have been wishlisted by a number of users.

To start with the more low-level technical stuff, as far as the umask of the
photo.db file, we rely on Sqlite to create the file if it doesn't exist,
which (presumably) creates the file with default permissions.  We might be
able to work around this by updating the umask after creation, but I'd need
to think more about that.  Thumbnails would need to have the same logic
(since we don't create the files but rely on gdk-pixbuf to produce the JPEG
files), and for that matter, just about everything that's written to the
library directory would need to be patched up.

A side issue here is that, even if we did get such a setup working, there's
no way you can run two Shotwell instances against the same database, i.e.
with user switching.  Shotwell is simply not built for this.

We've talked about (and have ticketed) various ideas to ease sharing
libraries between machines, which could be extended to sharing libraries on
the same machine.  We've also thought about making a libshotwell that would
make the library available to multiple clients in a safe way.

As has been ticketed, we need to have better error-handling when the
database is not writeable -- no question there.  Support for a read-only
database is a bit trickier, as not only is there the permissions problem,
but also reflecting the read-only state in the UI.  Every operation that
modifies, updates, or adds items to the library must be grayed out (or, in
my view, should be).  It's probably just easier to build a Shotwell library
browser that is built from the ground-up to work in read-only mode.  Just
thinking out loud here.

As far as storing the metadata (Shotwell's metadata plus the standard stuff)
in the photo files themselves, or in a sidecar or a hidden directory, as
you've said, that's something we've been considering as well.  That path has
a lot of glitter to it, because it couples the metadata with the photo file
itself, which is the way you want to go.  I have some performance concerns,
however, and I'm wary of the database being a cache because date duplication
(in my experience) creates buckets of bugs if not thought all the way
through.

On top of all this, every user has different feelings about where the data
should reside: in the master file, in a sidecar, hidden directory, hidden
file, etc.  RAW files (not always modifiable) add a twist to the problem.

Anyway, that's my brain dump about all of this.  Solving your immediate
problem of creating a shared library writeable by two accounts is not
something I think can be solved at this time.  One possibility (off the top
of my head): create a dummy shotwell account and sudo to it to run
Shotwell.  This might introduce other complications but might solve your
immediate problem.  (Test this with data you can afford to lose, obviously.
I've not even tried it.)  And, as noted before, make sure only one instance
of Shotwell is running at a time.

-- Jim

On Sun, Dec 26, 2010 at 2:11 PM, Brian Candler <B.Candler at pobox.com> wrote:

> Hi,
>
> I have a problem finding a good way to set up shotwell (testing using 0.7.2
> under Ubuntu Lucid)
>
> The scenario: both myself and my wife use the same computer at home. We
> have
> our own home directories and logins.  My wife has her own smartphone and I
> want her to be able import into her own photo library without my
> assistance.
>
> I would also like to be able to browse my wife's photo collection, and she
> to be able to browse mine.  But I don't want to import all her photos into
> my collection (and vice versa), because any tagging, events, image
> adjustment etc will have been lost.
>
> Permissions are set up so that I have read-access to her home directory,
> and
> vice versa. But unfortunately that's not good enough for shotwell:
>
> $ shotwell -d ~caroline/.shotwell
>
> ** ERROR **: DatabaseTables.vala:55: execute_update_by_id: [8] attempt to
> write a readonly database
> aborting...
> Aborted
>
> (Her photo collection *does* appear for about half a second before shotwell
> terminates with the above error message)
>
> So this gives a potential feature request 1: be able to browse a photo
> collection even if you only have read access to it.
>
> Having to start with a -d flag is also a bit manual, so potential feature
> request 2 would be to add multiple libraries within the GUI, and be able to
> switch between them (e.g.  with a drop-down menu).  Unfortunately I that
> might open the floodgates to some more complex requests though, like being
> able to add a photo from one collection into another.
>
> Another option is to combine our collections, and make ~/.shotwell in both
> home directories point to a common area.  This would involve setting up a
> group which is writeable to us both (ok), setting the setgid bit so that
> files and subdirs inherit that group (ok), and getting shotwell to use the
> correct umask.  That last one doesn't appear to be well supported by
> shotwell today (0.7.2 under Ubuntu Lucid).  As a test, if I do
>
>    (umask 002; shotwell -d ~/.shotwelltest)
>
> then the directories are created with group write permissions, but photo.db
> is stil created mode 644.
>
> $ ls -lR /u/home/brian/.shotwelltest/
> /u/home/brian/.shotwelltest/:
> total 12
> drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 data
> drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 mimics
> drwxrwxr-x 4 brian brian 4096 2010-12-26 21:50 thumbs
>
> /u/home/brian/.shotwelltest/data:
> total 12
> -rw-r--r-- 1 brian brian 10240 2010-12-26 21:50 photo.db
>
> /u/home/brian/.shotwelltest/mimics:
> total 0
>
> /u/home/brian/.shotwelltest/thumbs:
> total 8
> drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 thumbs128
> drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 thumbs360
>
> /u/home/brian/.shotwelltest/thumbs/thumbs128:
> total 0
>
> /u/home/brian/.shotwelltest/thumbs/thumbs360:
> total 0
>
> I haven't tried testing anything else, e.g. what permissions thumbnail
> files
> are written with, but I don't really want to be a trailblazer if nobody
> else
> is using shotwell this way and it's likely to cause problems.
>
> One day maybe all the metadata will be stored within the photos themselves
> or on the filesystem(*), and sqlite3 would just become a cache of that
> data.
> This is something I know has been discussed before, and may eventually
> provide a solution, but I'd like to start using shotwell now.
>
> We can just browse each other's Pictures directories using gthumb, but
> that's painful given the YYYY/MM/DD directory structure which shotwell
> imports to.
>
> Any other suggestions?
>
> Thanks,
>
> Brian.
>
> (*) I'd also like to sync my photo collection from my home PC to my laptop,
> and have the metadata sync too. 'unison' handles file replication both ways
> nicely, but independent updates to the sqlite3 database can't be resolved.
> For now I can live with the photo database just being on the desktop.
> _______________________________________________
> Shotwell mailing list
> Shotwell at lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>