From roman.yepishev at yandex.ua Mon Mar 1 16:07:13 2010 From: roman.yepishev at yandex.ua (Roman Yepishev) Date: Mon, 01 Mar 2010 18:07:13 +0200 Subject: [Shotwell] Shotwell performance in Lucid Lynx In-Reply-To: <1267280014.2959.12.camel@mind> References: <1267273470.4375.21.camel@buzz.west.homenet.org> <1267280014.2959.12.camel@mind> Message-ID: <1267459633.6358.11.camel@buzz.west.homenet.org> On Sat, 2010-02-27 at 15:13 +0100, caccolangrifata wrote: > libglib2.0-0 Indeed: libglib2.0-0: Installed: 2.23.4-1ubuntu1 Candidate: 2.23.4-1ubuntu1 Version table: *** 2.23.4-1ubuntu1 0 500 http://archive.ubuntu.com lucid/main Packages 100 /var/lib/dpkg/status So, is this affecting only shotwell or there is some kind of regression for all applications? So far I have issues only with gNote which has something bad happening in Gtk++. No other applications misbehave the same way as shotwell. -- Roman Yepishev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From adam at yorba.org Mon Mar 1 20:42:00 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 01 Mar 2010 12:42:00 -0800 Subject: [Shotwell] Shotwell performance in Lucid Lynx In-Reply-To: <1267459633.6358.11.camel@buzz.west.homenet.org> References: <1267273470.4375.21.camel@buzz.west.homenet.org> <1267280014.2959.12.camel@mind> <1267459633.6358.11.camel@buzz.west.homenet.org> Message-ID: <4B8C2698.2050005@yorba.org> An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Tue Mar 2 12:39:22 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Tue, 02 Mar 2010 13:39:22 +0100 Subject: [Shotwell] testing and recent library versions (was: Call for testing) In-Reply-To: References: Message-ID: <4B8D06FA.6090200@techfak.uni-bielefeld.de> Heya, would it be possible to loosen the library requirements, including Vala, to something that is available out-of-the-box (i.e. no PPAs) on Ubuntu 9.04? Maybe reduce them to a warning or something. cheers, Ingo Am 27.02.2010 03:09, schrieb Jim Nelson: > Hello, > > We've been working diligently on Shotwell 0.5 and we have high hopes for > this release. Several big new features have been added as well as a slew of > tweaks, additions, and bug fixes. Some of the more big ticket items > include: > > * Tags as another way of organizing your collection > * Picasa Web publishing > * Printing > * Adjust photos dates and times, both to a single moment and shifting > several forward and backward in time > > We could use your help. We're hoping to ship Shotwell 0.5 in the next few > weeks and would like to run it through its paces. We need people to > download the current revision in trunk (not the tarball) and really beat up > on it. If you're interested, follow the directions here for getting the > source and building it: > > http://trac.yorba.org/wiki/ShotwellInstallation > > If you find bugs or issues -- anything that seems odd -- please feel free to > report them here on the mailing list or via our Trac ticketing system at: > > http://trac.yorba.org/ > > We're also always looking for translators to assist us in making Shotwell a > world-class product. If you're interested, please visit our Transifex page > to get started: > > http://www.transifex.net/projects/p/shotwell/ > > Thanks for your continued support! > > -- Jim Nelson > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -- Ingo L?tkebohle -- http://www.techfak.uni-bielefeld.de/~iluetkeb/ From adam at yorba.org Tue Mar 2 16:15:02 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 02 Mar 2010 08:15:02 -0800 Subject: [Shotwell] testing and recent library versions In-Reply-To: <4B8D06FA.6090200@techfak.uni-bielefeld.de> References: <4B8D06FA.6090200@techfak.uni-bielefeld.de> Message-ID: <4B8D3986.6010403@yorba.org> An HTML attachment was scrubbed... URL: From jim at yorba.org Wed Mar 3 01:51:13 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 2 Mar 2010 17:51:13 -0800 Subject: [Shotwell] Small patch for trinket handling In-Reply-To: <654d70961002271358i6ce7204at7071d5d46935199@mail.gmail.com> References: <654d70961002271358i6ce7204at7071d5d46935199@mail.gmail.com> Message-ID: Thanks for this -- yes, there's no support for multiple trinkets at this point, but it's good to have this fixed. This is as good a place as any to submit a patch. If there was a ticket for this, then you could attach the patch there as well. Committed. Cheers, -- Jim On Sat, Feb 27, 2010 at 1:58 PM, Martin Robinson < martin.james.robinson at gmail.com> wrote: > I'm not sure if this is the appropriate place to submit patches, but > here goes. :) I was fiddling around with trinket positioning today for > fun and I ran into some code which requisitions size for multiple > trinkets, but doesn't position them properly. > > It's not entirely useful, as there doesn't appear to be a way to have > multiple trinkets yet, but I've attached a very simple patch for this > issue. > > Martin > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Thu Mar 4 08:58:37 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Thu, 04 Mar 2010 09:58:37 +0100 Subject: [Shotwell] testing and recent library versions In-Reply-To: <4B8D3986.6010403@yorba.org> References: <4B8D06FA.6090200@techfak.uni-bielefeld.de> <4B8D3986.6010403@yorba.org> Message-ID: <4B8F763D.5080200@techfak.uni-bielefeld.de> Am 02.03.2010 17:15, schrieb Adam Dingle: > I'm not sure whether you're asking about loosening the requirements required to > *build* Shotwell (including valac) on Ubuntu 9.04, or only requirements for > running it. In either case, however, the changes wouldn't be trivial, and they > won't happen for the upcoming Shotwell 0.5 release. I was thinking about the build. However, having seen what that would entail, I understand that you're not exactly anxious to do it. Thanks for the explanation! cheers, -- Ingo L?tkebohle -- http://www.techfak.uni-bielefeld.de/~iluetkeb/ From jim at yorba.org Sat Mar 6 02:05:42 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 5 Mar 2010 18:05:42 -0800 Subject: [Shotwell] Final call for testing Shotwell 0.5 Message-ID: Hello all, Just to get the word out, we're rapidly moving toward wrapping up Shotwell 0.5.0 for release in the coming week. As I've mentioned before, we have several new notable features we're excited about, including: * Picasa Web publishing * Tags as another way of organizing your collection * Printing * Adjust photos dates and times, both to a single moment and shifting several forward and backward in time We've fixed a number of the bugs you all reported in the last round of testing -- thanks so much! We'd still like you to bang on Shotwell and put it through its paces. We need people to pull the latest revision in trunk and try it out. If you're interested, follow the directions here forgetting the source and building it: http://trac.yorba.org/wiki/ShotwellInstallation If you find bugs or issues -- anything that seems odd or wrong -- please feel free to report them here on the mailing list or via our Trac ticketing system at: http://trac.yorba.org/ We're also always looking for translators to assist us in making Shotwell a world-class product. If you're interested, please visit our Transifex page to get started: http://www.transifex.net/projects/p/shotwell/ Thanks for your continued support! -- Jim Nelson -------------- next part -------------- An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Sat Mar 6 17:18:20 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-15?Q?Ingo_L=FCtkebohle?=) Date: Sat, 06 Mar 2010 18:18:20 +0100 Subject: [Shotwell] export-Feedback Message-ID: <4B928E5C.5000308@techfak.uni-bielefeld.de> Heya, I'm wondering a little about the worth of having export functionality developed from scratch for Shotwell. Of course, this is not 0.5 specific but applies to 0.4 too. However, I was kind of expecting to see plugin-capability in 0.5, which would have made this comment moot. As that did not happen, I'm sending it now. There are a number of excellent flickr-Tools available. For example, I'm using the small-and-to-the-point "postr", but there are several others for which the same argument holds. Such tools already integrate pretty well with Shotwell just using out-of-the-box capabilities -- i.e. drag'n'drop -- exporting using dnd and postr is at least as fast, if not faster, than the current Shotwell support for flickr. Whats more, postr allows me to specify names, tags and sets for my uploads, which Shotwell currently does not do. Last, but not least, postr doesn't block Shotwell while uploading. I would suspect that using the dnd data-exchange mechanism on the backend, integration with postr could have been built in a fraction of the time it took you to build your own flickr-uploader. Long mail, short question: Why are you building this functionality again? Cheers, Ingo From mnemo at minimum.se Sat Mar 6 23:12:51 2010 From: mnemo at minimum.se (Martin Olsson) Date: Sun, 07 Mar 2010 00:12:51 +0100 Subject: [Shotwell] Final call for testing Shotwell 0.5 In-Reply-To: References: Message-ID: <4B92E173.9050101@minimum.se> 0.5.0 is looking really good so far.. below are some new issues I found. I'm testing using current Lucid bits so I used to have the issues that Roman Yepishev posted about recently. Using Shotwell trunk as of now they seem to be fixed which is great. * What does the HIDE menu item do? I can see the images disappear alright but where do they go and what do I use this feature for? Even after messing around with it for several minutes, I don't really get it. (Update: a bit later while browsing around the menu I found the "View::Hidden" thing and I understand it now and it sort of makes sense. However, what about flashing and fading away the message "Use View::Hidden to show hidden images" somewhere in the UI when you first hide an image (conceptually sort of like how Firefox puts this yellow banner at the top of the page and says "FYI; I just blocked a pop up for you" etc. It could be just the first time you hide an image or maybe the first time in each session, so that it doesn't get too annoying. Another approach would be to show a small icon in the top left area of any "album" that has at least one hidden image; this icon should say "Click here to show hidden images as well" or similar. If you brainstorm a bit I'm sure you can come up with even better ways of cluing in the user as to where their images go when you "hide" them. Consider for example the special case where an event contains a single photo of a cat, thus that image will now be used for the event thumbnail despite being hidden and if you open that album you get an empty gray page which is a bit weird. * Import some photos, right click the first photo and select "Set as Desktop Background", press CTRL-ALT-D twice and verify that the image was set. Now click some other image and select "Set as Desktop Background" on that one and again look at the desktop. Now the old image will still be set as wallpaper. I suspect maybe this is because gconf doesn't emit a "changed" event if you set the exact same value again, i.e: picture_filename = /home/mnemo/.shotwell/wallpaper/wallpaper.jpg * After looking briefly at the set wallpaper code I'd suggest these changes: - in set_background() do "if (!set_string()) return false" - the function set_background() should return bool so that you can do AppWindow.error_messag("txt") in set_desktop_background() like you already do in the catch there. * In the English translation, when you open the context menu on a photo both the "Modify Tags" and "Remove" items have keyboard accelerator "_m". Similar with "Favorites" and "Fullscreen" in the View menu. * File::Publish is the only menu item in the main menu which does not have a "_X"-style keyboard accelerator. * If I have firefox running and I select "Help::Contents" in shotwell the page loads but the FF window is not raised (which typically means the user will not notice, I thought it did nothing at first). gtk_show_uri() doesn't throw though so maybe this is an GTK/Ubuntu bug (I've seen similar issues on Ubuntu before and discussions about that the "allowed window raising policy" is these days). Maybe you'd want to look into what's going on there or maybe deploy some sort of explicit "raise window" workaround though because Shotwell users will suffer from this for sure. * Import a photo, right click it and select "Modify tags" (note: image should have no prior tags) and then type "blah" and press OK. Reproducible SEGV: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7ba3ce9 in gee_collection_contains (self=0x0, item=0x94c8a0) at collection.c:158 158 return GEE_COLLECTION_GET_INTERFACE (self)->contains (self, item); (gdb) bt #0 0x00007ffff7ba3ce9 in gee_collection_contains (self=0x0, item=0x94c8a0) at collection.c:158 #1 0x00000000004f26c7 in modify_tags_command_construct (object_type=, photo=, new_tag_list=0xd76580) at src/Commands.c:4827 #2 0x0000000000422f4f in collection_page_on_modify_tags (action=, self=) at src/CollectionPage.c:3328 #3 _collection_page_on_modify_tags_gtk_action_callback (action=, self=) at src/CollectionPage.c:2020 * From a "UI clutter" perspective I don't see why you need both "Add tags" and "Modify tags"? * Reproducible SIGABRT. Import three JPGs and right click the first one and select "Hide". The use CTRL-A to select all remaining photos and right click selecting DUPLICATE. ERROR:src/CheckerboardLayout.c:2619:checkerboard_layout_repaint_item: assertion failed: (data_collection_contains (DATA_COLLECTION (self->priv->view), DATA_OBJECT (item))) Program received signal SIGABRT, Aborted. 0x00007ffff1b5ea85 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c #0 0x00007ffff1b5ea85 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff1b62520 in *__GI_abort () at abort.c:92 #2 0x00007ffff1f10124 in IA__g_assertion_message (domain=, file=, line=, func=0x51d200 "checkerboard_layout_repaint_item", message=0xee90d0 "assertion failed: (data_collection_contains (DATA_COLLECTION (self->priv->view), DATA_OBJECT (item)))") at /build/buildd/glib2.0-2.23.4/glib/gtestutils.c:1318 #3 0x00007ffff1f106a0 in IA__g_assertion_message_expr (domain=0x0, file=0x51caec "src/CheckerboardLayout.c", line=2619, func=0x51d200 "checkerboard_layout_repaint_item", expr=) at /build/buildd/glib2.0-2.23.4/glib/gtestutils.c:1329 #4 0x0000000000439834 in checkerboard_layout_repaint_item (self=0xade120, item=0xed9250) at src/CheckerboardLayout.c:2619 #5 0x00007ffff259a4ee in IA__g_closure_invoke (closure=0xae98e0, return_value=0x0, n_param_values=2, param_values=0xee96a0, invocation_hint=0x7fffffffc390) at /build/buildd/glib2.0-2.23.4/gobject/gclosure.c:767 #6 0x00007ffff25b12d9 in signal_emit_unlocked_R (node=0x96bdc0, detail=, instance=, emission_return=, instance_and_params=) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:3243 #7 0x00007ffff25b2b36 in IA__g_signal_emit_valist (instance=0xad29c0, signal_id=, detail=0, var_args=0x7fffffffc5b0) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:2976 #8 0x00007ffff25b2e5d in IA__g_signal_emit_by_name (instance=0xad29c0, detailed_signal=) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:3070 #9 0x00000000004ac5af in view_collection_notify_item_view_altered (self=0xad29c0, view=0xed9250) at src/DataCollection.c:3409 #10 view_collection_internal_notify_view_altered (self=0xad29c0, view=0xed9250) at src/DataCollection.c:4791 #11 0x00000000004a7ac4 in data_view_real_notify_view_altered (self=0xed9250) at src/DataObject.c:2137 #12 0x0000000000438409 in checkerboard_item_real_notify_membership_changed (base=, collection=0xad29c0) at src/CheckerboardLayout.c:1020 #13 0x00000000004b4c98 in data_collection_internal_add_many (self=0xad29c0, objects=, monitor=0, monitor_target=) at src/DataCollection.c:1997 #14 data_collection_add_many (self=0xad29c0, objects=, monitor=0, monitor_target=) at src/DataCollection.c:2074 #15 0x00000000004b523d in view_collection_add_sources (self=0xad29c0, added=, monitor=0, monitor_target=0x0) at src/DataCollection.c:3723 #16 0x00007ffff259a4ee in IA__g_closure_invoke (closure=0xcaabf0, return_value=0x0, n_param_values=2, param_values=0x7fffdc000d30, invocation_hint=0x7fffffffc970) at /build/buildd/glib2.0-2.23.4/gobject/gclosure.c:767 #17 0x00007ffff25b12d9 in signal_emit_unlocked_R (node=0x92f8f0, detail=, instance=, emission_return=, instance_and_params=) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:3243 #18 0x00007ffff25b2b36 in IA__g_signal_emit_valist (instance=0x7d60c0, signal_id=, detail=0, var_args=0x7fffffffcb90) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:2976 #19 0x00007ffff25b2e5d in IA__g_signal_emit_by_name (instance=0x7d60c0, detailed_signal=) at /build/buildd/glib2.0-2.23.4/gobject/gsignal.c:3070 #20 0x00000000004ab680 in database_source_collection_real_notify_items_added (base=, added=0xd74100) at src/DataCollection.c:3138 #21 0x00000000004b57c9 in data_collection_notify_items_added (self=0x7d60c0, object=) at src/DataCollection.c:1687 #22 data_collection_add (self=0x7d60c0, object=) at src/DataCollection.c:2032 #23 0x0000000000471a4c in library_photo_duplicate (self=, error=) at src/Photo.c:4728 #24 0x00000000004edccc in duplicate_multiple_photos_command_real_execute_on_source (base=0xe1a470, source=) at src/Commands.c:3717 #25 0x00000000004ef75d in multiple_data_source_command_execute_on_source (self=0xe1a470, exec=, can_cancel=, todo=, completed=0xd744c0) at src/Commands.c:2320 #26 multiple_data_source_command_execute_all (self=0xe1a470, exec=, can_cancel=, todo=, completed=0xd744c0) at src/Commands.c:2399 #27 0x00000000004ede94 in duplicate_multiple_photos_command_real_execute (base=) at src/Commands.c:3697 #28 0x00000000004e8b10 in command_execute (self=0x829a40, command=0xe1a470) at src/CommandManager.c:220 #29 command_manager_execute (self=0x829a40, command=0xe1a470) at src/CommandManager.c:390 #30 0x000000000042127c in collection_page_on_duplicate_photo (action=, self=) at src/CollectionPage.c:3390 #31 _collection_page_on_duplicate_photo_gtk_action_callback (action=, self=) at src/CollectionPage.c:1913 * Switching between photos are a bit slow. I have a quad core 2.8ghz with 8GB RAM, speed raided 10K RPM discs and 12MB CPU cache; still it routinely takes >500ms to switch to the next image. Not sure what's going on there. Also when I import photos I can see them flash by extremely fast, like 10 images per second fast; so why does it have to be so slow to switch between images in the photo album (i.e. open a photo in full view and then pressing LEFT and RIGHT arrows). For example try holding down the RIGHT key (and try it in Picasa too). I think it would be useful to hit this with gprof/oprofile because something is fishy there and long term of course you could pre-render/load the JPGs (and maybe even add progressive loading even though I hate that) like Picasa does (which I assume you don't right now?). I want Shotwell to feel extremely light-weight so that when I try to find that special image that I want to show someone, then bottle-neck should be how fast _I_ can browse/inspect the images not how fast the machine is. Also note that if I launch a terminal with "htop" and mark it as "always on top" and the hold down the RIGHT key so make Shotwell constantly switch to the next image, it does not tax my CPU nor my HDD at 100% (not even a single core is saturated) so maybe there is something cheezy goign on with keyboard repeat rate or similar? * Double click any photo (from an event with multiple photos) to bring it up in full view. Then super quickly hit the RIGHT keyboard key twice. Shotwell only moves to the next image, not two images forward. This is really annoying if you want to quickly skip past that particular one image when you had too much to drink or whatever. * Download and unpack these two images to a separate dir: http://temp.minimum.se/shotwell_crashers/12.tgz Launch with "rm -rf rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" and import from that dir, press OK when import finishes and immediately after you press OK you will get a reproducible SEGV with this stack: Program received signal SIGSEGV, Segmentation fault. 0x00000000004b9961 in batch_import_on_import_file_completed (self=0xb012a0, j=0xa10b40) at src/BatchImport.c:1642 1642 gee_collection_add (GEE_COLLECTION (self->priv->manifest->imported), photo); (gdb) bt #0 0x00000000004b9961 in batch_import_on_import_file_completed (self=0xb012a0, j=0xa10b40) at src/BatchImport.c:1642 #1 0x00000000004b8ff6 in _batch_import_on_import_file_completed_completion_callback (job=0xa10b40, self=0xb012a0) at src/BatchImport.c:1548 #2 0x0000000000544666 in background_job_on_notify_completion (self=0xa10b40) at src/Workers.c:566 #3 0x000000000054440a in _background_job_on_notify_completion_gsource_func (self=0xa10b40) at src/Workers.c:535 #4 0x00007ffff1ee9df2 in g_main_dispatch (context=0x84db20) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:1960 * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" and import the photos from this tarball: http://temp.minimum.se/shotwell_crashers/catbug.tgz Click "Photos", select bug.jpg and then Events::NewEvent. At this point the bug gets sort under the 1970 event node which is unintuitive (unless you know that unix date zero is at 1970) but this is not something that makes sense for an end-user. How about having a special event tree node for "Unknown Year" or something like that? * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" and import the photos from this tarball: http://temp.minimum.se/shotwell_crashers/catbug.tgz Click "Photos", select cat.jpg and then Events::NewEvent. At this point the event tree first expands but is then automatically collapsed again and it leaves me in this weird state where no new event node has been added at all to the event node tree? In the terminal I can see this (below) but it's unclear to me _why_ Shotwell destroys the event "Event" ? [DBG] LibraryWindow.vala:221: Creating new event page for Event 2 [DBG] Event.vala:192: Destroying event Event [1/6] Event 1 * Are you aware that you're generating _extremely_ deep stacks during modest to large imports (which will most likely give you a stackoverflow for imports of a certain size and up)? I've seen cases where Shotwell used stacks 40000 frames deep. In these cases the frames follow the following repeating pattern, i.e: #9 0x0000000000476896 in spin_event_loop () at src/util.c:1138 #10 0x0000000000431ba2 in thumbnail_cache_import_thumbnails (photo_id=0x7fffffda4bd0, thumbnails=0x1b6188c0, force=1, error=0x7fffffda4be8) at src/ThumbnailCache.c:779 #11 0x0000000000472620 in library_photo_import (photo_row=0x16cfb68, thumbnails=0x1b6188c0, photo=0x7fffffda4c28) at src/Photo.c:4513 #12 0x000000000047b4ee in batch_import_on_import_file_completed (job=, self=) at src/BatchImport.c:1639 #13 _batch_import_on_import_file_completed_completion_callback (job=, self=) at src/BatchImport.c:1548 #14 0x00000000004d3411 in background_job_on_notify_completion (self=) at src/Workers.c:566 #15 _background_job_on_notify_completion_gsource_func (self=) at src/Workers.c:535 #16 0x00007ffff1ee9df2 in g_main_dispatch (context=0x7a5b20) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:1960 #17 IA__g_main_context_dispatch (context=0x7a5b20) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2513 #18 0x00007ffff1eedc38 in g_main_context_iterate (context=0x7a5b20, block=, dispatch=, self=) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2591 #19 0x00007ffff1eede1c in IA__g_main_context_iteration (context=0x7a5b20, may_block=1) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2654 #20 0x00007ffff52047d1 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x0000000000476896 in spin_event_loop () at src/util.c:1138 #22 0x0000000000431ba2 in thumbnail_cache_import_thumbnails (photo_id=0x7fffffda4e40, thumbnails=0x7fffd4664860, force=1, error=0x7fffffda4e58) at src/ThumbnailCache.c:779 #23 0x0000000000472620 in library_photo_import (photo_row=0x16cfa48, thumbnails=0x7fffd4664860, photo=0x7fffffda4e98) at src/Photo.c:4513 #24 0x000000000047b4ee in batch_import_on_import_file_completed (job=, self=) at src/BatchImport.c:1639 #25 _batch_import_on_import_file_completed_completion_callback (job=, self=) at src/BatchImport.c:1548 #26 0x00000000004d3411 in background_job_on_notify_completion (self=) at src/Workers.c:566 #27 _background_job_on_notify_completion_gsource_func (self=) at src/Workers.c:535 #28 0x00007ffff1ee9df2 in g_main_dispatch (context=0x7a5b20) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:1960 #29 IA__g_main_context_dispatch (context=0x7a5b20) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2513 #30 0x00007ffff1eedc38 in g_main_context_iterate (context=0x7a5b20, block=, dispatch=, self=) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2591 #31 0x00007ffff1eede1c in IA__g_main_context_iteration (context=0x7a5b20, may_block=1) at /build/buildd/glib2.0-2.23.4/glib/gmain.c:2654 #32 0x00007ffff52047d1 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 #33 0x0000000000476896 in spin_event_loop () at src/util.c:1138 * When I start with a deleted ~/.shotwell and using SHOTWELL_LOG=1, then it says: [DBG] DatabaseTables.vala:277: Database version -1 create by app version (null) ...is that supposed to be "created" maybe? And maybe a special message should be printed when a new database is created instead of saying "app version (null)" ? * If you try to publish to Picasa Web Albums and select publish to a new album and you enter a single space character as the name, then it says "Service returned HTTP status code 400". I think there should be a "START OVER" or "BACK" button on this dialog page. Also I think you should prevent the user from pressing Publish if trim(album_name)="". Also using the name "
INJECTION" didn't work, maybe some people will actually try stuff like "My Birthday!" or whatever since they don't know "<" and ">" is special chars so maybe Shotwell should warm about that too? Martin Jim Nelson wrote: > Hello all, > > Just to get the word out, we're rapidly moving toward wrapping up Shotwell > 0.5.0 for release in the coming week. As I've mentioned before, we have > several new notable features we're excited about, including: > > * Picasa Web publishing > * Tags as another way of organizing your collection > * Printing > * Adjust photos dates and times, both to a single moment and shifting > several forward and backward in time > > We've fixed a number of the bugs you all reported in the last round of > testing -- thanks so much! We'd still like you to bang on Shotwell and put > it through its paces. We need people to pull the latest revision in trunk > and try it out. If you're interested, follow the directions here > forgetting the source and building it: > > http://trac.yorba.org/wiki/ShotwellInstallation > > If you find bugs or issues -- anything that seems odd or wrong -- please > feel free to report them here on the mailing list or via our Trac ticketing > system at: > > http://trac.yorba.org/ > > We're also always looking for translators to assist us in making Shotwell a > world-class product. If you're interested, please visit our Transifex page > to get started: > > http://www.transifex.net/projects/p/shotwell/ > > Thanks for your continued support! > > -- Jim Nelson > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From mnemo at minimum.se Sun Mar 7 21:32:29 2010 From: mnemo at minimum.se (Martin Olsson) Date: Sun, 07 Mar 2010 22:32:29 +0100 Subject: [Shotwell] Final call for testing Shotwell 0.5 In-Reply-To: <4B92E173.9050101@minimum.se> References: <4B92E173.9050101@minimum.se> Message-ID: <4B941B6D.9080007@minimum.se> Martin Olsson wrote: > * If you try to publish to Picasa Web Albums and select publish to a new album > and you enter a single space character as the name, then it says "Service returned > HTTP status code 400". I think there should be a "START OVER" or "BACK" button on > this dialog page. Also I think you should prevent the user from pressing Publish > if trim(album_name)="". Also using the name "
INJECTION" didn't work, maybe > some people will actually try stuff like "My Birthday!" or whatever since > they don't know "<" and ">" is special chars so maybe Shotwell should warm about > that too? I noticed that it works very well to create an album called "Lakers > Knicks" so what you want here is probably for Shotwell to do HTML/XML entity encoding on the written title before handing it off to the Picasa Web Albums server. Martin From adam at yorba.org Mon Mar 8 17:56:15 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 08 Mar 2010 09:56:15 -0800 Subject: [Shotwell] Final call for testing Shotwell 0.5 In-Reply-To: <4B92E173.9050101@minimum.se> References: <4B92E173.9050101@minimum.se> Message-ID: <4B953A3F.4070600@yorba.org> Martin, first of all, our heartfelt thanks for your thorough and impressive testing efforts! You've revealed a number of significant issues previously unknown to us. Your feedback for both Shotwell 0.4 and 0.5 has been an important contribution. We deeply appreciate it! I've filed tickets in our bug database for all of the significant issues below, and I've cc-ed you on the tickets so you can follow their progress. (I know this may result in lots of email; if you'd rather not be cc-ed on tickets we file for bugs you've reported then just let me know.) > 0.5.0 is looking really good so far.. below are some new issues I found. > I'm testing using current Lucid bits so I used to have the issues that > Roman Yepishev posted about recently. Using Shotwell trunk as of now they > seem to be fixed which is great. > That's good to hear. > * What does the HIDE menu item do? I can see the images disappear alright but > where do they go and what do I use this feature for? Even after messing around > with it for several minutes, I don't really get it. (Update: a bit later while > browsing around the menu I found the "View::Hidden" thing and I understand it > now and it sort of makes sense. However, what about flashing and fading away > the message "Use View::Hidden to show hidden images" somewhere in the UI when > you first hide an image (conceptually sort of like how Firefox puts this yellow > banner at the top of the page and says "FYI; I just blocked a pop up for you" etc. > It could be just the first time you hide an image or maybe the first time in each > session, so that it doesn't get too annoying. Another approach would be to show a > small icon in the top left area of any "album" that has at least one hidden image; > this icon should say "Click here to show hidden images as well" or similar. If you > brainstorm a bit I'm sure you can come up with even better ways of cluing in the > user as to where their images go when you "hide" them. Consider for example the > special case where an event contains a single photo of a cat, thus that image > will now be used for the event thumbnail despite being hidden and if you open > that album you get an empty gray page which is a bit weird. > Yes - we could possibly make it clearer where the hidden images have gone. It's too late to address this in 0.5, but maybe in another release. > * Import some photos, right click the first photo and select "Set as Desktop Background", > press CTRL-ALT-D twice and verify that the image was set. Now click some other image and > select "Set as Desktop Background" on that one and again look at the desktop. Now the old > image will still be set as wallpaper. I suspect maybe this is because gconf doesn't emit a > "changed" event if you set the exact same value again, i.e: > picture_filename = /home/mnemo/.shotwell/wallpaper/wallpaper.jpg > Good catch. I see this only on Lucid. > * After looking briefly at the set wallpaper code I'd suggest these changes: > - in set_background() do "if (!set_string()) return false" > - the function set_background() should return bool so that you can do > AppWindow.error_messag("txt") in set_desktop_background() like you > already do in the catch there. > Thanks for the code suggestion - we'll look at this soon. > * In the English translation, when you open the context menu on a photo both > the "Modify Tags" and "Remove" items have keyboard accelerator "_m". Similar with > "Favorites" and "Fullscreen" in the View menu. > Right. > * File::Publish is the only menu item in the main menu which does not have a "_X"-style > keyboard accelerator. > Yup. > * If I have firefox running and I select "Help::Contents" in shotwell the page loads > but the FF window is not raised (which typically means the user will not notice, > I thought it did nothing at first). gtk_show_uri() doesn't throw though so maybe > this is an GTK/Ubuntu bug (I've seen similar issues on Ubuntu before and discussions > about that the "allowed window raising policy" is these days). Maybe you'd want to > look into what's going on there or maybe deploy some sort of explicit "raise window" > workaround though because Shotwell users will suffer from this for sure. > This occurs only on Lucid, and indeed seems to be a GTK/Ubuntu bug: I see the same behavior when I click a URL in gedit's About box, for example. As such, we're reluctant to implement a Shotwell-specific workaround. I hope that Ubuntu will address this before the Lucid release. > * Import a photo, right click it and select "Modify tags" (note: image should have no prior tags) > and then type "blah" and press OK. Reproducible SEGV: > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7ba3ce9 in gee_collection_contains (self=0x0, item=0x94c8a0) at collection.c:158 > 158 return GEE_COLLECTION_GET_INTERFACE (self)->contains (self, item); > ... > Great catch. I think this worked until recently and is a recent regression. > * From a "UI clutter" perspective I don't see why you need both "Add tags" and "Modify tags"? > Add Tags can work on multiple photos, but Modify Tags works on only one. It might be tricky to make Modify Tags work on multiple photos, since the photos can have different tags. > * Reproducible SIGABRT. Import three JPGs and right click the first one and select "Hide". The use CTRL-A to select all remaining photos and right click selecting DUPLICATE. > ERROR:src/CheckerboardLayout.c:2619:checkerboard_layout_repaint_item: assertion failed: (data_collection_contains (DATA_COLLECTION (self->priv->view), DATA_OBJECT (item))) > ... Great catch. > > * Switching between photos are a bit slow. I have a quad core 2.8ghz with 8GB RAM, > speed raided 10K RPM discs and 12MB CPU cache; still it routinely takes >500ms to > switch to the next image. Not sure what's going on there. Also when I import photos > I can see them flash by extremely fast, like 10 images per second fast; so why does > it have to be so slow to switch between images in the photo album (i.e. open a photo > in full view and then pressing LEFT and RIGHT arrows). For example try holding down > the RIGHT key (and try it in Picasa too). I think it would be useful to hit this with > gprof/oprofile because something is fishy there and long term of course you could > pre-render/load the JPGs (and maybe even add progressive loading even though I hate that) > like Picasa does (which I assume you don't right now?). I want Shotwell to feel extremely > light-weight so that when I try to find that special image that I want to show someone, > then bottle-neck should be how fast _I_ can browse/inspect the images not how fast the > machine is. Also note that if I launch a terminal with "htop" and mark it as "always on > top" and the hold down the RIGHT key so make Shotwell constantly switch to the next > image, it does not tax my CPU nor my HDD at 100% (not even a single core is saturated) > so maybe there is something cheezy goign on with keyboard repeat rate or similar? > Improving photo transition performance is an ongoing effort, and actually we've already profiled the code and we already do some prefetching as well. But yes, this could be improved more and I agree we'd like to work toward instant photo transitions. I've filed a ticket and hopefully we can improve this more in 0.6. > * Double click any photo (from an event with multiple photos) to bring it up in > full view. Then super quickly hit the RIGHT keyboard key twice. Shotwell only > moves to the next image, not two images forward. This is really annoying if you > want to quickly skip past that particular one image when you had too much to drink > or whatever. > Right. We already have a ticket for this: http://trac.yorba.org/ticket/1465 . Maybe in 0.6. > * Download and unpack these two images to a separate dir: > http://temp.minimum.se/shotwell_crashers/12.tgz > Launch with "rm -rf rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" > and import from that dir, press OK when import finishes and immediately after > you press OK you will get a reproducible SEGV with this stack: > ... Great catch. Oddly, this seems to occur only when running under GDB. We'll investigate. > > * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" and import > the photos from this tarball: http://temp.minimum.se/shotwell_crashers/catbug.tgz > Click "Photos", select bug.jpg and then Events::NewEvent. At this point the bug gets > sort under the 1970 event node which is unintuitive (unless you know that unix date zero > is at 1970) but this is not something that makes sense for an end-user. How about having > a special event tree node for "Unknown Year" or something like that? > Right. We've seen (and fixed) this bug before when adding date-less photos to existing events, but as you point out it also occurs when creating a new event, and so I've reopened the associated ticket: http://trac.yorba.org/ticket/1152 . It's unlikely we'll fix this for 0.5; hopefully in the next release. > * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr ./shotwell" and import > the photos from this tarball: http://temp.minimum.se/shotwell_crashers/catbug.tgz > Click "Photos", select cat.jpg and then Events::NewEvent. At this point the event tree > first expands but is then automatically collapsed again and it leaves me in this weird > state where no new event node has been added at all to the event node tree? In the terminal > I can see this (below) but it's unclear to me _why_ Shotwell destroys the event "Event" ? > [DBG] LibraryWindow.vala:221: Creating new event page for Event 2 > [DBG] Event.vala:192: Destroying event Event [1/6] Event 1 > This is expected behavior. The event previously containing cat.jpg is destroyed (that was Event 1) since it no longer contains any photos: cat.jpg has been removed from it. A new event is created for cat.jpg (which happens to look just like the old one). If you find this unduly confusing, what alternative behavior would you suggest? > * Are you aware that you're generating _extremely_ deep stacks during modest to large > imports (which will most likely give you a stackoverflow for imports of a certain size > and up)? I've seen cases where Shotwell used stacks 40000 frames deep. In these cases > the frames follow the following repeating pattern, i.e: > > ... No, we were not aware. Stacks this deep are not good. We'll investigate and see if there's a way to avoid this. > > * When I start with a deleted ~/.shotwell and using SHOTWELL_LOG=1, then it says: > [DBG] DatabaseTables.vala:277: Database version -1 create by app version (null) > ...is that supposed to be "created" maybe? And maybe a special message should be > printed when a new database is created instead of saying "app version (null)" ? > OK - we'll clean up this message if we can. > * If you try to publish to Picasa Web Albums and select publish to a new album > and you enter a single space character as the name, then it says "Service returned > HTTP status code 400". I think there should be a "START OVER" or "BACK" button on > this dialog page. Also I think you should prevent the user from pressing Publish > if trim(album_name)="". Also using the name "
INJECTION" didn't work, maybe > some people will actually try stuff like "My Birthday!" or whatever since > they don't know "<" and ">" is special chars so maybe Shotwell should warm about > that too? > Reasonable suggestions. We also saw your subsequent email about HTML encoding the album name; that also sounds like a good idea. Once again, many thanks for the outstanding feedback! adam From caccolangrifata at gmail.com Mon Mar 8 21:06:24 2010 From: caccolangrifata at gmail.com (caccolangrifata) Date: Mon, 08 Mar 2010 22:06:24 +0100 Subject: [Shotwell] Shotwell String Freeze is Here! In-Reply-To: <992b763d1003041938v84c779cxae3e2a16b72ea96f@mail.gmail.com> References: <992b763d1003041938v84c779cxae3e2a16b72ea96f@mail.gmail.com> Message-ID: <1268082384.2692.2.camel@mind> Hi! here is the Italian translation. :D and, you're doing a great job! Cheers! Il giorno gio, 04/03/2010 alle 19.38 -0800, Lucas Beeler ha scritto: > Hi Shotwell Translators, > > You're receiving this message because you provided translation > services for Shotwell during the past release cycle. > > Just over a week ago, I wrote you to announce that Shotwell 0.5 is > due to be released soon. As I remarked then, we at Yorba are very > excited about this release, since it introduces a boatload of cool new > features, including printing, tags, publishing photos to PicasaWeb, > shifting photo exposure time, and more. > > In my earlier email, I invited you to begin updating your > translations, but I noted that we hadn't yet frozen the addition of > new strings to Shotwell. Excitingly, all of this changed this > afternoon: the Shotwell 0.5 string freeze happened today! So the final > set of strings for the upcoming 0.5 release is now available in the > POT file, ready and waiting for you to translate! > > If you want to see your translation included in the Shotwell 0.5 > release package, we will need to receive it by next Tuesday, March > 9th. To make translating Shotwell as simple and straightforward for > you as possible, I have attached the final Shotwell 0.5 POT file to > this message. Once you've updated your translation, you can submit it > either by attaching it in reply to this email or by pointing your > browser to our Transifex project page at > http://www.transifex.net/projects/p/shotwell/. > > We thank you for your efforts, and wish you the best. > > Kinds regards, > Lucas -- caccolangrifata -------------- next part -------------- A non-text attachment was scrubbed... Name: shotwell.0.5.it.po Type: text/x-gettext-translation Size: 63059 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From adam at yorba.org Mon Mar 8 23:33:52 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 08 Mar 2010 15:33:52 -0800 Subject: [Shotwell] export-Feedback In-Reply-To: <4B928E5C.5000308@techfak.uni-bielefeld.de> References: <4B928E5C.5000308@techfak.uni-bielefeld.de> Message-ID: <4B958960.5090805@yorba.org> Ingo, it's true that Postr is a useful tool for uploading photos to Flickr, and at the moment it's pretty easy to export from Shotwell to Flickr using Postr: all you have to do is export photos from Shotwell to a folder (e.g. on your desktop), then drag the folder into Postr. As you point out, it might be nice if the user could drag from Shotwell to Postr directly. Unfortunately that might not so easy to implement given the intricacies of how drag and drop works in GNOME. Technical details: Postr accepts files dragged from Nautilus, i.e. a set of URLs. But because Shotwell is a non-destructive photo editor, when you begin dragging the images to be exported are not yet available as files. When you drag from Shotwell 0.5 to a Nautilus folder, Shotwell builds the exported images on the fly and copies them into the destination folder. But unfortunately this won't work for dragging into Postr or other applications which expect a set of URLs. We've built exporting to Flickr and other services directly into Shotwell for a couple of reasons. First, as described above it might not be so easy to implement drag and drop into other exporting applications. Second, we like having export inside Shotwell because over time we may evolve Shotwell to be more deeply integrated with photo-hosting services. At some point we may automatically sync photos bidirectionally between Shotwell and hosting sites, so that photos you upload to a site through a Web browser will be downloaded into Shotwell automatically. We might also implement background syncing so that you can work locally with your photos at full resolution quickly, but photos will be automatically synced up to photo services in the background. Shotwell's existing integrated export capability is a possible first step toward this sort of deeper integration. It's true that the export services are still hard-coded in Shotwell 0.5: we don't yet have plugins. But we are still planning to implement a plugin API in Shotwell at some point; then we'll probably move the currently built-in export code into a set of plugins. See http://trac.yorba.org/ticket/182 . Eventually photo service plugins may even support bidirectional syncing as described above. cheers adam Ingo L?tkebohle wrote: > Heya, > > I'm wondering a little about the worth of having export functionality > developed from scratch for Shotwell. > > Of course, this is not 0.5 specific but applies to 0.4 too. However, I > was kind of expecting to see plugin-capability in 0.5, which would have > made this comment moot. As that did not happen, I'm sending it now. > > There are a number of excellent flickr-Tools available. For example, I'm > using the small-and-to-the-point "postr", but there are several others > for which the same argument holds. > > Such tools already integrate pretty well with Shotwell just using > out-of-the-box capabilities -- i.e. drag'n'drop -- exporting using dnd > and postr is at least as fast, if not faster, than the current Shotwell > support for flickr. > > Whats more, postr allows me to specify names, tags and sets for my > uploads, which Shotwell currently does not do. Last, but not least, > postr doesn't block Shotwell while uploading. > > I would suspect that using the dnd data-exchange mechanism on the > backend, integration with postr could have been built in a fraction of > the time it took you to build your own flickr-uploader. > > Long mail, short question: Why are you building this functionality again? > > Cheers, Ingo > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From iluetkeb at techfak.uni-bielefeld.de Tue Mar 9 08:59:55 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Tue, 09 Mar 2010 09:59:55 +0100 Subject: [Shotwell] export-Feedback In-Reply-To: <4B958960.5090805@yorba.org> References: <4B928E5C.5000308@techfak.uni-bielefeld.de> <4B958960.5090805@yorba.org> Message-ID: <4B960E0B.2030004@techfak.uni-bielefeld.de> Hi Adam, Am 09.03.2010 00:33, schrieb Adam Dingle: > it's true that Postr is a useful tool for uploading photos to Flickr, > and at the moment it's pretty easy to export from Shotwell to Flickr > using Postr: all you have to do is export photos from Shotwell to a > folder (e.g. on your desktop), then drag the folder into Postr. As you > point out, it might be nice if the user could drag from Shotwell to > Postr directly. Unfortunately that might not so easy to implement given > the intricacies of how drag and drop works in GNOME. Hmm. I've been dragging directly from Shotwell to postr since 0.3. In fact, my previous mail must've been unclear -- I've been wanting to say that dragging to postr works fine and that I'm quite happy with it -- in fact, so happy, that I don't see a point in doing something else ;-) What I do is select a few images, then drag them to the open postr window, into the side-bar that displays images. If I understand what you're saying correctly, I might get old versions of the images, right? I will have to check this, but in the past, I was wondering about exactly this kind of thing (because of Shotwells editing) and it appeared to work just fine. I will re-check with 0.5, though. > We've built exporting to Flickr and other services directly into > Shotwell for a couple of reasons. First, as described above it might > not be so easy to implement drag and drop into other exporting > applications. Second, we like having export inside Shotwell because > over time we may evolve Shotwell to be more deeply integrated with > photo-hosting services. At some point we may automatically sync photos > bidirectionally between Shotwell and hosting sites, so that photos you > upload to a site through a Web browser will be downloaded into Shotwell > automatically. sorry, I didn't mean to say that you shouldn't have export integrated with Shotwell. I just questioned whether to achieve that, you have to /reimplement/ it, instead of integrating with a tool that does it already -- and better. For syncing, gnome-conduit appears to have plugins. I haven't used that personally, but it might be a start. btw, I haven't used gnome-conduit because /automatic/ "syncing of everything" never held much appeal for me, I prefer to be in control of what to sync, like dropbox does it with a particular folder. cheers, -- Ingo L?tkebohle -- http://www.techfak.uni-bielefeld.de/~iluetkeb/ From adam at yorba.org Tue Mar 9 22:25:58 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 09 Mar 2010 14:25:58 -0800 Subject: [Shotwell] export-Feedback In-Reply-To: <4B960E0B.2030004@techfak.uni-bielefeld.de> References: <4B928E5C.5000308@techfak.uni-bielefeld.de> <4B958960.5090805@yorba.org> <4B960E0B.2030004@techfak.uni-bielefeld.de> Message-ID: <4B96CAF6.4070004@yorba.org> An HTML attachment was scrubbed... URL: From mnemo at minimum.se Wed Mar 10 22:41:52 2010 From: mnemo at minimum.se (Martin Olsson) Date: Wed, 10 Mar 2010 23:41:52 +0100 Subject: [Shotwell] Final call for testing Shotwell 0.5 In-Reply-To: <4B953A3F.4070600@yorba.org> References: <4B92E173.9050101@minimum.se> <4B953A3F.4070600@yorba.org> Message-ID: <4B982030.80108@minimum.se> Adam Dingle wrote: > (I know this may result in lots of email; if you'd rather not > be cc-ed on tickets we file for bugs you've reported then just let me > know.) Nah I really enjoy see that you fix the bugs. >> * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr >> ./shotwell" and import >> the photos from this tarball: >> http://temp.minimum.se/shotwell_crashers/catbug.tgz >> Click "Photos", select cat.jpg and then Events::NewEvent. At this >> point the event tree >> first expands but is then automatically collapsed again and it leaves >> me in this weird >> state where no new event node has been added at all to the event node >> tree? In the terminal >> I can see this (below) but it's unclear to me _why_ Shotwell destroys >> the event "Event" ? >> [DBG] LibraryWindow.vala:221: Creating new event page for Event 2 >> [DBG] Event.vala:192: Destroying event Event [1/6] Event 1 >> > > This is expected behavior. The event previously containing cat.jpg is > destroyed (that was Event 1) since it no longer contains any photos: > cat.jpg has been removed from it. A new event is created for cat.jpg > (which happens to look just like the old one). If you find this unduly > confusing, what alternative behavior would you suggest? Not sure, will post if I come up with something good. Anyway, I ran some really large sets of files through the import now and it looks very stable. I did notice one semi-annoying issue when exporting though and some minor related stuff, see below. -- "Can't re-export images originally imported from CD" Repro steps: fetch, unpack and import these: http://temp.minimum.se/shotwell_crashers/bugs.tgz Export both images to a new folder, switch back to Shotwell, drag saturation to bottom on both photos and re-export to the same folder. The export of bug400.jpg now fails because Shotwell can't overwrite the previously exported bug400.jpg (because since this file was chmod 400 apparently the exported version of it is also chmod 400 which doesn't really make sense). For example on CDs files are often all chmod 400 or 444 and in some cases I've seen files chmod'd +x on CDs. I don't think it's entirely clear what is the correct behavior here but I think reusing the chmod from the imported file for the exported file is definitely not the right way to go. A secondary issue here is that Shotwell should bails out with a generic "file error" for something as simple as a "chmod -w"ed file. I think it's better with a "really overwrite read-only file?" confirmation question than expecting users to chmod +w and re-export yet again. If an export fails it would be nice to have some warning printed "per file" to the terminal for debugging purposes because the Shotwell message box only says "X photos failed to export". For example, in the catch where you do failed++ you could also do: warning("Failed to export photo '%s' due to file error '%s'.", basename, err.message); CRITICAL should be printed to the terminal by default (giving better bug reports from people who are not that familar with Shotwell and who don't bother learning about SHOTWELL_X envars). Maybe WARNING as well but you seem to be using that quite a lot for stuff which is not Shotwell bugs. Martin From adam at yorba.org Wed Mar 10 23:44:55 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 10 Mar 2010 15:44:55 -0800 Subject: [Shotwell] Final call for testing Shotwell 0.5 In-Reply-To: <4B982030.80108@minimum.se> References: <4B92E173.9050101@minimum.se> <4B953A3F.4070600@yorba.org> <4B982030.80108@minimum.se> Message-ID: <4B982EF7.70203@yorba.org> Martin, thanks for doing even more pre-release testing! Glad to hear you found no major issues. > -- > > "Can't re-export images originally imported from CD" > Repro steps: fetch, unpack and import these: > http://temp.minimum.se/shotwell_crashers/bugs.tgz > Export both images to a new folder, switch back to > Shotwell, drag saturation to bottom on both photos > and re-export to the same folder. The export of > bug400.jpg now fails because Shotwell can't overwrite > the previously exported bug400.jpg (because since this > file was chmod 400 apparently the exported version of > it is also chmod 400 which doesn't really make sense). > For example on CDs files are often all chmod 400 or 444 > and in some cases I've seen files chmod'd +x on CDs. > I don't think it's entirely clear what is the correct > behavior here but I think reusing the chmod from the > imported file for the exported file is definitely not > the right way to go. > Right. I've filed a ticket in our bug tracking system. We may possibly fix this for 0.5. > A secondary issue here is that Shotwell should bails > out with a generic "file error" for something as simple > as a "chmod -w"ed file. I think it's better with a > "really overwrite read-only file?" confirmation question > than expecting users to chmod +w and re-export yet again. > You're right that we could ask "really overwrite read-only file?" On the other hand, even Nautilus doesn't do that when copying files, and I think we probably don't need to go any further than Nautilus at this time. If you do feel strongly that we should implement this, feel free to file a ticket. > If an export fails it would be nice to have some warning > printed "per file" to the terminal for debugging purposes > because the Shotwell message box only says "X photos failed > to export". For example, in the catch where you do failed++ > you could also do: > warning("Failed to export photo '%s' due to file error '%s'.", basename, err.message); > Right, or we could report the failed filename(s) through a dialog, which might be better for (typical) users who didn't happen to launch Shotwell from the command line. Ticketed. > CRITICAL should be printed to the terminal by default > (giving better bug reports from people who are not that > familar with Shotwell and who don't bother learning about > SHOTWELL_X envars). Maybe WARNING as well but you seem to > be using that quite a lot for stuff which is not Shotwell bugs. > A reasonable suggestion. Ticketed. adam From lucas at yorba.org Sat Mar 13 01:43:38 2010 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 12 Mar 2010 17:43:38 -0800 Subject: [Shotwell] Announce: Shotwell 0.5.0 - a digital photo manager for the GNOME desktop Message-ID: <992b763d1003121743h6cfb07cfye17f5e7e60aaeab6@mail.gmail.com> Yorba has released Shotwell 0.5.0, a major update to our digital photo manager. This release includes a host of new features, including: * Photos can be tagged and organized by tag, creating a new tool for managing your photo collection * Printing * Photos can be published to Google's Picasa Web Albums service * Photo exposure date and time can be set and shifted * Photos can be set as your desktop background directly from Shotwell * Photo import runs in the background, making imports smoother and more fluid * Publishing photos to web services is more responsive * New or updated language support for French, Italian, German, Simplified Chinese, Bulgarian, Danish, Dutch, Estonian, Polish, and Portuguese. * Other stability and performance improvements We highly recommend that all Shotwell users upgrade. Yorba would like to thank all of our bug testers and translators, without whom this release would not have been possible. We'd like to specially thank Martin Olsson, for his rigorous testing of Shotwell 0.5, and Kaj-Ivar van der Wijst, for his stylish redesign of the Yorba website. We'd also like to thank our friends at Red Hat for making Shotwell the default photo manager in Fedora 13 alpha! You can download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ or grab a binary for Ubuntu Karmic or Lucid via Yorba's Launchpad PPA at: https://launchpad.net/~yorba/+archive/ppa -- Lucas Beeler From tommy.he at linux.com Sat Mar 13 12:53:19 2010 From: tommy.he at linux.com (Tommy He) Date: Sat, 13 Mar 2010 12:53:19 +0000 Subject: [Shotwell] Announce: Shotwell 0.5.0 - a digital photo manager for the GNOME desktop In-Reply-To: <992b763d1003121743h6cfb07cfye17f5e7e60aaeab6@mail.gmail.com> References: <992b763d1003121743h6cfb07cfye17f5e7e60aaeab6@mail.gmail.com> Message-ID: <8ed3c2d1003130453t2c9482eg9e5b1ae414bd069@mail.gmail.com> Hello, I published an entry about this exciting announcement on LinuxTOY, a popular Linux news website among Chinese. http://linuxtoy.org/archives/photo-manager-shotwell-050-released.html Thank you for all of you who made this wonderful photo manager. Kind regards, Tommy He On 13 March 2010 01:43, Lucas Beeler wrote: > Yorba has released Shotwell 0.5.0, a major update to our digital photo > manager. This release includes a host of new features, including: > > * Photos can be tagged and organized by tag, creating a new > tool for managing your photo collection > > * Printing > > * Photos can be published to Google's Picasa Web Albums > service > > * Photo exposure date and time can be set and shifted > > * Photos can be set as your desktop background directly > from Shotwell > > * Photo import runs in the background, making imports smoother > and more fluid > > * Publishing photos to web services is more responsive > > * New or updated language support for French, Italian, German, > Simplified Chinese, Bulgarian, Danish, Dutch, Estonian, > Polish, and Portuguese. > > * Other stability and performance improvements > > We highly recommend that all Shotwell users upgrade. > > Yorba would like to thank all of our bug testers and translators, > without whom this release would not have been possible. We'd like to > specially thank Martin Olsson, for his rigorous testing of Shotwell > 0.5, and Kaj-Ivar van der Wijst, for his stylish redesign of the Yorba > website. > > We'd also like to thank our friends at Red Hat for making Shotwell the > default photo manager in Fedora 13 alpha! > > You can download a source tarball from the Shotwell home page at: > http://www.yorba.org/shotwell/ > > or grab a binary for Ubuntu Karmic or Lucid via Yorba's Launchpad PPA at: > https://launchpad.net/~yorba/+archive/ppa > > -- Lucas Beeler > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- Take a Deep Breath out of Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Sat Mar 13 13:29:17 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Sat, 13 Mar 2010 14:29:17 +0100 Subject: [Shotwell] export-Feedback In-Reply-To: <4B96CAF6.4070004@yorba.org> References: <4B928E5C.5000308@techfak.uni-bielefeld.de> <4B958960.5090805@yorba.org> <4B960E0B.2030004@techfak.uni-bielefeld.de> <4B96CAF6.4070004@yorba.org> Message-ID: <4B9B932D.40902@techfak.uni-bielefeld.de> Hi Adam, Am 09.03.2010 23:25, schrieb Adam Dingle: > the destination folder *after* the user lets go of the drag. But this means that > it's now possible to drag and drop only to Nautilus, not to other applications Thanks for the explanation, thats good to know. Am I correct in assuming the root cause of the difference to be that Nautilus makes a copy -- hence, it can accept transient data, whereas postr (and other tools) just use a reference, and thus can accept static data only? I guess there is no easy way around that. The trouble would seem to be that drag'n'drop's interaction model is too restricted. Is there no way to allow an interaction between the two applications, that could make these things easier? For example, this could enable Shotwell to provide the edited data on-demand (and multiple times, so that postr can display a thumbnail immediately and request the full data on upload, for immediate sending). btw, picasa and f-spot don't do too well on this either: Picasa requires an explicit sync to disk for changes to appear, whereas f-spot just doesn't do dragging properly at all. In fact, this was one of the reasons why I preferred Shotwell ;-) Please don't take it as criticism of Shotwell when I say that this is a serious PITA. I now understand why it happens, but this is just so wrong and all the "workarounds" strike me as just that. This is annoying beyond flickr-export -- there are all sorts of applications which accept data by drag'n'drop and none of these will work properly. > (just like when dragging from File Roller, for example). I have noticed that -- though I have to say that the use cases for working with archive files are different from those of photos. > well would be to change Shotwell so that it would keep full-resolution versions > of all edited images at all times. We could possibly do that, but it would be a > large change and we'd need to generate the images in the background to avoid > slowing down the user interface. We'll think about this more as a possibility > for future releases. Well, it would not be a solution for postr (at least not right now), but maybe you could pass around different URLs, such as http-URLs, which would enable you to provide data on-demand by opening a local http-Server. Just a thought -- maybe there are other protocols that would make this work better. btw, postr doesn't accept http URLs, but GIMP, for example, does. I guess it wouldn't be too hard to extend postr to do, too. cheers, Ingo From adam at yorba.org Sun Mar 14 16:22:32 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 14 Mar 2010 09:22:32 -0700 Subject: [Shotwell] export-Feedback In-Reply-To: <4B9B932D.40902@techfak.uni-bielefeld.de> References: <4B928E5C.5000308@techfak.uni-bielefeld.de> <4B958960.5090805@yorba.org> <4B960E0B.2030004@techfak.uni-bielefeld.de> <4B96CAF6.4070004@yorba.org> <4B9B932D.40902@techfak.uni-bielefeld.de> Message-ID: <7c6db8601003140922kd577646kf714276d438ed5e2@mail.gmail.com> Ingo, the root cause of the difference between Nautilus and other applications is that Nautilus has a special feature which allows us to receive the URI of the destination folder when a user drags into Nautilus. This allows the source application (in this case, Shotwell) to construct the required files and copy them into the destination URI after the drag completes. For other drag destinations such as Postr, at drag time we must provide a set of URIs which already contain the files to be transferred. I agree that allowing dragging to Postr and other applications would be great. Your suggestion of using a local HTTP server is interesting. There might be other tricks we can play such as using a socket or a named pipe, or somehow extending the drag/drop protocol itself. Or perhaps we can extend Shotwell so that it automatically keeps full-resolution images up to date in the background (though there are some concerns there about CPU usage and disk space). I've created a ticket for this at http://trac.yorba.org/ticket/1563 - we'll keep thinking about this. cheers adam On Sat, Mar 13, 2010 at 6:29 AM, Ingo L?tkebohle < iluetkeb at techfak.uni-bielefeld.de> wrote: > Hi Adam, > > Am 09.03.2010 23:25, schrieb Adam Dingle: > > the destination folder *after* the user lets go of the drag. But this > means that > > it's now possible to drag and drop only to Nautilus, not to other > applications > > Thanks for the explanation, thats good to know. Am I correct in assuming > the root cause of the difference to be that Nautilus makes a copy -- > hence, it can accept transient data, whereas postr (and other tools) > just use a reference, and thus can accept static data only? > > I guess there is no easy way around that. The trouble would seem to be > that drag'n'drop's interaction model is too restricted. Is there no way > to allow an interaction between the two applications, that could make > these things easier? For example, this could enable Shotwell to provide > the edited data on-demand (and multiple times, so that postr can display > a thumbnail immediately and request the full data on upload, for > immediate sending). > > btw, picasa and f-spot don't do too well on this either: Picasa requires > an explicit sync to disk for changes to appear, whereas f-spot just > doesn't do dragging properly at all. In fact, this was one of the > reasons why I preferred Shotwell ;-) > > Please don't take it as criticism of Shotwell when I say that this is a > serious PITA. I now understand why it happens, but this is just so wrong > and all the "workarounds" strike me as just that. > > This is annoying beyond flickr-export -- there are all sorts of > applications which accept data by drag'n'drop and none of these will > work properly. > > > (just like when dragging from File Roller, for example). > > I have noticed that -- though I have to say that the use cases for > working with archive files are different from those of photos. > > > well would be to change Shotwell so that it would keep full-resolution > versions > > of all edited images at all times. We could possibly do that, but it > would be a > > large change and we'd need to generate the images in the background to > avoid > > slowing down the user interface. We'll think about this more as a > possibility > > for future releases. > > Well, it would not be a solution for postr (at least not right now), but > maybe you could pass around different URLs, such as http-URLs, which > would enable you to provide data on-demand by opening a local > http-Server. Just a thought -- maybe there are other protocols that > would make this work better. > > btw, postr doesn't accept http URLs, but GIMP, for example, does. I > guess it wouldn't be too hard to extend postr to do, too. > > cheers, Ingo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at yorba.org Sun Mar 14 16:30:21 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 14 Mar 2010 09:30:21 -0700 Subject: [Shotwell] Features for Shotwell 0.6 Message-ID: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> Now that Shotwell 0.5 is out the door, we're already beginning to plan for Shotwell 0.6. We're interested in input from you, the Shotwell community, about the features you'd most like to see. If you could choose only a small number of features for the next release, which would they be? Your ideas are welcome - thanks! adam === Adam Dingle Yorba -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas at aquarionics.com Sun Mar 14 18:15:32 2010 From: nicholas at aquarionics.com (Nicholas Avenell) Date: Sun, 14 Mar 2010 18:15:32 +0000 Subject: [Shotwell] Clean install of 0.5 for windows doesn't appear to work Message-ID: Hi, I've just downloaded and installed Shotwell 0.5 onto a clean install of Windows 7 (Well, fairly clean, it was new on Friday) When installing (to F:\Program Files (x86)\Shotwell) I get an error dialog like this: title: gdk-pixbuf-query-loaders.exe - System Error content: The program can't start because libjpeg-7.dll is missing from your computer. Try reinstalling the program to fix this problem buttons: [ OK ] and when I OK that: title: gdk-pixbuf-query-loaders.exe - System Error content: The program can't start because libfontconfig-1.dll is missing from your computer. Try reinstalling the program to fix this problem buttons: [ OK ] This leaves Shotwell installed, but if I run it I get an almost identical error: title: shotwell.exe - System Error content: The program can't start because libfontconfig-1.dll is missing from your computer. Try reinstalling the program to fix this problem buttons: [ OK ] A bit of googling told me that those libraries were part of the GTK+ runtime, which recently removed some libraries from the default install, including libjpeg-7.dll, so I installed the GTK+ runtime manually from http://gtk-win.sourceforge.net/home/index.php/en/Home This appears to fix the initial problem, but now I get this dialog instead: title: Error content: ** ERROR **: Resources.vala:314: Couldn't recognise the image file format for file "F:\Program Files(x86)\Shotwell\share\shotwell\icons\object-rotate-right.svg" aborting... buttons: [ OK ] Any idea what I can do to get this up and running? -- Nicholas 'Aquarion' Avenell http://www.aquarionics.com - http://www.nicholasavenell.com "Nothing takes the taste out of peanut butter quite like unrequited love." - Charlie Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at yorba.org Sun Mar 14 23:25:01 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 14 Mar 2010 16:25:01 -0700 Subject: [Shotwell] Clean install of 0.5 for windows doesn't appear to work In-Reply-To: References: Message-ID: <4B9D704D.2000403@yorba.org> An HTML attachment was scrubbed... URL: From mnemo at minimum.se Mon Mar 15 22:33:51 2010 From: mnemo at minimum.se (Martin Olsson) Date: Mon, 15 Mar 2010 23:33:51 +0100 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> Message-ID: <4B9EB5CF.7000209@minimum.se> Adam Dingle wrote: > Now that Shotwell 0.5 is out the door, we're already beginning to plan for > Shotwell 0.6. We're interested in input from you, the Shotwell community, > about the features you'd most like to see. If you could choose only a small > number of features for the next release, which would they be? Your ideas > are welcome - thanks! In this order, as many as possible without compromising quality: * NEF/CRW support * A basic screensaver that shows images from your Shotwell photo collection * Enhance the screensaver so that it does this: http://www.photojoy.com/gallery/gallery.aspx?type_id=4&id=11213 * Video playback/seeking * Export album to static HTML website; to local folder, SFTP, SSH and FTP (resident geek owns hosting and sets it up, family member just clicks Publish) * Export to Gallery ( http://gallery.menalto.com/ ) * Ability to attach tags during import (i.e. if I shot photos during an 8 day vacation they are currently split into several date-based events which is fine but it's a bit annoying having to go into each separate day from my vacation, then select all and add the tag). * Photo specific printing, i.e. ability to select X photos and group them Y per page, ability to choose how the photos are rotated on the paper. * Currently you can easily navigate to "Photos from December 2005" using the events tree, but in a semi professional photo workflow you'd often to the same for other metadata such as specific DSLR lenses or GPS data. Sometimes these are also combined (i.e. I want to see all the shoots from my 50mm fixed lens taken in India). * Upload video to youtube. * Super simple editor for still image slideshow videos (user selects duration for each still, selects transition effects, selects background music, possibly adds some caption texts) * Support Adobe DNG and RAW formats from minor camera manufacturers. Also as a parallel to all of this: * Automated UI sanity tests, unittests, code coverage and performance regression tests - Helps new devs get started. - Extends product lifetime by helping non-core devs maintain the project and its quality, years after it's "pioneer glory" days fade away (i.e when many yorba devs focus on Lombard instead or whatever). - It's hard to catch up if you have a huge backlog of untested features. - Ensures package sanity on each specific target platform before shipping (i.e. Debian will add the "make check" to their debuild etc ensuring that stuff like the issues Lucid had earlier are detected before reaching end users) - In reality no human notices a series of small perf regressions that happen over time so the only way to deliver great perf is to have tests for it; i.e. use "sync" and "/proc/sys/vm/drop_caches" followed by a normal import for example. Martin From tonyw at pobox.com Tue Mar 16 01:40:07 2010 From: tonyw at pobox.com (Tony Willoughby) Date: Mon, 15 Mar 2010 21:40:07 -0400 Subject: [Shotwell] Importing Tags Message-ID: I've just started playing with 0.5.0 and it's pretty impressive. I've been using kphotoalbum for several years now and have nearly 9000 images tagged with events, people, places, etc. I'd love to make the switch to shotwell, but I can't afford to loose all those tags. Kphoto stores tags in XML, is it possible to import these into shotwell? -- Tony Willoughby tonyw at pobox.com "Maple syrup makers never die, they just evaporate." -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at yorba.org Tue Mar 16 16:52:24 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 16 Mar 2010 09:52:24 -0700 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <4B9EB5CF.7000209@minimum.se> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <4B9EB5CF.7000209@minimum.se> Message-ID: <4B9FB748.9080606@yorba.org> Martin, thanks for the suggestions - these are all great ideas. Some of them weren't already on our to-do list and so I've added tickets for those. It's safe to say these won't all happen in 0.6 :) but we'll keep these in mind as we plan the next couple of releases. I agree that automated tests would be great for all the reasons you describe. Testing in a completely automated way might not be completely easy since Shotwell is a relatively interactive and visual program, but I hope we can take some steps in this direction before long. Below, I've listed the tickets for each of your suggestions so that you (or others) can track them if you like. > * NEF/CRW support > http://trac.yorba.org/ticket/522 > * A basic screensaver that shows images from your Shotwell photo collection > http://trac.yorba.org/ticket/1112 > * Enhance the screensaver so that it does this: http://www.photojoy.com/gallery/gallery.aspx?type_id=4&id=11213 > http://trac.yorba.org/ticket/1579 > * Video playback/seeking > http://trac.yorba.org/ticket/855 > * Export album to static HTML website; to local folder, SFTP, SSH and FTP (resident geek owns hosting and sets it up, family member just clicks Publish) > http://trac.yorba.org/ticket/1580 > * Export to Gallery ( http://gallery.menalto.com/ ) > http://trac.yorba.org/ticket/1585 > * Ability to attach tags during import (i.e. if I shot photos during an 8 day vacation they are currently split into several date-based events which is fine but it's a bit annoying having to go into each separate day from my vacation, then select all and add the tag). > http://trac.yorba.org/ticket/1586 > * Photo specific printing, i.e. ability to select X photos and group them Y per page, ability to choose how the photos are rotated on the paper. > http://trac.yorba.org/ticket/1188 > * Currently you can easily navigate to "Photos from December 2005" using the events tree, but in a semi professional photo workflow you'd often to the same for other metadata such as specific DSLR lenses or GPS data. Sometimes these are also combined (i.e. I want to see all the shoots from my 50mm fixed lens taken in India). > http://trac.yorba.org/ticket/1587 > * Upload video to youtube. > http://trac.yorba.org/ticket/1589 > * Super simple editor for still image slideshow videos (user selects duration for each still, selects transition effects, selects background music, possibly adds some caption texts) > http://trac.yorba.org/ticket/1591 http://trac.yorba.org/ticket/1590 > * Support Adobe DNG and RAW formats from minor camera manufacturers. > http://trac.yorba.org/ticket/522 > Also as a parallel to all of this: > * Automated UI sanity tests, unittests, code coverage and performance regression tests > http://trac.yorba.org/ticket/1068 adam From adam at yorba.org Tue Mar 16 18:04:07 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 16 Mar 2010 11:04:07 -0700 Subject: [Shotwell] Importing Tags In-Reply-To: References: Message-ID: <4B9FC817.9050701@yorba.org> Tony, > I've just started playing with 0.5.0 and it's pretty impressive. > Thanks! > I've been using kphotoalbum for several years now and have nearly 9000 > images tagged with events, people, places, etc. > > I'd love to make the switch to shotwell, but I can't afford to loose all > those tags. Kphoto stores tags in XML, is it possible to import these into > shotwell? > > It's not yet possible to import these tags into Shotwell, unfortunately. Within the next couple of releases we hope to be able to import from IPTC tags embedded in photo files (see http://trac.yorba.org/ticket/1290). I don't know whether KPhotoAlbum can export IPTC tags, however. A Web search for [kphotoalbum iptc] reveals that there has been some work in that direction, but I don't know whether it's made it into the shipping KPhotoAlbum. In theory we could implement KPhotoAlbum-specific importing in Shotwell. Feel free to file a ticket for that if you like, though I think we would definitely prioritize that below importing from IPTC tags, which are supported by many photo applications. adam From tonyw at pobox.com Wed Mar 17 02:22:03 2010 From: tonyw at pobox.com (Tony Willoughby) Date: Tue, 16 Mar 2010 22:22:03 -0400 Subject: [Shotwell] Importing Tags In-Reply-To: <4B9FC817.9050701@yorba.org> References: <4B9FC817.9050701@yorba.org> Message-ID: <4BA03CCB.3070104@pobox.com> I don't think Kphotoalbum exports IPTC tags (I don't think that would serve my purposes as I'm interested in the tags I added myself). I'm a programmer and could probably help out. Is there an existing API into Shotwell? Or perhaps a structure how to set values directly into SQLite? Adam Dingle wrote: > Tony, >> I've just started playing with 0.5.0 and it's pretty impressive. >> > > Thanks! > >> I've been using kphotoalbum for several years now and have nearly 9000 >> images tagged with events, people, places, etc. >> >> I'd love to make the switch to shotwell, but I can't afford to loose all >> those tags. Kphoto stores tags in XML, is it possible to import these >> into >> shotwell? >> >> > > It's not yet possible to import these tags into Shotwell, > unfortunately. Within the next couple of releases we hope to be able to > import from IPTC tags embedded in photo files (see > http://trac.yorba.org/ticket/1290). I don't know whether KPhotoAlbum > can export IPTC tags, however. A Web search for [kphotoalbum iptc] > reveals that there has been some work in that direction, but I don't > know whether it's made it into the shipping KPhotoAlbum. > > In theory we could implement KPhotoAlbum-specific importing in > Shotwell. Feel free to file a ticket for that if you like, though I > think we would definitely prioritize that below importing from IPTC > tags, which are supported by many photo applications. > > adam > -- Tony Willoughby tonyw at pobox.com "Bill Clinton and Yalmulke Lewinski" -My 4 year old son describing his parents' Halloween costumes to his teacher. From jim at yorba.org Wed Mar 17 18:05:32 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 17 Mar 2010 11:05:32 -0700 Subject: [Shotwell] Importing Tags In-Reply-To: <4BA03CCB.3070104@pobox.com> References: <4B9FC817.9050701@yorba.org> <4BA03CCB.3070104@pobox.com> Message-ID: We don't have an API or a plug-in system yet (although those are things we are considering for future releases). The easiest thing -- and I feel the "right" way to do this -- would be for Kphotoalbum to write those tags into the photo files themselves as IPTC tags. (There may be other open mechanisms for this, but that is the most obvious and widespread.) We are planning for Shotwell 0.6 to read those tags at import time and automatically tag the photos internally. With all this in place, everything Would Just Work. Since it doesn't sound like Kphotoalbum writes tags to the photo files, and Shotwell doesn't read them yet, the solution's not straightforward. A long-term solution is to think in terms of migration, not merely data conversion; we have tickets to offer F-Spot migration, for example. I would suggest you ticket Kphotoalbum migration as well, if this is important to you. I can't in good conscious recommend you update the internal database directly, as we're treating that as a private persistent data store -- the schema could alter at any time, and for that matter, we might remove SQLite and go with another system. But if you *were* to update it directly, you would (a) need to make those updates with Shotwell not running, and (b) have to import the photo files without copying them into the library, as I bet Kphotoalbum's data file uses absolute file paths. I would also recommend saving a backup of your ~/.shotwell directory. If you look in Shotwell's source, in DatabaseTables.vala, you'll get an idea of how the database is laid out and how the TagTable is tied to the other tables. -- Jim On Tue, Mar 16, 2010 at 7:22 PM, Tony Willoughby wrote: > > I don't think Kphotoalbum exports IPTC tags (I don't think that would > serve my purposes as I'm interested in the tags I added myself). > > I'm a programmer and could probably help out. Is there an existing API > into Shotwell? Or perhaps a structure how to set values directly into > SQLite? > > > > > > Adam Dingle wrote: > > Tony, > >> I've just started playing with 0.5.0 and it's pretty impressive. > >> > > > > Thanks! > > > >> I've been using kphotoalbum for several years now and have nearly 9000 > >> images tagged with events, people, places, etc. > >> > >> I'd love to make the switch to shotwell, but I can't afford to loose all > >> those tags. Kphoto stores tags in XML, is it possible to import these > >> into > >> shotwell? > >> > >> > > > > It's not yet possible to import these tags into Shotwell, > > unfortunately. Within the next couple of releases we hope to be able to > > import from IPTC tags embedded in photo files (see > > http://trac.yorba.org/ticket/1290). I don't know whether KPhotoAlbum > > can export IPTC tags, however. A Web search for [kphotoalbum iptc] > > reveals that there has been some work in that direction, but I don't > > know whether it's made it into the shipping KPhotoAlbum. > > > > In theory we could implement KPhotoAlbum-specific importing in > > Shotwell. Feel free to file a ticket for that if you like, though I > > think we would definitely prioritize that below importing from IPTC > > tags, which are supported by many photo applications. > > > > adam > > > > -- > Tony Willoughby tonyw at pobox.com > "Bill Clinton and Yalmulke Lewinski" > -My 4 year old son describing his parents' > Halloween costumes to his teacher. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.velazquez08 at gmail.com Sat Mar 20 15:38:16 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Sat, 20 Mar 2010 11:38:16 -0400 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> Message-ID: <90f0eaee1003200838s76579da7m77121d871161f312@mail.gmail.com> On Sun, Mar 14, 2010 at 12:30 PM, Adam Dingle wrote: > Now that Shotwell 0.5 is out the door, we're already beginning to plan for > Shotwell 0.6. We're interested in input from you, the Shotwell community, > about the features you'd most like to see. If you could choose only a small > number of features for the next release, which would they be? Your ideas > are welcome - thanks! > > adam > > === > Adam Dingle > Yorba > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > I'd like to see Shotwell be able to recognize .png's if it's simple enough. Somehow I ended up with a ton of pictures in this format and Shotwell says they are unrecognized files when I go to import them. The ability to monitor a directory for new pictures either upon startup or only while running would be nice as well, Picasa-esque in nature I guess. I'm not sure if Shotwell has this right now but scanning for dupes (by date/name?) or however it's done would be useful. Combined with a prompt set in the preferences to either delete, prompt the user on what to do, or do nothing at all would be nifty as well. My thoughts, thanks for a great product! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.he at linux.com Sat Mar 20 15:50:38 2010 From: tommy.he at linux.com (Tommy He) Date: Sat, 20 Mar 2010 15:50:38 +0000 Subject: [Shotwell] Fwd: Features for Shotwell 0.6 In-Reply-To: <8ed3c2d1003200850uc9a0227jf0f8803fc956faf7@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <8ed3c2d1003200850uc9a0227jf0f8803fc956faf7@mail.gmail.com> Message-ID: <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> ---------- Forwarded message ---------- From: Tommy He Date: 20 March 2010 15:50 Subject: Re: [Shotwell] Features for Shotwell 0.6 To: Adam Dingle It would be great that shotwell 0.6 could generate the tag according the existing folder name. I think there are still a lot of people use the old folder to organize their photo collection. The ability to generate the tag from the folder name would help them immigrate to this more efficient way to organize without losing the existing database structure. Kind regards, On 14 March 2010 16:30, Adam Dingle wrote: > Now that Shotwell 0.5 is out the door, we're already beginning to plan for > Shotwell 0.6. We're interested in input from you, the Shotwell community, > about the features you'd most like to see. If you could choose only a small > number of features for the next release, which would they be? Your ideas > are welcome - thanks! > > adam > > === > Adam Dingle > Yorba > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -- Take a Deep Breath out of Windows -- Take a Deep Breath out of Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.velazquez08 at gmail.com Sun Mar 21 02:20:39 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Sat, 20 Mar 2010 22:20:39 -0400 Subject: [Shotwell] Fwd: Features for Shotwell 0.6 In-Reply-To: <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <8ed3c2d1003200850uc9a0227jf0f8803fc956faf7@mail.gmail.com> <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> Message-ID: <90f0eaee1003201920g2cb657a8g3f6194b9bda7a607@mail.gmail.com> I love this idea. I keep my photos organized hierarchically in folders with the event name or other meaningful names. The ability to tag all photos within a directory from the directory name would be amazing. On Sat, Mar 20, 2010 at 11:50 AM, Tommy He wrote: > > > ---------- Forwarded message ---------- > From: Tommy He > Date: 20 March 2010 15:50 > Subject: Re: [Shotwell] Features for Shotwell 0.6 > To: Adam Dingle > > > It would be great that shotwell 0.6 could generate the tag according the > existing folder name. I think there are still a lot of people use the old > folder to organize their photo collection. The ability to generate the tag > from the folder name would help them immigrate to this more efficient way to > organize without losing the existing database structure. > > Kind regards, > > On 14 March 2010 16:30, Adam Dingle wrote: > >> Now that Shotwell 0.5 is out the door, we're already beginning to plan for >> Shotwell 0.6. We're interested in input from you, the Shotwell community, >> about the features you'd most like to see. If you could choose only a small >> number of features for the next release, which would they be? Your ideas >> are welcome - thanks! >> >> adam >> >> === >> Adam Dingle >> Yorba >> >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > > > -- > Take a Deep Breath out of Windows > > > > -- > Take a Deep Breath out of Windows > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Sun Mar 21 19:53:54 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Sun, 21 Mar 2010 20:53:54 +0100 Subject: [Shotwell] Importing Tags In-Reply-To: <4BA03CCB.3070104@pobox.com> References: <4B9FC817.9050701@yorba.org> <4BA03CCB.3070104@pobox.com> Message-ID: <4BA67952.8080305@techfak.uni-bielefeld.de> Tony, Am 17.03.2010 03:22, schrieb Tony Willoughby: > I'm a programmer and could probably help out. Is there an existing API > into Shotwell? Or perhaps a structure how to set values directly into > SQLite? exiv2 can manipulate IPTC tags. If KPhotoAlbum stores the tags as XML, I bet it would be pretty easy to whip up a script that extracts them and modifies the files with exiv2. cheers, Ingo From iluetkeb at techfak.uni-bielefeld.de Sun Mar 21 20:00:12 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Sun, 21 Mar 2010 21:00:12 +0100 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> Message-ID: <4BA67ACC.4040300@techfak.uni-bielefeld.de> Am 14.03.2010 17:30, schrieb Adam Dingle: > Now that Shotwell 0.5 is out the door, we're already beginning to plan for > Shotwell 0.6. We're interested in input from you, the Shotwell community, > about the features you'd most like to see. If you could choose only a small > number of features for the next release, which would they be? Your ideas > are welcome - thanks! * a D-BUS API (or a REST one) * json/xml import/export for photo meta-data These two would go well together, btw, with D-BUS/REST exchange in that data-format. In fact, I wonder why you haven't done this already ;-) Of course, I recognize that both of these things can be pretty hard to specify when you're not exactly sure yet what Shotwell will develop towards. However, both D-BUS and REST are pretty extensible in a backwards-compatible way, so I'd suggest just jumping in there. Regarding the meta-data stuff, IPTC would probably be a good start. Cheers, Ingo From tonyw at pobox.com Sun Mar 21 20:00:18 2010 From: tonyw at pobox.com (Tony Willoughby) Date: Sun, 21 Mar 2010 16:00:18 -0400 Subject: [Shotwell] Importing Tags In-Reply-To: <4BA67952.8080305@techfak.uni-bielefeld.de> References: <4B9FC817.9050701@yorba.org> <4BA03CCB.3070104@pobox.com> <4BA67952.8080305@techfak.uni-bielefeld.de> Message-ID: <4BA67AD2.8070904@pobox.com> Okay, I'll look into it. Thanks for the tip. Ingo L?tkebohle wrote: > Tony, > > Am 17.03.2010 03:22, schrieb Tony Willoughby: >> I'm a programmer and could probably help out. Is there an existing API >> into Shotwell? Or perhaps a structure how to set values directly into >> SQLite? > > exiv2 can manipulate IPTC tags. If KPhotoAlbum stores the tags as XML, I > bet it would be pretty easy to whip up a script that extracts them and > modifies the files with exiv2. > > cheers, Ingo > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -- Tony Willoughby tonyw at pobox.com "Next time, I would rather break than bend." - Warren Zevon From adam at yorba.org Mon Mar 22 00:37:18 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 21 Mar 2010 17:37:18 -0700 Subject: [Shotwell] Fwd: Features for Shotwell 0.6 In-Reply-To: <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <8ed3c2d1003200850uc9a0227jf0f8803fc956faf7@mail.gmail.com> <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> Message-ID: <4BA6BBBE.4090909@yorba.org> An HTML attachment was scrubbed... URL: From adam at yorba.org Mon Mar 22 00:44:57 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 21 Mar 2010 17:44:57 -0700 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <90f0eaee1003200838s76579da7m77121d871161f312@mail.gmail.com> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <90f0eaee1003200838s76579da7m77121d871161f312@mail.gmail.com> Message-ID: <4BA6BD89.5020803@yorba.org> David, thanks for the suggestions for 0.6. > I'd like to see Shotwell be able to recognize .png's if it's simple enough. > Somehow I ended up with a ton of pictures in this format and Shotwell says > they are unrecognized files when I go to import them. > Yes - this is http://trac.yorba.org/ticket/602 . Probably coming soon. > The ability to monitor a directory for new pictures either upon startup or > only while running would be nice as well, Picasa-esque in nature I guess. > Right - we're interested in this too. This is http://trac.yorba.org/ticket/374 . We're still undecided whether Shotwell should always scan the entire library for changes on every startup (which might not actually be so bad if we can do it in the background) or whether the user should be able to configure this for each library directory (like in Picasa). > I'm not sure if Shotwell has this right now but scanning for dupes (by > date/name?) or however it's done would be useful. Combined with a prompt set > in the preferences to either delete, prompt the user on what to do, or do > nothing at all would be nifty as well. > Today, if your library contains photo A and you import photo B which is a duplicate of A, then Shotwell detects the duplicate and does not import B. If, however, you simultaneously import two photos which are duplicates of each other, then Shotwell imports both. So if you have an existing folder that contains duplicates and you import it into Shotwell, you still have the duplicates. We'd like to fix this so that Shotwell detects simultaneously imported duplicates as well; this is http://trac.yorba.org/ticket/1418 . > My thoughts, thanks for a great product! > > Thanks! adam From adam at yorba.org Mon Mar 22 01:09:45 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 21 Mar 2010 18:09:45 -0700 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <4BA67ACC.4040300@techfak.uni-bielefeld.de> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <4BA67ACC.4040300@techfak.uni-bielefeld.de> Message-ID: <4BA6C359.8080408@yorba.org> Ingo L?tkebohle wrote: > * a D-BUS API (or a REST one) > By a D-Bus API, do you mean an API that allows other processes to control the running Shotwell instance via D-Bus, sending it commands which are similar to Shotwell's menu commands (e.g. import, rotate, publish and so on)? And by a REST API, do you mean a similar mechanism in which Shotwell will listen for HTTP connections at some port and respond to similar commands sent in REST style? We haven't thought much about such mechanisms. When Shotwell does have an API, we've been thinking that it will work more like gedit: people will be able to write plugins, which will be shared libraries which Shotwell will load on startup. With this system, plugins will be able to add menu commands to Shotwell and will be able to manipulate the Shotwell library by calling API functions, but this will all happen in-process. (This is http://trac.yorba.org/ticket/1603 ). Do you see compelling use cases for an external D-Bus API rather than an internal plugin-based one? If so, can you explain them a bit? > * json/xml import/export for photo meta-data > For tags, captions and descriptions we've been thinking that we'd implement import/export via IPTC/XMP metadata. When Shotwell imports photos, it can read this metadata automatically (http://trac.yorba.org/ticket/1596). As for exporting (http://trac.yorba.org/ticket/1290), perhaps Shotwell can keep IPTC/XMP tags up to date in photo files automatically (like Picasa), or perhaps it can write these tags back to photo files only when the user explicitly requests it. I hope we'll be able to update the tags automatically at some point. Are you proposing JSON/XML import/export because (a) you want to import/export metadata which can't be conveniently stored in IPTC/XMP (e.g. Shotwell's event information), or (b) you think that JSON/XML import/export might be more a useful mechanism than IPTC/XMP? We might lean toward IPTC/XMP because it keeps the metadata with the photo files and is likely to work with other photo managers automatically. But if you have use cases for (a) and/or (b) then we'd be interested to hear them. cheers adam From tommy.he at linux.com Mon Mar 22 12:44:52 2010 From: tommy.he at linux.com (Tommy He) Date: Mon, 22 Mar 2010 12:44:52 +0000 Subject: [Shotwell] Fwd: Features for Shotwell 0.6 In-Reply-To: <4BA6BBBE.4090909@yorba.org> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <8ed3c2d1003200850uc9a0227jf0f8803fc956faf7@mail.gmail.com> <8ed3c2d1003200850l59a13a9dr72decab0d4a63902@mail.gmail.com> <4BA6BBBE.4090909@yorba.org> Message-ID: <8ed3c2d1003220544k9bca3e4gcddac9ac12a0f941@mail.gmail.com> Magnificently useful. I also like the feature of auto-import. Current manual import is probably not efficient in certain user case. When user John receive a photo from his friend, he has to put the photo in a directory adhere to the topic and import it into Shotwell manually. Auto-import could integrate these two steps. Kind regards, On 22 March 2010 00:37, Adam Dingle wrote: > Tommy, > > Instead of adding a feature which assigns tags according to folder names, I > think it's more likely that we'll add a new sidebar tree that lets you > browse all photos according to the folders which contain them ( > http://trac.yorba.org/ticket/1594). I think that would be clearer and > easier for the user, and would also allow Shotwell to react automatically > when the folder structure changes if/when Shotwell becomes smart enough to > watch the contents of library directories ( > http://trac.yorba.org/ticket/374). Does this sound useful to you? > > By the way, we'd eventually like to have yet another sidebar tree that lets > you browse photos according to the location they were taken using GPS > information in the photos (http://trac.yorba.org/ticket/1473). This tree > might have groupings by country, state, city and so on. > > adam > > Tommy He wrote: > > ---------- Forwarded message ---------- > From: Tommy He > Date: 20 March 2010 15:50 > Subject: Re: [Shotwell] Features for Shotwell 0.6 > To: Adam Dingle > > > It would be great that shotwell 0.6 could generate the tag according the > existing folder name. I think there are still a lot of people use the old > folder to organize their photo collection. The ability to generate the tag > from the folder name would help them immigrate to this more efficient way to > organize without losing the existing database structure. > > Kind regards, > > On 14 March 2010 16:30, Adam Dingle wrote: > > > > Now that Shotwell 0.5 is out the door, we're already beginning to plan for > Shotwell 0.6. We're interested in input from you, the Shotwell community, > about the features you'd most like to see. If you could choose only a small > number of features for the next release, which would they be? Your ideas > are welcome - thanks! > > adam > > === > Adam Dingle > Yorba > > > _______________________________________________ > Shotwell mailing listShotwell at lists.yorba.orghttp://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > ------------------------------ > > _______________________________________________ > Shotwell mailing listShotwell at lists.yorba.orghttp://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > -- Take a Deep Breath out of Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.he at linux.com Wed Mar 24 23:00:27 2010 From: tommy.he at linux.com (Tommy He) Date: Wed, 24 Mar 2010 23:00:27 +0000 Subject: [Shotwell] Minor problems on shotwell website on Windows Message-ID: <8ed3c2d1003241600u188b4fc3g59cded35c658d3cd@mail.gmail.com> Hello, Yesterday I recommend shotwell to my friend who uses Windows. However, it turned out that she was directly lead to the old 0.4.3 alpha windows version rather than the download page with new 0.5.1 version. So that I had to download the windows version with my Linux box and sent it to her. After that, I used the user agent switcher add-on to disguise as IE8. Blah, old 0.4.3 windows version on front page. It probably not what it should be. Another problem only occurs on Windows package. I see it's experimental phase for windows version currently, but it would receive more result from wider regions if the local language packs were included in Windows installer. Now it seems there is only English language. Kind regards, Tommy He -- Take a Deep Breath out of Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From kajivarvdw at gmail.com Thu Mar 25 05:46:07 2010 From: kajivarvdw at gmail.com (Kaj-Ivar van der Wijst) Date: Thu, 25 Mar 2010 06:46:07 +0100 Subject: [Shotwell] Minor problems on shotwell website on Windows In-Reply-To: <8ed3c2d1003241600u188b4fc3g59cded35c658d3cd@mail.gmail.com> References: <8ed3c2d1003241600u188b4fc3g59cded35c658d3cd@mail.gmail.com> Message-ID: <4BAAF89F.2010607@gmail.com> Hi, Thanks for pointing out the problem. I just send a fix for that yesterday, and it should be updated very soon. Sorry for the inconvenience! For the languages in the windows binaries, I didn't know it, but it looks like a good idea. Best regards, Kaj-Ivar Op 25-03-10 00:00, Tommy He schreef: > Hello, > > Yesterday I recommend shotwell to my friend who uses Windows. However, > it turned out that she was directly lead to the old 0.4.3 alpha > windows version rather than the download page with new 0.5.1 version. > So that I had to download the windows version with my Linux box and > sent it to her. > After that, I used the user agent switcher add-on to disguise as IE8. > Blah, old 0.4.3 windows version on front page. It probably not what it > should be. > > Another problem only occurs on Windows package. I see it's > experimental phase for windows version currently, but it would receive > more result from wider regions if the local language packs were > included in Windows installer. Now it seems there is only English > language. > > Kind regards, > > Tommy He > > -- > Take a Deep Breath out of Windows > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarryson at gmail.com Fri Mar 26 16:19:15 2010 From: jarryson at gmail.com (=?UTF-8?B?5peg5Y+v5pWR6I2v?=) Date: Sat, 27 Mar 2010 00:19:15 +0800 Subject: [Shotwell] How about meet XDG standards, move config, cache, data dir to XDG dirs? Message-ID: <5ba146a11003260919i4f29a0cfpdf25c978ca064e5f@mail.gmail.com> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html instead of put all files into ~/.shotwell, put config files to $XDG_CONFIG_HOME/shotwell, cache files to $XDG_CACHE_HOME/shotwell, data files to $XDG_DATA_HOME/shotwell will be better. $XDG_CONFIG_HOME default is ~/.config $XDG_CACHE_HOME default is ~/.cache $XDG_DATA_HOME default is ~/.local/share it will make your $HOME dir clean, and easier for user to delete what the don't want, e.g. cache files. just delete ~/.cache, no need to find cache file in every application dirs. glib2 provide g_get_user_config_dir(), and python provide pyxdg, vala i don't know yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at yorba.org Fri Mar 26 21:54:14 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 26 Mar 2010 14:54:14 -0700 Subject: [Shotwell] Minor problems on shotwell website on Windows In-Reply-To: <8ed3c2d1003241600u188b4fc3g59cded35c658d3cd@mail.gmail.com> References: <8ed3c2d1003241600u188b4fc3g59cded35c658d3cd@mail.gmail.com> Message-ID: <4BAD2D06.4050400@yorba.org> An HTML attachment was scrubbed... URL: From adam at yorba.org Fri Mar 26 22:07:17 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 26 Mar 2010 15:07:17 -0700 Subject: [Shotwell] How about meet XDG standards, move config, cache, data dir to XDG dirs? In-Reply-To: <5ba146a11003260919i4f29a0cfpdf25c978ca064e5f@mail.gmail.com> References: <5ba146a11003260919i4f29a0cfpdf25c978ca064e5f@mail.gmail.com> Message-ID: <4BAD3015.2080402@yorba.org> An HTML attachment was scrubbed... URL: From peter.puk at gmail.com Sat Mar 27 22:17:33 2010 From: peter.puk at gmail.com (Peter Puk) Date: Sat, 27 Mar 2010 23:17:33 +0100 Subject: [Shotwell] Import to external harddisk Message-ID: <4BAE83FD.70807@gmail.com> My mother, currently switched to Ubuntu (9.10) uses F-Spot to manage her photo's. She uses an external harddrive to store all the photos. But F-spot is very slow with more then 5000 pictures and lacks the ability of deleting the imported photo's from the camera. Therefore i found shotwell as an alternative. While it works much faster, is saves the photo's to ~/Images. I couldn't find an option to import them on the harddrive, which is needed because the internal harddrive isn't big enough. Is there a possibility to import them to the external harddrive? Peter From adam at yorba.org Sat Mar 27 23:11:55 2010 From: adam at yorba.org (Adam Dingle) Date: Sat, 27 Mar 2010 16:11:55 -0700 Subject: [Shotwell] Import to external harddisk In-Reply-To: <4BAE83FD.70807@gmail.com> References: <4BAE83FD.70807@gmail.com> Message-ID: <7c6db8601003271611s3811ac6br25808f6cde32ef5@mail.gmail.com> Peter, Shotwell imports photos into the XDG pictures directory. By default this is ~/Pictures on most distributions, though from your email it sounds like on your distribution it is ~/Images. In any case, it is easy to change this. Simply edit ~/.config/user-dirs.dirs, find the line that specifies XDG_PICTURES_DIR and change it to any directory you like. You'll then need to restart Shotwell. In Shotwell 0.6, we may add a preference that allows the user to specify a directory to be used for importing other than the XDG pictures dir. Hope this helps! adam On Sat, Mar 27, 2010 at 3:17 PM, Peter Puk wrote: > My mother, currently switched to Ubuntu (9.10) uses F-Spot to manage her > photo's. She uses an external harddrive to store all the photos. But > F-spot is very slow with more then 5000 pictures and lacks the ability > of deleting the imported photo's from the camera. > > Therefore i found shotwell as an alternative. While it works much > faster, is saves the photo's to ~/Images. I couldn't find an option to > import them on the harddrive, which is needed because the internal > harddrive isn't big enough. > > Is there a possibility to import them to the external harddrive? > > Peter > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iluetkeb at techfak.uni-bielefeld.de Mon Mar 29 19:24:10 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Mon, 29 Mar 2010 21:24:10 +0200 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <4BA6C359.8080408@yorba.org> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <4BA67ACC.4040300@techfak.uni-bielefeld.de> <4BA6C359.8080408@yorba.org> Message-ID: <4BB0FE5A.6050602@techfak.uni-bielefeld.de> Hi Adam, sorry for the slow reply. Am 22.03.2010 02:09, schrieb Adam Dingle: > By a D-Bus API, do you mean an API that allows other processes to > control the running Shotwell instance via D-Bus, sending it commands > which are similar to Shotwell's menu commands (e.g. import, rotate, > publish and so on)? And by a REST API, do you mean a similar mechanism > in which Shotwell will listen for HTTP connections at some port and > respond to similar commands sent in REST style? Well, yes and no. I meant an API where Shotwell interacts over D-BUS/REST, but not to call menu functions but to interact with the photo database. Things such as "list photo collections" (which might return events), "give me the image of photo ", "give me the metadata", "store as the new metadata". Stuff like that. Sort of a local web-service for photo data-base access. You can see I specified those ops very REST-like which is because I am most familiar with that way of working, In a way, that would make Shotwell a service that makes available my photos to other apps in a coherent manner so that they, for example, share the tags or use the same organization for accessing photos. It would do so in a way that exposes the additional meta-data that Shotwell has over pure files. There might be other people working on similar things, e.g. the desktop search guys. > Do you see compelling use cases for an external D-Bus API rather than an > internal plugin-based one? If so, can you explain them a bit? I have two. Firstly, I find that with programs such as The GIMP, which follow the traditional plug-in model, the menus get cluttered immensely. I do not think that this model scales and for many things, you don't really need it. I would prefer several small tools that each do a particular job but share access to a common data collection. Of course, some people think that multiple tools are also clutter, but I find that you can aggregate easier than you can split up afterwards. Secondly, I thought that maybe the REST way of doing things would make it easier for you guys to get an API fast, because it is much simpler conceptually. Also, your implementation is encapsulated way more so that you can kick out an API now, without having to worry about compatibility later on. > For tags, captions and descriptions we've been thinking that we'd > implement import/export via IPTC/XMP metadata. When Shotwell imports > photos, it can read this metadata automatically That sounds cool. I wasn't sure whether IPTC had an XML representation but if it has, thats the way to go IMHO. Cheers, Ingo