[Shotwell] Improvement suggestions

[Adam Dingle]

Mattias,

I'm glad you like Shotwell so far!  Thanks for your many suggestions.  
Here's some feedback:
> 1. Quite a number of keyboards and mouses have back and forward buttons,
> which are mostly useful for browsing web. These keys could be used in
> Shotwell too, for navigating in 10 or 20 item history.
>   
It's a good idea to support the mouse back/forward buttons in some way.  
We could either (a) make these buttons equivalent to the Previous Photo 
and Next Photo buttons in full-window mode, or (b) use them to navigate 
through the history of pages recently viewed.  With (b), the back button 
might take you to the previous viewed event, for example.  Are you 
suggesting (b) rather than (a)?
> 2. Optional integration with F-Spot, so you could tick "Common database
> with F-Spot" in preferences. F-Spot uses simply a sqlite db. On start-up
> the Shotwell should then check if F-Spot is running and give user a
> notice about read only mode.
>   
Yes, some sort of integration with F-Spot would be nice, though reading 
F-Spot's sqlite database format is probably further than we want to go 
here.  We'll think about this more for our 0.5 release early next year.
> 3. When I drag a picture to the window, it says "1 photo successfully
> imported" while showing the photo and goes to "Photos" directory. I
> would prefer to see the previously imported image selected either in
> directory or even shown in full window.
>   
It's not so clear how to implement this, because photo importing is 
asynchronous: you can continue to use Shotwell while photos are being 
imported.  Suppose that the user drags in 100 photos.  Should we 
suddently select them all in the main Photos view once the import is 
complete?  Or should we select each one in turn as it's imported?  I 
think either of those behaviors would be odd.  I suppose that in the 
case of importing a single photo we could select it in the Photos view 
after the import is complete, perhaps.
> 4. Instead of blue border, you could prefer light gray, to indicate
> which images are selected, it would look more professional and would not
> impact eye perception of colours. I really like the medium dark gray
> background.
>   
That's an interesting idea; we'll think about this more.  Soon, we'd 
like to make it possible for the user to select colors using a GNOME 
theme (see http://trac.yorba.org/ticket/318 ).
> 5. Press delete key to trash currently open image file, with optional
> confirmation.
>   
We've already implemented that feature in the trunk, so it will be in 
the 0.4 release later this month.
> 6. Changing rotate icon when trying to hit Ctrl+R is confusing. So 
> Ctrl+R should rotate the image CCW (while CCW icon is shown), Ctrl+Shift
> should change the icon back to normal and Ctrl+Shift+R rotate CW.
>   
Hm - I guess it does seem confusing that the Ctrl key changes the icon 
to rotate left even though Ctrl+R rotates right.  We'll think more about 
what to do about that.
> 7. Using page up and page down to navigate, with Ctrl to navigate
> through events. (This automatically makes the Presentation control
> remotes useful, which are are simply HID keyboards with PgUp and PgDn keys
> for Prev - Next slide, . (a dot) for blank screen, Esc to end session,
> F5 to start presentation, these are simply Powerpoint default shortcuts)
>   
I believe you're asking for the following:

Page Up/Down = go to previous/next photo in full-window mode (just like 
left arrow)
Ctrl+Page Up/Down = go to previous/next event (in full-window mode?  or 
even in the Photos view?)

Is this correct?
> 8. Backspace for full-window image should move to containing event
> directory (same as doubleclick).
>   
This seems like a reasonable idea.  I've filed a ticket for this 
(http://trac.yorba.org/ticket/1080 ).  This should be easy, so we might 
implement this for 0.4.
> 9. Slideshow and fullscreen view should be directly switchable from one
> mode to another.
>   
I suppose we could allow that, though I don't imagine users would need 
this too often.  Are you suggesting that we implement this with a 
toolbar button, or with a key command?
> 10. For cropping, current Gimp interface is worth a medallion for easy
> mouse usage, it is a little hard to snap from current 12px area (at
> least on 1640x1050 which is becoming more common).
>   
When you say "it is a little hard to snap from current 12 px area", do 
you mean that in Shotwell the user must crop by moving the mouse into a 
12-pixel area near the crop rectangle, and that that area is too small?  
I've never found the Shotwell interface to be hard to use, but I suppose 
we could make that area a bit larger like in Gimp.
> 11. This is probably a feature for 2.5, but IMHO Gnome desktop is still
> lacking a decent way to present images with nice transitions. It should
> be enabled only with OpenGL and default to nice 800ms fade with nice Ken
> Burns effect (http://en.wikipedia.org/wiki/Ken_Burns_Effect). Most of
> other effects are not worth implementing.
>   
Yes - we've always intended to implement slideshow transitions at some 
point.  We'd like to offer the user a choice of transition effects, and 
I agree we probably don't need to make this too fancy.  I've just filed 
a ticket for this feature (http://trac.yorba.org/ticket/1081 ).  It 
won't make 0.4, but will happen some time next year.

adam