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.
2009/12/8 caleb.marcus+u-d-d <caleb.marcus+u-...@gmail.com<caleb.marcus%2bu-...@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 <seb...@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. >> >> 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 >> >> >> >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> > >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
