[Shotwell] Some Ideas of mine

[Adam Dingle]

Kenneth,

On 05/14/2010 12:06 AM, Kenneth Jernigan wrote:
> Hello,
>
> I've been playing with Shotwell for a few days and looking over the
> backend/code structure in my spare time.  I hope to be able to take some
> time to experiment with the Vala programming language and perhaps toy with
> some of these ideas I have.  However, I felt it best to share them and let
> the masses decide if my idea(s) are worth the time I spent typing...  Thus,
> I send the following ideas:
>
> 1.)  The undo feature is great - however, I notice it's only for the current
> session and is lost following a restart of the application.  However, I
> noticed that in the database, all of the transforms are kept there.  Thus,
> my first thought is that Shotwell should be able to undo ANY transform at
> ANY time (This could also allow re-arrange of the transforms without needing
> to redo them).  An example... if I've taken time to perform a Red-Eye
> removal and performed an Enhance and then later decide to "un-enhance" the
> photo, I must now spend time re-performing the Red-Eye.  (A "history" could
> be added to the Side Bar)
>    

Shotwell already allows you to adjust or undo almost any transform at 
any time.  To use the example you gave, suppose that you're performed an 
Enhance operation and then a Red-eye operation.  The Enhance operation 
automatically sets the position of various sliders in the Adjust dialog 
- it does nothing more and nothing less.  So if you want to undo an 
Enhance operation, you can simply open the Adjust dialog and press 
Reset.  The autoenhance will be undone, but any red-eye operation you've 
performed will still be intact.

Notice that I said /almost/ any transform in the paragraph above.  Once 
you've restarted Shotwell, there's currently no way to undo a red-eye 
operation without reverting the photo to original.  All other 
operations, though, including cropping, adjusting and enhancing can be 
independently adjusted at any time.  This is all by design.

Today, the order of operations in the Shotwell image pipeline is fixed.  
We could conceivably consider other transformation models, e.g. where 
each photo has a ordered history of operations which you can view in the 
sidebar and control independently.  That would be a large change to 
Shotwell and is something we could conceivably undertake someday.  I 
think the current model works well for most casual photo editing needs, 
though.

> 2.)  The first thought led me to my second thought.   The layout of the
> transforms in the database appear to me like they might be un-optimized.
>   I'm not sure on all of the timing of Shotwell (mostly due to my lack of
> knowledge of the code -- still learning), however, it would seem to me that
> using text string processing would be using resources and limit the
> reasonable growth of the database. I would think, instead, that a separate
> table of transforms would be stored, capturing a different transform in each
> table entry.  Then, the photo table would have a list of associated
> transform keys (in order).   While the transform parameters in the table
> would still be text, the amount of text parsing could be reduced, or even
> offloaded into the transform function.  I could even see this opening the
> door for plug-in style transform updates. However, I do not know the time
> the SQL database takes to query compared with string parsing, but I know
> database queries are already performed to read the Tags and  Events, so I
> assume not too much time is lost.
>    

I'm wary of speculating which operations inside Shotwell are performance 
bottlenecks without running profiling tools or other performance 
measurements.  I don't think we have any reason to believe that string 
processing is a bottleneck today, however.  If there are specific 
operations in Shotwell that you think are too slow and which are bounded 
by CPU time, I'd encourage you to run a profiling tool (I suggest 
Sysprof - see http://sysprof.com/) to see where the bottleneck lies.  
After that we'd be happy to discuss possible optimization work.

> 3.)  Specifically, I miss a few types of transforms:
>
>     - the ability to create a sepia or B/W photo. I know this can
>     be achieved with careful manipulation of the Adjust sliders, but predefined
>     filters will improve user performance.
>    

A reasonable idea.  I've ticketed this at 
http://trac.yorba.org/ticket/1913 .

>     - Soft Focus feature - great for hiding complexions and creating affects
>    

This would be another nice feature.  Ticketed at 
http://trac.yorba.org/ticket/1916 .

>     - Rotate (straighten) -- I saw a ticket for this already.
>    

Right - this is http://trac.yorba.org/ticket/61 (currently the 
lowest-numbered outstanding Shotwell ticket, by the way).

>     - Sharpen -- sometimes photos come too soft/blurred.  It'd be nice to fix
>     without loading GIMP.
>    

Right.  We have a ticket for this at http://trac.yorba.org/ticket/690 .

>     - Faded borders -- one of my wife's favorites features when prepping a
>     photo for print.
>    

Another reasonable idea.  I've ticketed this at 
http://trac.yorba.org/ticket/1914 .

>     - Flip -- rotate 180 + mirror.
>    

This shouldn't be needed all the time, but could occasionally be 
useful.  I've created a ticket at http://trac.yorba.org/ticket/1915 .

>
> 4.)  A struggle I've had with Shotwell is it's lack of multiple
> keyboard/mouse inputs.  I will list here the keyboard/layout/mouse gestures
> I keep trying to use but can't:
>
>     - When I've zoomed to a picture, I expect my scroll wheel to move me to
>     the next -- but no luck.
>    

