Re: Trying f-spot for (almost) the first time

[Larry Ewing <lewing ximian com>]

On Fri, 2004-10-22 at 14:31 -0400, Benjamin Kahn wrote:
> I've just started trying f-spot out as my photo management application.
> I checked out the sources from CVS yesterday (October 21st, 2004) and
> compiled.  Here are some of my thoughts and comments.
> 
> When adopting a photo application, most users probably already have a
> good collection of images.  So the first step is to import them all into
> the new program.  In my case, I have them stored on a server.  So I
> needed to copy them into F-Spot.
> 

F-Spot really needs to start up with a big "Import Photos" dialog when
you start it for the first time to ease people into the import flow as
well.

> I saw no way inside of F-Spot to do this automatically, so I SCP'd to
> the files from the server to the local machine.  But, the connection was
> pretty slow (25k/s!) and the amount of data fairly large (okay, only a
> Gig of data...) so I got impatient while loading the images and imported
> the directory multiple times.  This lead to duplicate images.
> 
> So feature requests from this:  
> 
>       * Have a way to import images from online albums similar to
>         export.  A plugin system for different types of online
>         repositories would be great, but supporting directories of files
>         and Gallery would be a great start.

The current Gallery code should work for downloading all this needs is a
ui and some thought.  In general the problem is harder and and I need to
come up with a decent plug-in interface for importers and exporters.  I
wish there were decent c# gnome-vfs bindings so that I could use things
like the ssh vfs methods to write an importer.  Oh well, I'm sure some
will come along.

>       * During import, if the image is already in the catalog, don't
>         import it again.  (Plus, what happens if I import an image
>         twice, select one instance and pick Edit -> Delete from Drive?)

You have one thumbnail that will not load an image, I'm not sure if it
is smart enough to show the broken image icon right now if there is a
not a valid thumbnail.  Obviously there are better ways this could be
handled

>       * I should be able to select a directory as a source for images.
>         Images added to this directory should automatically import.

you can.  The directory selection logic in gtkfilechooser is just very,
very confusing.  Federico you want to comment on this? 

>       * Lots of context information was lost in the import.  I kept the
>         images organized in folders which would have made GREAT tag
>         names.  For example, 2003/Jan/14 should have created three tags:
>         2003, Jan, and 14.  All the images in that directory should have
>         been given those tags. 

I see what you are getting at but I'm not sure the example is the best.
If the exif data is intact we know the date and there are better ways to
represent it than tags.  I suppose the import dialog could look for
subdirectories in the import folder and offer to create tags for them if
they don't match the DCF file format spec.

>       * The thumbnails displayed come from the thumbnails embedded in
>         the exif data which is defined to be 160x120 always.  While this
>         makes importing really fast, it means that large icons always
>         display badly (until a real thumbnail is generated) and rotated
>         images are displayed wrong (again, until a real thumbnail is
>         generated).  Either there should be a background process for
>         creating real thumbnails, or the correct thumbnails should be
>         produced at import time.
> 

The plan is to update the thumbails after the import in an idle handler.
It has stayed pretty low on the list so far but patches are welcome.

> Bug list:
> 
>       * While importing the incomplete list of images, the new images
>         sometimes wouldn't show up in the list, or would appear blank.

Hmmm I don't remeber seeing this but it is possible some of the images
wouldn't appear in that dialog if they didn't have a thumbnail in the
exif data.  File it.

