Solang or Shotwell vs. F-Spot for Lucid

[Sebastien Bacher]

Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit :
> Before too much effort is invested into making F-Spot good enough to
> meet all of the needs outlined at the UDS Default App Selection
> session, i thought i should bring up Solang and Shotwell to see if it
> might be worth including instead of F-Spot in Lucid, or if it's too
> late, in Lucid +1. 

Hi,

Thank you for raising the topic. What effort are you speaking about
exactly there though? The only change we needed was the edit options to
be available in view mode basically and upstream already fixed that one.

> GTumb has been discussed, but it doesn't seem to deliver the goods.

Why not? Somebody pointed recently a post about gthumb, the code has
been refactored recently apparently and the new version looks quite good

>  Solang is new, yet it's developed quickly and is showing a lot of
> promise. Shotwell might also be a contender worth discussing, but i am
> unfamiliar with it. Hopefully someone else has some insights as to how
> Shotwell compares to Solang and F-Spot. 

We have something not perfect right now but working ok for common use,
it seems risky to want to change to some new codebase in a lts cycle
especially when we don't know how reliable upstream is and when those
softwares have not been exposed to real user testing and feedback yet.

>       * A major issue with F-Spot that Solang doesn't have is that you
>         have to move images to import them into the library. 

Do you? The import dialog has a checkbox about copy that you can uncheck

>       * F-Spot is much more resource intensive than Solang

Do you have numbers on that?

> Solang, Shotwell, and F-Spot are all fine image managers/organizers,
> but the current plan is to work on F-Spot to get it to meet the
> following needs: 
>       * Quickly viewing images by folder [currently handled by EOG]
>               * Solang and F-Spot both have view-modes but still
>                 require importing the image. Shotwell might not. 

No, the f-spot --view mode doesn't require to import anything...

>       * Editing images without importing (Shotwell does this)
>               * Rotating [currently handled by EOG]
>               * Red-eye removal [currently handled by GIMP]
>               * Cropping [currently handled by GIMP]

those are done by f-spot as well

> Although the interface has been cleaned up, it just feels heavy. 

The comment there is about the user interface or the opening speed,
reactivity to actions, ...?

> It's worth reconsidering how much work should be put in to F-Spot when
> other projects seem to be progressing faster. If this much work is
> going to be invested as it is, we should consider whether it might be
> better to focus on Solang instead. Shotwell might already meet many of
> these needs, and need significantly less work. 

We don't put too many efforts in f-spot, the work is done mostly by
upstream and the packaging is done mostly by Debian, we just try to
issues reported on launchpad and work with upstream on the ones we
consider worth trying to fix for the next version.

Where did you get that the other projects are moving faster too? They
might have extra work to put to catch up with what f-spot does now. The
timeline view is rather nice to use and f-spot has quite some other
options. 

Did anybody looked at how those other software handle exporting to
flick, picasa or other web services?

> Please look into both Solang and Shotwell and post your thoughts. 
> Thanks! 

I will let other people comment on those, but changing a known codebase
for new project in a lts cycle doesn't seem a good move from there



Sebastien Bacher