In the trunk build, the scroll wheel zooms into a picture - this is one 
of our major new features for 0.6.  I think we'll continue to use the 
scroll wheel for this rather than for advancing between pictures, for 
consistency with other GNOME applications (e.g. Eye of GNOME) which also 
use the scroll wheel for zooming.

>     - When I press backspace from a picture page, I expect to return to the
>     Photos page (legacy effect of internet explorer).

We've had conflicting user requests for the Backspace key: some people 
want it to move to the previous photo (this is currently implemented in 
trunk), and others like you want it to jump back a level.  (By the way, 
I hope you realize that the Escape key does jump back a level, i.e. to 
the Photos view.)  There is precedent for both uses of Backspace in 
other GNOME applications: in Nautilus it jumps back a level (to the 
containing directory) but in Eye of GNOME it moves to the previous 
photo.  I personally don't have a strong opinion about this since there 
are already other keys (Escape and left arrow) for each of these operations.

> Same is true for my
>     mouse's browser back button.
>    

It would be nice to support the mouse's back button.  I've ticketed this 
at http://trac.yorba.org/ticket/1917 .

>     - When I have a red-eye tool on the screen, I try to get precise
>     placement control with the arrow keys -- doesn't work.
>    

Right.  This is http://trac.yorba.org/ticket/1144 .

>     - I wish that the mirror, adjust date/time, and favorites where
>     accessible without needing to click Photo first
>    

We're not convinced that the Mirror and Adjust Date/Time commands are 
commonly enough used to deserve keyboard shortcuts out of the box.  If 
you use these commands often, you can assign your own keyboard shortcuts 
to them by enabling the can_change_accels GConf key; see e.g. 
http://ubuntuforums.org/showthread.php?t=1473788 to learn more about how.

>     - I wish Extended Information wasn't a modal dialog, but instead a
>     replacement/supplement for the Basic Information frame in the sidebar
>    

We've thought about this too.  I've ticketed this at 
http://trac.yorba.org/ticket/1918 .

>     - When on the photo checkerboard page, I want CTRL + Mouse Wheel to
>     adjust the zoom.
>    

An interesting idea.  I'm not aware of precedent for this in any other 
GNOME application, but it might be convenient.  Ticketed at 
http://trac.yorba.org/ticket/1919 .

>     - When looking at a photo - it'd be nice to have the option to zoom in
>     without needing to crop the image, make window bigger, etc. (I understand
>     optimization with libjpeg probably makes this difficult)
>    

This is already implemented in the trunk, and will be in the 0.6 release.

>     - When adjusting crop, It would be nice if the CTRL + crop option worked
>     similar to several other image editing apps (maintain current selections
>     aspect ratio).
>    

I'm not sure quite what you want here.  When cropping in Shotwell today, 
you can choose the Original Size constraint to constrain the crop 
rectangle to the photo's original aspect ratio.  Are you suggesting that 
if the user holds down the Control key while invoking the Crop tool, we 
should automatically select this constraint?  Or are you suggesting that 
whenever the user holds down the Control key while resizing the crop 
rectangle, the rectangle's aspect ratio should remain fixed?  If the 
latter, can you briefly explain a use case for this?

>     - When looking at a photo, it feels as though there is a missing up arrow
>     by the left/right arrows (to return to checkerboard page)
>    

It's true that in Nautilus Alt+up arrow will return to the containing 
page.  I'm not aware of any GNOME application which would act like that 
on a simple up arrow press, though.  Given that we already have a key 
for that (Escape) I'm not sure we need to add this one too.

> 5.)  It would be a nice feature to have captions for each picture that
> automatically upload to Picasa, Flickr, Facebook, etc, when the pictures are
> published.  I believe this could easily be stored as a text field in the
> Photos Table.
>    

In the trunk build of Shotwell you can already edit a caption for each 
picture.  We don't yet automatically upload these to photo-sharing 
sites, but we have a ticket for that (http://trac.yorba.org/ticket/1326) 
which we hope to implement before long.

> 6.)  Support for multiple users.  I have setup a single database shared (via
> links from the hidden folder to a shared folder with a user group to which
> all users have R/W access) between multiple logins (could be multiple PCs).
>   I like to share the images, otherwise when she imports the pictures, I have
> to re-link them into my database to see them. However, with this setup, I'm
> cautious not to have both users access the database simultaneously.  It
> would be ideal if Shotwell could handle this situation automatically with an
> option for shared database (/usr/share/shotwell/.shotwell/*) or individual
> database (~/.shotwell/*).
>    

We're also interested in extending Shotwell to sync/share photos between 
users, both on a local network (e.g. within a family) and globally.  
This probably won't happen real soon, but rest assured that this is part 
of our longer-term plans.

>
> For now, I have no other thoughts.  However, I will continue to play with
> the code, time permitting, and continue using Shotwell.  I'm glad to see
> that Shotwell is due to become the default photo handler in Ubuntu 10.10.  I
> appologize if I've rambled - just consider these the thoughts of a humble
> embedded software engineer...
>    

Thanks for all your feedback and ideas!  If you have more questions 
based on your exploration of the Shotwell code then don't hesitate to 
get in touch again.

adam