>       * When scrolling quickly through the list, thumbnails often don't
>         appear.  When this happens, this message arrives on the console:
>         BUG: Filing another request of order 26 (previously 25) for
>         `/home/xkahn/.thumbnails/large/cfef809df6a3aabc6b6b79fdd654a31c.png'

this is only because you have duplicate images in the database,  Once
the duplicate import bug is solved this will not be an image.

>       * Importing a directory was very confusing somehow.  The file
>         dialog made it very difficult since it kept OPENING the
>         directory I was trying to import.  For some reason it took me a
>         while to notice that the "Open" button was enabled even when
>         nothing was selected.  Also, once a directory was selected, it
>         was hard to unselect it.  (You have to hold down ctrl and click
>         that directory again.)

Bug Federico, this is stock gtk here.

> 
> Next I wanted to play around with the interface a little to get a feel
> with what I can do with F-Spot.  I looked at tags...
> 
> Feature Requests:
> 
>       * When you assign a tag that has no associated image yet (say...
>         the Other tag) the tag's icon becomes that first image.  This
>         was pretty surprising at first, and I can't remove the image
>         completely.  (Okay, okay...  Why would you want a tag that
>         doesn't have an icon?  How will you be able to tell when that
>         tag is applied?)  Maybe this is a bug report asking that all top
>         level tags come with icons already.  Or maybe a tag without an
>         icon should be represented by a text label?

The toplevel tags all need to have icons.  Maybe I'll just shove some
nautilus emblems in there and hope to customize them eventually.

>       * The checkboxes in the left hand sidebar are somewhat confusing
>         to me.  I selected a number of pictures and clicked the checkbox
>         for the Other tag.  Oops!  The checkbox is intended as a
>         filtering system, and all the images disappeared.  The checkbox
>         should be a tag assignment system.  (Yes, I know about the
>         right-click menu, dragging tags to images and dragging images to
>         tags, and the Tags -> Attach Tag to Selection and Tags -> Remove
>         Tag from Selection.  These methods seem less obvious and
>         confusing.)  Filtering should be a different mode from
>         assigning.

I think everyone agrees the current ui for the tag tree is highly
confusing.  The right way to fix it is still up for debate, but I
promise things will get better.

>       * Tags should be auto-created and assigned at import time as much
>         as possible.
> 

Agreed.

> Bugs:
> 
>       * Tags listed in the left sidebar should all be uniformly sized.
>         There shouldn't be tags that are very tall (because of their
>         icon) and those that are very short. (because of their lack of
>         icon).

Hrmmm I'll think about it.

>       * When an icon is assigned to a tag, the tag spacing isn't updated
>         to hold the image, and the image is chopped off.

File a GtkTreeView bug.  It should resize when the pixbuf in a row
changes.

>       * When assigning a non-top level tag to an image, the top level
>         tag icon is displayed as being associated.  The actual tag icon
>         should be shown.

actually I'm leaning towards only showing toplevel tag icons in the icon
list and showing full tags in the photo view.  It would limit the number
of possible tags and look nicer, and I'm not sure it would hurt things.

>       * The Tag menu doesn't have an accelerator.
>       * The menuitem "Remove Tag from Selection" doesn't have an
>         accelerator.
> 

File bugs for these.

> Next, I wanted to do some light editing on the images I had imported.
> First up is rotation.  I tend to always turn the camera the same way
> when taking pictures, so I selected 4 images right away that all needed
> to be rotated left.  On a hunch, I right clicked one of the images and
> saw the rotate menu item and selected it.  
> 
> Bugs:
> 
>       * Because of the thumbnail import bug listed above, rotating
>         images can be very frustrating.  (Images appear to be rotated
>         twice since the thumbnail is wrong at first.)
> 
> Now I wanted to examine a number of images to make sure it wasn't
> blurry, find which one was best, etc.  Double clicking on an image works
> to view it, as does selecting the right tab.  Once viewing the image,
> things degrade a little.
> 
> Feature Requests:
> 
>       * Standard GNOME zoom keys should work:  Ctrl-+ (Zoom In) and
>         Ctrl-- (Zoom Out) and Ctrl-= (Full Size) and Ctrl-0 (Fit to
>         Screen)

Already in the queue, a couple of fixes in the f-image-view.c and the
zooming code need to happen first for this to work.

>       * Clicking and Dragging across the image creates a crop box.  It
>         should pan the image instead.  (Cropping is important I guess,
>         but it's more likely that I'm examining an image, esp if the
>         image is larger than the screen.  Cropping, or any edits, should
>         be a mode.)

I'll probably use middle button for panning for now. It is possible I
should move all the editing out of the mail view dialog.  I haven't
decided one way or the other yet.

>   
>       * If I unzoom the image too far, I end up back at the list of
>         images.  Yeah, my camera does that too, but it feels a little
>         weird in an application.  It should just make the image smaller.
> 

File it and I'll think about it, trow mentioned he disliked that feature
as well.  I like using one binding for both but I'm not sold on it.

> Bugs:
> 
>       * The mouse wheel looks like it's trying to zoom the image.  (The
>         image becomes sharper for a moment and then smooths out again as
>         the wheel turns.)  But the zoom isn't working.  Actually, it's
>         weirder than that.  If I zoom the image in and try the
>         mousewheel, the image pans (very slowly) in relation to the area
>         of the image the mouse is hovering over.
> 

Yeah the current zoom stuff is seriously crappy,

> I know, I know.  Put these problems in bugzilla!  Okay, I will.  But
> wanted to jot down my notes from trying things out first.

bingo ;)

thanks for the great feedback Ben

--Larry