Solang or Shotwell vs. F-Spot for Lucid
caleb.marcus+u-d-d at gmail.com
Wed Dec 9 03:40:05 UTC 2009
Actually, it seems to start importing as soon as you select a folder... then
the dialog remains locked until it reads all the files in it.
<caleb.marcus+u-d-d at gmail.com<caleb.marcus%2Bu-d-d at gmail.com>
> The bizarrely obnoxious bit about F-Spot import is that it copies
> everything to your photos folder BEFORE you actually accept the import.
> Then, if you don't accept it, it deletes them... which is just Bad Behavior.
> On Tue, Dec 8, 2009 at 4:57 AM, Sebastien Bacher <seb128 at ubuntu.com>wrote:
>> 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.
>> 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
>> 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
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss