Re: master and portable/detached libraries

[Ruben Vermeersch <ruben savanne be>]

On di, 2008-06-03 at 01:43 +0200, Jakub Steiner wrote:
> Hi f-spot developers.
> I'd like to pitch an idea I've had because of a need to cover the
> following workflow.
> 
> Like everybody else on the list I have shot a lot of pictures over the
> years. My 'cleaned up' library consist of around 40 thousand pictures.
> When I travel to shoot pictures I usually take my camera equipment and
> a small notebook computer. After a day shoot I import all my photos to
> F-spot running on the notebook, throw away the clearly poor shots, tag
> everything appropriately. When I go back home, I import them to my
> massive library and delete the temporary library and resume my work on
> the master library. There's a couple of disadvantages to this
> workflow:
> 
> - I cannot do any editing. There isn't an easy way to transfer versions.
> - Time consuming. Every time I do this, I have to repeat the process
> of mounting my notebook drive or copy files over to my desktop machine
> and manually import to my main library.
> - When things break during the process (wifi issues, f-spot, ehm,
> crash), it's not trivial to resume the import.
> - I get a single import event in my master library (if you don't
> manage to tag everything appropriately on the go, this can make things
> harder).
> 
> It would be cool to be able to tell f-spot that this particular
> installation is a temporary/mobile storage and tell it the location of
> the master database file and photo storage location. It would then
> have a tool to synchronize to the master library, tagging photos on
> the notebook as synchronized after success and allowing me to wipe the
> temporary library clean of photos that have been synchronized. It may
> even be cool to hint the user there are unsynchronized photos when the
> master library location is mounted/available, making the tool easier
> to access in that situation. So in essence you get:
> 
> - a proper photo editing toolchain on the go (f-spot + gimp)
> - a better indication there's no photos 'in the void'
> - less room for errors
> - better speed. While f-spot is reasonably fast managing a large
> library, at 40k it does get a bit slower.
> 
> I would love to turn this into a proper functional spec, but I'd like
> to check for potential interest /comments here first.

I'm all for having this. The problems aren't even technical: we're
developers, we can juggle bits around until it works. It's mostly the
problem of how we're going to put this together.

There's a lot of ideas floating around (easily recognisable by the
starting words "what would be really cool for F-Spot..."), but once you
start thinking on how to combine all of them, you end up with a
gargantuan piece of complexity, the kind of applications that used to
haunt the KDE desktop.

What we need is a good plan on incorporating all this cool stuff,
without turning into a usability nightmare. A UI proposal that my mom
can use, a workflow that's intuitive in all cases.

I'll gladly help (probably after my GSoC) implementing this. The hardest
part is not putting it in code, it's deciding what to build and
therefore I'm highly interested in good specs.

Especially since the above covers my workflow as well :-)

Cheers,
   Ruben


--
Ruben Vermeersch (rubenv)
http://www.savanne.be