From kbressl at gmail.com Sun Jan 1 14:03:42 2012 From: kbressl at gmail.com (Kirk Bressler) Date: Sun, 1 Jan 2012 08:03:42 -0600 Subject: [Shotwell] Seg Fault Message-ID: When attempting to import from F-Spot Shotwell segfaults. backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00000000005f2d0f in ?? () (gdb) backtrace #0 0x00000000005f2d0f in ?? () #1 0x00007ffff41c1a5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007ffff41c2258 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff41c2792 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007ffff5d57db7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #5 0x000000000068ba5c in application_start () #6 0x00000000005785f4 in library_exec () #7 0x00000000005798cf in _vala_main () #8 0x000000000047b641 in main () (gdb) I am running 11.10 64b Ubuntu on an AMD machine with 8gB of memory. Kirk From kbressl at gmail.com Sun Jan 1 14:08:29 2012 From: kbressl at gmail.com (Kirk Bressler) Date: Sun, 1 Jan 2012 08:08:29 -0600 Subject: [Shotwell] More info on segfault Message-ID: (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_parent: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_new_for_path: assertion `path != NULL' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_basename: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_child: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion `G_IS_FILE (file)' failed (shotwell:6826): GLib-CRITICAL **: g_utf8_collate: assertion `str1 != NULL' failed ETC...... From brunogirin at gmail.com Sun Jan 1 17:38:39 2012 From: brunogirin at gmail.com (Bruno Girin) Date: Sun, 01 Jan 2012 17:38:39 +0000 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: <4EEB9FD6.6080201@yorba.org> References: <4EE8FC3D.90407@cols.name> <4EEA6701.9080702@cols.name> <4EEB828C.6070406@yorba.org> <4EEB9E84.6010702@cols.name> <4EEB9FD6.6080201@yorba.org> Message-ID: <4F009A1F.3030402@gmail.com> Hi all, The main problem is that the F-Spot import feature loads the whole F-Spot database in memory and performs a single large batch import. So even if it was tuned, there would always be a possibility that a very large database would make it run out of memory. So the only way to fix this is to completely overhaul the code. The good news is that this code overhaul is happening right now. I've made good progress during the Christmas break on bug 3614 (http://redmine.yorba.org/issues/3614) to move the code to the SPIT architecture. As part of that work, I've changed the behaviour to avoid importing everything in one go. There are still a few rough edges but I should have a first patch for review in the next couple of weeks. At that point, it would be very useful to test the functionality on large databases to see if it actually fixes the problem. Cheers, Bruno On 16/12/11 19:45, Adam Dingle wrote: > Josep, > > thanks for the additional information - I've appended it to the ticket > for this bug (http://redmine.yorba.org/issues/4498). The best way to > continue discussion about this is by adding comments to that ticket. > That way, people who are interested in this issue can easily follow > the discussion. Thanks! > > adam > > On 12/16/2011 11:39 AM, Josep Cols wrote: >> Thanks, Adam. >> >> For your information: >> >> The lasts 2 imports (when 3.1 Gb of virtual memory is used) imported >> only 1.200 photos every import. >> I think the quatity of photos imported and/or the mount the memory >> used is due to the tags. >> >> I've about 10.000 tags at the last level and about 13.000 tags in >> total on the database. The low level tags has 3-5 levels. >> Every photo as a minimum of 6 tags and an average of 8-10 tags (and a >> maximum of 20 tags). >> >> Also, the photos are jpg from 10 OR 15 Mpixels camera (between 4 and >> 8 Mbytes each). >> >> If you need more information, I can run tests for you and/or install >> specific software for test pourposes, etc. >> >> Regards >> >> Al 16/12/11 18:40, En/na Adam Dingle ha escrit: >>> Josep, >>> >>> thanks for reporting this crash. As Lucas mentioned, we're already >>> aware of a potential crash that can result from F-Spot database >>> inconsistencies. But the other crash you described, where Shotwell >>> is using an enormous amount of memory, is new. I've created a >>> ticket for this here: >>> >>> http://redmine.yorba.org/issues/4498 >>> >>> We should investigate this for the upcoming 0.12 release. >>> >>> adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From patriciasantanacruz at gmail.com Mon Jan 2 10:05:44 2012 From: patriciasantanacruz at gmail.com (Patricia Santana Cruz) Date: Mon, 2 Jan 2012 10:05:44 +0000 Subject: [Shotwell] nautilus-sendto in Shotwell In-Reply-To: References: Message-ID: Hei Lucas! 2011/12/30 Lucas Beeler > Hi Patricia, > > Great to hear from you! I hope your holidays were splendid! > thanks for your reply! My holidays kind of turn into a moving back home. Now, I am leaving back in Gran Canaria :)))) FInally a bit more of sun! > > To answer your question, we developed our own "connectors" (this is > what Shotwell calls them) for Facebook, Flickr, etc., because at the > time we began development (mid-to-late 2009), nautilus-sendto had no > support for publishing to social web services. Furthermore, our > ultimate vision for the Shotwell web connectors is that they be > bidirectional (i.e., not only can you publish your photos from > Shotwell to Flickr but you can import a Flickr photoset into > Shotwell). In the longer term, we'd also like Shotwell to support > automatic cloud synchronization, so that when you adjust the color of > a photo in Shotwell, the colors of that photo are also adjusted > automatically in the published version of the photo on Flickr and > Facebook. With these requirements, nautilus-sendto is just too simple > a tool to support our needs. That said, if all you're going to be > doing is moving from photos from Cheese onto social websites, > nautilus-sendto may work great for you. > > Thanks for the explanation. All those ideas sound great and I can not wait to see them working! > I can't wait to see you at GUADEC next year! > See you there in a few months guys! Patricia. Lucas > From lucas at yorba.org Mon Jan 2 19:57:38 2012 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 2 Jan 2012 11:57:38 -0800 Subject: [Shotwell] More info on segfault In-Reply-To: References: Message-ID: Hi Kirk, It seems that you've burned by Shotwell Bug #4487 (http://redmine.yorba.org/issues/4487). It looks like what's happened here is that you've got a situation where your F-Spot database is malformed in a very specific way: there's an F-Spot database field that holds a string that represents the path to the actual photo file on disk (e.g., "/home/kirk/Pictures/DSCF001.JPG") and in one case in your database, that string is NULL. In an ideal world, this would never happen, because even if F-Spot can't find photo file on disk, it should still record its last-known path, so the path field in F-Spot's database would never be NULL. But, of course, we don't live in an ideal world... ;-) That said, Shotwell should never crash, no matter how malformed your F-Spot database is. You'll be happy to know that Bruno Girin, one of our top Shotwell contributors, is working on this problem and we hope to have it fixed in the next major release of Shotwell (0.12). Cheers, Lucas On Sun, Jan 1, 2012 at 6:08 AM, Kirk Bressler wrote: > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_parent: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_new_for_path: assertion `path > != NULL' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_basename: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_child: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion > `G_IS_FILE (file)' failed > > (shotwell:6826): GLib-CRITICAL **: g_utf8_collate: assertion `str1 != NULL' > failed > > > ETC...... > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From brunogirin at gmail.com Mon Jan 2 21:20:09 2012 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 02 Jan 2012 21:20:09 +0000 Subject: [Shotwell] More info on segfault In-Reply-To: References: Message-ID: <4F021F89.2030007@gmail.com> Hi Lucas, Kirk, Thanks for the detailed crash report. I replied on the ticket page, it's actually quite an easy one to fix, especially once ticket #3614 is merged. Looking at the comments in the code, it could happen with an F-Spot database that was upgraded from v0.4.x to v0.5+ (i.e. quite an old database). So having it fixed for 0.12 should not be a problem. Cheers, Bruno On 02/01/12 19:57, Lucas Beeler wrote: > Hi Kirk, > > It seems that you've burned by Shotwell Bug #4487 > (http://redmine.yorba.org/issues/4487). It looks like what's happened > here is that you've got a situation where your F-Spot database is > malformed in a very specific way: there's an F-Spot database field > that holds a string that represents the path to the actual photo file > on disk (e.g., "/home/kirk/Pictures/DSCF001.JPG") and in one case in > your database, that string is NULL. In an ideal world, this would > never happen, because even if F-Spot can't find photo file on disk, it > should still record its last-known path, so the path field in F-Spot's > database would never be NULL. But, of course, we don't live in an > ideal world... ;-) > > That said, Shotwell should never crash, no matter how malformed your > F-Spot database is. You'll be happy to know that Bruno Girin, one of > our top Shotwell contributors, is working on this problem and we hope > to have it fixed in the next major release of Shotwell (0.12). > > Cheers, > Lucas > > On Sun, Jan 1, 2012 at 6:08 AM, Kirk Bressler wrote: >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_parent: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_new_for_path: assertion `path >> != NULL' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_basename: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_child: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-GIO-CRITICAL **: g_file_get_path: assertion >> `G_IS_FILE (file)' failed >> >> (shotwell:6826): GLib-CRITICAL **: g_utf8_collate: assertion `str1 != NULL' >> failed >> >> >> ETC...... >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From dougie at highmoor.co.uk Mon Jan 2 23:14:14 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 02 Jan 2012 23:14:14 +0000 Subject: [Shotwell] bulk delete aborts if one filename is too long Message-ID: <4F023A46.8090802@highmoor.co.uk> During some bulk tidying-up I found myself wanting to delete 2000+ images from Shotwell. I mean, really delete them. Just delete them. Having selected them all and hit Shift-Del + Move to Wastebasket, I found the process failing when it hit a file that was too long to delete. e.g. L 31611 2012-01-02 22:46:16 [MSG] MediaDataRepresentation.vala:105: Unable to move original photo /images/2011/08/15/White-letter Hairstreak Survey -- Hardwick Dene -- Pieris rapae (Pieridae) (Small White or Small Cabbage White) -- tentative_ident -- (United Kingdom - England - Bishopsgarth and Elm Tree Ward - Stockton-on-Tees) -- Mon 15 Aug 2011 11-21-15 BST.jpg to trash: Unable to create wastebasket info file: File name too long Two points. 1. When I get the error (I think it's something like "Unable to move to Wastebasket, delete anyway?" - I select YES, and the entire process stops. It's only by looking at the logfile I realise that the problem is caused by the filename being too long. I think shotwell could handle this a bit more gracefully - there's no reason to abort the batch delete just because there's a problem with one file. 2. Couldn't shotwell just delete it? Must it go to a wastebasket, which I'm then going to locate and empty anyway? I grow weary of programs trying to hold my hand and protect me from myself. I expect it in Microsoft but one of my reasons for preferring Linux is the lack of seatbelts. The ability to do things quickly and efficiently. Perhaps it could be done as an option? Dougie From michiel.detailleur at gmail.com Wed Jan 4 21:37:59 2012 From: michiel.detailleur at gmail.com (Michiel Detailleur) Date: Wed, 04 Jan 2012 22:37:59 +0100 Subject: [Shotwell] Filter on tag but exclude child tags Message-ID: <4F04C6B7.5070105@gmail.com> Hi, I just moved from F-Spot to Shotwell (import went ok, with 2 small hickups which I will describe in another message). I really like the speed of Shotwell, a big improvement on F-Spot! However (there always is one isn't it ;) ): I would like to be able to filter on tags like I could in F-Spot. In F-Spot, tags are hierarchical, but not quite like Shotwell implements it. For example, consider the following, very imaginative, tag hierarchy: Parent \-> Child A \-> Grand Child \-> Child B Photos tagged with 'Child A' do not automatically obtain the tag 'Parent'. So if you filter on Parent, you don't automatically get the photos tagged 'Child A' or 'Child B' or 'Grand Child', unless those photos are also explicitly tagged with 'Parent'. Shotwells implementation differs from this (child tags automatically obtain the parent tags). That's not particularly good or bad, if however Shotwell would also make it possible to filter like F-Spot does: filter all photos tagged with 'Parent' and only 'Parent', meaning: exclude all photos tagged with 'Child A/B' or 'Grand Child'. This is handy for numerous reasons. For example when you started out with just a 'Family' tag a while ago and now you want to make that a bit more specific, so you start tagging a bunch of 'Dad' and 'Mom' photos within the 'Family' photos. And now you want to search for your brother 'John' and start tagging him, but you don't want to go through the whole bunch of photos already tagged with 'Dad' and 'Mom' within 'Family'. Any chance this could be made possible? I don't know anything about Shotwells implementation, but it would seam that making this available via the Saved Search feature is within reason? Thanks, Michiel From michiel.detailleur at gmail.com Wed Jan 4 21:52:11 2012 From: michiel.detailleur at gmail.com (Michiel Detailleur) Date: Wed, 04 Jan 2012 22:52:11 +0100 Subject: [Shotwell] 3 small F-Spot import hickups, version 0.11.6 Message-ID: <4F04CA0B.20807@gmail.com> Ok, so as I said in my previous message, I had 2 small F-Spot import hickups, well, actually 3 now that I think of it: * Shotwell used to crash badly (with ugliness at the terminal) at earlier attempts of importing my F-Spot library. But I think I found the cause: I had a tag in F-Spot with a / in it. I replaced the / with a & and tried again and BAM, I got a whole lot further in the import (but not till the end, see below)! So I'm not 100% sure if this was due to the removing of the / or because of my Shotwell version got updated in the meantime, but maybe this is worth checking out? I know Shotwell doesn't allow creating tags with / in it itself, but maybe it doesn't check for them during import from other software? * Further along, Shotwell crashed during import, without a message in GUI or terminal. I'm sorry, I can't give you anything more on this. I think it was due to memory shortage as others have reported here (which would explain the lack of messages, if it got killed by the kernel). Luckily I could restart Shotwell, see that it had already imported a whole bunch of photos and start importing again. Shotwell succesfully added the remaining photos (while detecting the photos it had already imported). * Tags were still imported in hierarchical *and flat* form. So I manually removed all flat tags. Luckily I don't have that many. That's all! Michiel From brunogirin at gmail.com Wed Jan 4 22:14:53 2012 From: brunogirin at gmail.com (Bruno Girin) Date: Wed, 04 Jan 2012 22:14:53 +0000 Subject: [Shotwell] 3 small F-Spot import hickups, version 0.11.6 In-Reply-To: <4F04CA0B.20807@gmail.com> References: <4F04CA0B.20807@gmail.com> Message-ID: <4F04CF5D.4020909@gmail.com> On 04/01/12 21:52, Michiel Detailleur wrote: > Ok, so as I said in my previous message, I had 2 small F-Spot import > hickups, well, actually 3 now that I think of it: > > * Shotwell used to crash badly (with ugliness at the terminal) at > earlier attempts of importing my F-Spot library. But I think I found > the cause: I had a tag in F-Spot with a / in it. I replaced the / with > a & and tried again and BAM, I got a whole lot further in the import > (but not till the end, see below)! > So I'm not 100% sure if this was due to the removing of the / or > because of my Shotwell version got updated in the meantime, but maybe > this is worth checking out? I know Shotwell doesn't allow creating > tags with / in it itself, but maybe it doesn't check for them during > import from other software? That probably falls under ticket 4487 (http://redmine.yorba.org/issues/4487). I can see why a / character would make it fail. I'll try to reproduce with a small database to see what it does. > * Further along, Shotwell crashed during import, without a message in > GUI or terminal. I'm sorry, I can't give you anything more on this. I > think it was due to memory shortage as others have reported here > (which would explain the lack of messages, if it got killed by the > kernel). Luckily I could restart Shotwell, see that it had already > imported a whole bunch of photos and start importing again. Shotwell > succesfully added the remaining photos (while detecting the photos it > had already imported). That would be defect 4498 (http://redmine.yorba.org/issues/4498). I am currently working on migrating the F-Spot import code to the SPIT architecture (see http://redmine.yorba.org/issues/3614) and I'm hoping that we can address that issue in the refactoring. > * Tags were still imported in hierarchical *and flat* form. So I > manually removed all flat tags. Luckily I don't have that many. Some work was done on this as part of defect 4081 (http://redmine.yorba.org/issues/4081) but it seems that the issue still exists somewhat. From what I understand, this can happen when tags are also stored in the image file as IPTC or XMP meta-data so they may get imported twice: hierarchically via F-Spot, flat via the IPTC / XMP meta-data. Any photo file and details of how it's tagged in F-Spot would help a lot in narrowing down this issue. Thanks for the issue report! Cheers, Bruno From dougie at highmoor.co.uk Wed Jan 4 22:39:01 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 04 Jan 2012 22:39:01 +0000 Subject: [Shotwell] Filter on tag but exclude child tags In-Reply-To: <4F04C6B7.5070105@gmail.com> References: <4F04C6B7.5070105@gmail.com> Message-ID: <4F04D505.4070100@highmoor.co.uk> On 04/01/2012 21:37, Michiel Detailleur wrote: > [ ... ] > > However (there always is one isn't it ;) ): I would like to be able to > filter on tags like I could in F-Spot. In F-Spot, tags are > hierarchical, but not quite like Shotwell implements it. > > For example, consider the following, very imaginative, tag hierarchy: > > Parent > \-> Child A > \-> Grand Child > \-> Child B > > Photos tagged with 'Child A' do not automatically obtain the tag > 'Parent'. So if you filter on Parent, you don't automatically get the > photos tagged 'Child A' or 'Child B' or 'Grand Child', unless those > photos are also explicitly tagged with 'Parent'. > > Shotwells implementation differs from this (child tags automatically > obtain the parent tags). That's not particularly good or bad, if > however Shotwell would also make it possible to filter like F-Spot > does: filter all photos tagged with 'Parent' and only 'Parent', > meaning: exclude all photos tagged with 'Child A/B' or 'Grand Child'. > This is handy for numerous reasons. This makes fascinating reading for me as I noticed exactly the same thing migrating from f-spot to shotwell. For me the problems are slightly different as I've got into a routine of renaming images based on their tags. In f-spot, when I noticed that only the terminal-child tag was written as meta-data to the image I sometimes had to compensate for it, as I *wanted* some of the parent tags in the filenames. I examined what f-shot physically wrote to the file and wrote my rename-script accordingly (http://www.bluecedar.org.uk/?p=143). However after migrating to shotwell I've discovered, as you have, that the child tags inherit the parent tags, and if 'write metadata to file' is checked, then an image file can have an awful lot of tags. This means my rename script often gives filenames that are, 1. Too long, and 2. Have unhelpful tags in the name (e.g. 'location', and 'Family'). I have to say though, that I think shotwell have got it right, and f-spot had it wrong. For me anyway, it makes far more logical sense for the child tags to inherit the parent tags, even if it does cause me a bit of short-term hassle. Dougie From dougie at highmoor.co.uk Wed Jan 4 22:47:53 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 04 Jan 2012 22:47:53 +0000 Subject: [Shotwell] Filter on tag but exclude child tags In-Reply-To: <4F04C6B7.5070105@gmail.com> References: <4F04C6B7.5070105@gmail.com> Message-ID: <4F04D719.6000000@highmoor.co.uk> On 04/01/2012 21:37, Michiel Detailleur wrote: > [ ... ] > > Photos tagged with 'Child A' do not automatically obtain the tag > 'Parent'. So if you filter on Parent, you don't automatically get the > photos tagged 'Child A' or 'Child B' or 'Grand Child', unless those > photos are also explicitly tagged with 'Parent'. > In all the time I used f-spot I could never figure out whether this was a bug or a feature! From adam at yorba.org Wed Jan 4 23:32:00 2012 From: adam at yorba.org (Adam Dingle) Date: Wed, 04 Jan 2012 15:32:00 -0800 Subject: [Shotwell] Filter on tag but exclude child tags In-Reply-To: <4F04C6B7.5070105@gmail.com> References: <4F04C6B7.5070105@gmail.com> Message-ID: <4F04E170.6010804@yorba.org> On 01/04/2012 01:37 PM, Michiel Detailleur wrote: > Hi, > > I just moved from F-Spot to Shotwell (import went ok, with 2 small > hickups which I will describe in another message). > > I really like the speed of Shotwell, a big improvement on F-Spot! > > However (there always is one isn't it ;) ): I would like to be able to > filter on tags like I could in F-Spot. In F-Spot, tags are > hierarchical, but not quite like Shotwell implements it. > > For example, consider the following, very imaginative, tag hierarchy: > > Parent > \-> Child A > \-> Grand Child > \-> Child B > > Photos tagged with 'Child A' do not automatically obtain the tag > 'Parent'. So if you filter on Parent, you don't automatically get the > photos tagged 'Child A' or 'Child B' or 'Grand Child', unless those > photos are also explicitly tagged with 'Parent'. > > Shotwells implementation differs from this (child tags automatically > obtain the parent tags). That's not particularly good or bad, if > however Shotwell would also make it possible to filter like F-Spot > does: filter all photos tagged with 'Parent' and only 'Parent', > meaning: exclude all photos tagged with 'Child A/B' or 'Grand Child'. > This is handy for numerous reasons. For example when you started out > with just a 'Family' tag a while ago and now you want to make that a > bit more specific, so you start tagging a bunch of 'Dad' and 'Mom' > photos within the 'Family' photos. And now you want to search for your > brother 'John' and start tagging him, but you don't want to go through > the whole bunch of photos already tagged with 'Dad' and 'Mom' within > 'Family'. > > Any chance this could be made possible? I don't know anything about > Shotwells implementation, but it would seam that making this available > via the Saved Search feature is within reason? Shotwell should let you do this via a Boolean search: you should be able to search for all photos tagged with 'Family', but not with 'Dad' or 'Mom'. Unfortunately it's not currently possible to search for all photos which are not tagged with a particular tag: http://redmine.yorba.org/issues/3659 Once that is fixed I think a Boolean search should do the trick. We could consider adding an additional search operator which matches only a given tag (not parent tags). It might be a little tricky to come up for a name for that operator which would be clear, since we already have an operator "is exactly", which means an exact string match. Feel free to file a ticket for an additional operator like this and propose how it would look in the user interface. adam From adam at yorba.org Wed Jan 4 23:42:09 2012 From: adam at yorba.org (Adam Dingle) Date: Wed, 04 Jan 2012 15:42:09 -0800 Subject: [Shotwell] bulk delete aborts if one filename is too long In-Reply-To: <4F023A46.8090802@highmoor.co.uk> References: <4F023A46.8090802@highmoor.co.uk> Message-ID: <4F04E3D1.70804@yorba.org> On 01/02/2012 03:14 PM, Dougie Nisbet wrote: > During some bulk tidying-up I found myself wanting to delete 2000+ > images from Shotwell. I mean, really delete them. Just delete them. > Having selected them all and hit Shift-Del + Move to Wastebasket, I > found the process failing when it hit a file that was too long to > delete. e.g. > > L 31611 2012-01-02 22:46:16 [MSG] MediaDataRepresentation.vala:105: > Unable to move original photo /images/2011/08/15/White-letter > Hairstreak Survey -- Hardwick Dene -- Pieris rapae (Pieridae) (Small > White or Small Cabbage White) -- tentative_ident -- (United Kingdom - > England - Bishopsgarth and Elm Tree Ward - Stockton-on-Tees) -- Mon 15 > Aug 2011 11-21-15 BST.jpg to trash: Unable to create wastebasket info > file: File name too long > > Two points. > > 1. When I get the error (I think it's something like "Unable to move > to Wastebasket, delete anyway?" - I select YES, and the entire process > stops. It's only by looking at the logfile I realise that the problem > is caused by the filename being too long. I think shotwell could > handle this a bit more gracefully - there's no reason to abort the > batch delete just because there's a problem with one file. You're right: this is a bug. We've ticketed this at http://redmine.yorba.org/issues/4555 . > > 2. Couldn't shotwell just delete it? Must it go to a wastebasket, > which I'm then going to locate and empty anyway? I grow weary of > programs trying to hold my hand and protect me from myself. I expect > it in Microsoft but one of my reasons for preferring Linux is the lack > of seatbelts. The ability to do things quickly and efficiently. > Perhaps it could be done as an option? The essential problem here is that there are several possibilities and it's tricky to design a nice user interface which offers the user any of the following: 1. Move to the Shotwell trash. 2. Remove from the library, while leaving the file in place. 3. Remove from the library and move the file to the desktop trash. 4. Remove from the library and delete the file outright. As a compromise, Shotwell currently lets the user perform operations 1-3 but not 4. If you have a concrete suggestion about how we could add possibility 4 without cluttering the user interface, we could consider it. I think a good solution to this problem could be to unify the Shotwell and desktop trashes (http://redmine.yorba.org/issues/2645); that would reduce the set of options we need to offer the user. adam From dougie at highmoor.co.uk Thu Jan 5 08:42:11 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 05 Jan 2012 08:42:11 +0000 Subject: [Shotwell] bulk delete aborts if one filename is too long In-Reply-To: <4F04E3D1.70804@yorba.org> References: <4F023A46.8090802@highmoor.co.uk> <4F04E3D1.70804@yorba.org> Message-ID: <4F056263.7010800@highmoor.co.uk> On 04/01/2012 23:42, Adam Dingle wrote: > > The essential problem here is that there are several possibilities and > it's tricky to design a nice user interface which offers the user any > of the following: > > 1. Move to the Shotwell trash. > 2. Remove from the library, while leaving the file in place. > 3. Remove from the library and move the file to the desktop trash. > 4. Remove from the library and delete the file outright. > > As a compromise, Shotwell currently lets the user perform operations > 1-3 but not 4. If you have a concrete suggestion about how we could > add possibility 4 without cluttering the user interface, we could > consider it. > I guess it's a bit of an old-school thing too. Coming from a pre-GUI Linux environment I'm still not used to the idea of having a Desktop Wastebasket and have never found it useful. Even now I always have to read the dialogue twice after Shift-Delete to make sure it's about to do what I expect it to do. > I think a good solution to this problem could be to unify the Shotwell > and desktop trashes (http://redmine.yorba.org/issues/2645); that would > reduce the set of options we need to offer the user. I still like the idea of a 'real delete' although I accept the philosophy that shotwell should manage photos, not files. Dougie From dougie at highmoor.co.uk Thu Jan 5 08:45:39 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 05 Jan 2012 08:45:39 +0000 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View Message-ID: <4F056333.6060405@highmoor.co.uk> Not sure if this is a bug. I noticed that a few photos in my Event View for Mon 8 Sep 2003 were misdated, and should be in 9 Aug 2003. So I selected them and adjusted the date. As soon as I did this, *all* the photos in 8 Sep 2003 were moved to 9 Aug 2003. To test, I did an Undo, then selected a single image and Adjusted the date again. Once more, all the 103 photos in 8 Sep were recategorised into 9 Aug 2003. There may be something else going on here, such as malformed exif data in the images concerned. Interested to know if it's just me, and will do a few more exhaustive tests as and when required. Dougie From insomniacpenguin at googlemail.com Thu Jan 5 09:11:17 2012 From: insomniacpenguin at googlemail.com (Andy Stevens) Date: Thu, 5 Jan 2012 09:11:17 +0000 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View In-Reply-To: <4F056333.6060405@highmoor.co.uk> References: <4F056333.6060405@highmoor.co.uk> Message-ID: I recall some discussion on the list a while ago about having event "dates" (which are really just text labels) be updated automatically when their photos have their dates changed. Sounds to me like someone forgot to consider the case that you might not always want to adjust the date of all the photos in an event, and therefore need to split it... It seems to me that things would be a lot less confusing if events were handled more like tags with long names, and we had a separate timeline view and/or hierarchy based solely on the photos' actual dates. Or would that be too much like F-Spot? :-) Andy. On 5 Jan 2012 08:45, "Dougie Nisbet" wrote: > Not sure if this is a bug. > > I noticed that a few photos in my Event View for Mon 8 Sep 2003 were > misdated, and should be in 9 Aug 2003. So I selected them and adjusted the > date. As soon as I did this, *all* the photos in 8 Sep 2003 were moved to 9 > Aug 2003. > > To test, I did an Undo, then selected a single image and Adjusted the date > again. Once more, all the 103 photos in 8 Sep were recategorised into 9 Aug > 2003. > > There may be something else going on here, such as malformed exif data in > the images concerned. Interested to know if it's just me, and will do a few > more exhaustive tests as and when required. > > Dougie > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From r.m.krug at gmail.com Thu Jan 5 09:26:53 2012 From: r.m.krug at gmail.com (Rainer M Krug) Date: Thu, 05 Jan 2012 10:26:53 +0100 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View In-Reply-To: References: <4F056333.6060405@highmoor.co.uk> Message-ID: <4F056CDD.4040508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/01/12 10:11, Andy Stevens wrote: > I recall some discussion on the list a while ago about having event > "dates" (which are really just text labels) be updated > automatically when their photos have their dates changed. Sounds > to me like someone forgot to consider the case that you might not > always want to adjust the date of all the photos in an event, and > therefore need to split it... > > It seems to me that things would be a lot less confusing if events > were handled more like tags with long names, and we had a separate > timeline view and/or hierarchy based solely on the photos' actual > dates. I just started using shotwell, but the separation of tags and events is indeed confusing - why have events if you could have tags with a certain format, e.g."#@!EVENT!@#" and a display which sorts by using these tags? This would also allow: 1) multiple events 2) subevents (e.g. Marriage - reception - church - evening - ... and 3) these events would be stored in the image and available for other programs as well. A timeline view based on the actual photos actual dates would be very useful. Cheers, Rainer > Or would that be too much like F-Spot? :-) > > Andy. On 5 Jan 2012 08:45, "Dougie Nisbet" > wrote: > >> Not sure if this is a bug. >> >> I noticed that a few photos in my Event View for Mon 8 Sep 2003 >> were misdated, and should be in 9 Aug 2003. So I selected them >> and adjusted the date. As soon as I did this, *all* the photos in >> 8 Sep 2003 were moved to 9 Aug 2003. >> >> To test, I did an Undo, then selected a single image and Adjusted >> the date again. Once more, all the 103 photos in 8 Sep were >> recategorised into 9 Aug 2003. >> >> There may be something else going on here, such as malformed exif >> data in the images concerned. Interested to know if it's just me, >> and will do a few more exhaustive tests as and when required. >> >> Dougie >> >> ______________________________**_________________ Shotwell >> mailing list Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell >> > >> _______________________________________________ > Shotwell mailing list Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer at krugs.de Skype: RMkrug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8FbN0ACgkQoYgNqgF2egp8YQCdG0IIYGckfqCvZyWzD3LSAmoe a2kAnRhcwuR8ofNKydaqtIifbMpwzwxn =Xcrs -----END PGP SIGNATURE----- From jcdubacq1 at free.fr Thu Jan 5 09:59:30 2012 From: jcdubacq1 at free.fr (Jean-Christophe Dubacq) Date: Thu, 05 Jan 2012 10:59:30 +0100 Subject: [Shotwell] Event tags In-Reply-To: <4DE32EA1.5030109@free.fr> References: <4DE32EA1.5030109@free.fr> Message-ID: <4F057482.2090806@free.fr> On 30/05/2011 07:44, Jean-Christophe Dubacq wrote: > Hi, > > I began using shotwell three months ago. Before mass-importing my > pictures (all the way from 2005), I pondered whether this could be a > fine addition to have "Event tags" > > Event tags are tags that apply to the whole event and complement the > normal picture (and soon region) tags. Selecting events tags would allow > to restrict the > > What do people think of it? I did not find it in the request list (but I > may have been a bit too quick; subjects are sometimes terse). > > This may be related to #1586. Hello, I finally reported a feature request about this as Feature #4557. http://redmine.yorba.org/issues/4557 Sincerly, -- Jean-Christophe Dubacq From thomas at xyz.pp.se Thu Jan 5 11:06:47 2012 From: thomas at xyz.pp.se (Thomas Novin) Date: Thu, 05 Jan 2012 12:06:47 +0100 Subject: [Shotwell] Rotating an image Message-ID: <4F058447.4010309@xyz.pp.se> Hello If I from Shotwell rotate an image, it seems the rotate is only done in the Shotwell database, ie. how the image is presented when viewed. I would like the original image to be changed so this is permanent even if not using Shotwell to view the image. Is this possible? Rgds//Thomas From adam at yorba.org Thu Jan 5 15:43:03 2012 From: adam at yorba.org (Adam Dingle) Date: Thu, 05 Jan 2012 07:43:03 -0800 Subject: [Shotwell] Filter on tag but exclude child tags In-Reply-To: References: <4F04C6B7.5070105@gmail.com> <4F04E170.6010804@yorba.org> Message-ID: <4F05C507.7030204@yorba.org> On 01/04/2012 06:32 PM, Noah Beck wrote: > On Wed, Jan 4, 2012 at 6:32 PM, Adam Dingle > wrote: > > Shotwell should let you do this via a Boolean search: you should > be able to search for all photos tagged with 'Family', but not > with 'Dad' or 'Mom'. Unfortunately it's not currently possible to > search for all photos which are not tagged with a particular tag: > > http://redmine.yorba.org/issues/3659 > > Once that is fixed I think a Boolean search should do the trick. > > We could consider adding an additional search operator which > matches only a given tag (not parent tags). It might be a little > tricky to come up for a name for that operator which would be > clear, since we already have an operator "is exactly", which means > an exact string match. Feel free to file a ticket for an > additional operator like this and propose how it would look in the > user interface. > > > Boolean search would be great. From the GUI perspective, when you > select a tag, you get all the images that have that tag. I've thought > it would be really handy if you could shift-select or crtl-select > another tag, and have images with those tags excluded from the image > set. That works well with the original poster's problem; he could > select 'Parent' and then exclude-select 'Child A' and exclude-select > 'Child B'. Well, we actually intend to let the user select multiple tags but with a different meaning, namely the intersection (AND) of all the selected tags: http://redmine.yorba.org/issues/2275 With your proposal, it's not clear which tag would be included and which would be excluded. I suppose you could say that the first tag selected would be included and others would be excluded, but I think that wouldn't be obvious at all. adam From insomniacpenguin at googlemail.com Thu Jan 5 17:46:12 2012 From: insomniacpenguin at googlemail.com (Andy Stevens) Date: Thu, 5 Jan 2012 17:46:12 +0000 Subject: [Shotwell] Rotating an image In-Reply-To: <4F058447.4010309@xyz.pp.se> References: <4F058447.4010309@xyz.pp.se> Message-ID: Unless I'm mistaken, if you've got the "save metadata to files" setting enabled, then rotating the photo should update the exif Rotation value i.e. it should indeed be "permanent". Whether any specific other application will pay attention to this like it's supposed to, I couldn't say. But if they don't, that's cause for a bug report to the other app rather than an enhancement request to shotwell in my opinion ;-) Andy. On 5 Jan 2012 11:06, "Thomas Novin" wrote: > Hello > > If I from Shotwell rotate an image, it seems the rotate is only done in > the Shotwell database, ie. how the image is presented when viewed. > > I would like the original image to be changed so this is permanent even if > not using Shotwell to view the image. > > Is this possible? > > Rgds//Thomas > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From chrisgame at pobox.com Thu Jan 5 18:05:02 2012 From: chrisgame at pobox.com (Chris Game) Date: Thu, 5 Jan 2012 18:05:02 +0000 (GMT Standard Time) Subject: [Shotwell] Filter on tag but exclude child tags In-Reply-To: References: Message-ID: >> Parent >> \-> Child A >> \-> Grand Child >> \-> Child B This is obviously a heirarchy which will lead to problems. Parents do *not* include their children! The top-level tag for a family would be 'Wilson Family' or for Windows users 'My Family' :-) And children typically have at least two parents (and maybe step-parents). A search on 'Child *' should pull in all those tagged 'Child *' but no Parents or Grand-child photos. If you search a particular tag, you shouldn't get parent tags or child tags included. If I want photos of a particular parent, why would I want their children as well? I can see the case for an inclusive 'My Family' tag but more than one layer under that will cause problems in search/filtering. All this implies it's *much* easier to stick to one level of tags! Regds, Chris. From laura at yorba.org Thu Jan 5 19:28:06 2012 From: laura at yorba.org (Laura Khalil) Date: Thu, 5 Jan 2012 11:28:06 -0800 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View In-Reply-To: <4F056333.6060405@highmoor.co.uk> References: <4F056333.6060405@highmoor.co.uk> Message-ID: Hey Dougie, Let's try and figure this out. Couple questions: What version of Shotwell are you running? What exactly are you seeing on the screen to suggest that all the photos from 8 Sep 2003 are being moved to 9 Aug 2003? Cheers, Laura On Thu, Jan 5, 2012 at 12:45 AM, Dougie Nisbet wrote: > Not sure if this is a bug. > > I noticed that a few photos in my Event View for Mon 8 Sep 2003 were > misdated, and should be in 9 Aug 2003. So I selected them and adjusted the > date. As soon as I did this, *all* the photos in 8 Sep 2003 were moved to 9 > Aug 2003. > > To test, I did an Undo, then selected a single image and Adjusted the date > again. Once more, all the 103 photos in 8 Sep were recategorised into 9 Aug > 2003. > > There may be something else going on here, such as malformed exif data in > the images concerned. Interested to know if it's just me, and will do a few > more exhaustive tests as and when required. > > Dougie > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Thu Jan 5 20:24:21 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 05 Jan 2012 20:24:21 +0000 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View In-Reply-To: References: <4F056333.6060405@highmoor.co.uk> Message-ID: <4F0606F5.3020502@highmoor.co.uk> On 05/01/2012 19:28, Laura Khalil wrote: > Hey Dougie, > > Let's try and figure this out. Couple questions: > > What version of Shotwell are you running? > What exactly are you seeing on the screen to suggest that all the > photos from 8 Sep 2003 are being moved to 9 Aug 2003? > ah, right, I think I see what's going on now. If I'm right, shotwell is treating each event date as an indivisible entity. It so happens that a few of the photographs in the event have the wrong date, and when I adjust them, shotwell is keeping the group of photos intact, and assigning a *date range*. I hadn't noticed this the first time I tried it. In this example I select 4 images and adjust the date to 9th Aug 2003, and the event is renamed to correspond to the new date range for the event. http://www.fellandforest.co.uk/p326476854/e1640a8a6 I suppose a workaround would be to export the images from shotwell then adjust the dates using exiftool or exiv2 or similar, then re-import. Dougie PS: version 0.11.6 From laura at yorba.org Thu Jan 5 22:49:54 2012 From: laura at yorba.org (Laura Khalil) Date: Thu, 5 Jan 2012 14:49:54 -0800 Subject: [Shotwell] Strange behaviour when Adjusting Date in Event View In-Reply-To: <4F0606F5.3020502@highmoor.co.uk> References: <4F056333.6060405@highmoor.co.uk> <4F0606F5.3020502@highmoor.co.uk> Message-ID: > > ah, right, I think I see what's going on now. > > If I'm right, shotwell is treating each event date as an indivisible > entity. It so happens that a few of the photographs in the event have the > wrong date, and when I adjust them, shotwell is keeping the group of photos > intact, and assigning a *date range*. I hadn't noticed this the first time > I tried it. > Right. The dates of all your photos aren't changing, but the name of the event has been modified to reflect that there are photos from both 9 Aug 2003 and 8 Sept 2003. Event names in Shotwell can cause some confusion. There are a couple feature requests open in that regard: 3549and 2108 . Cheers, Laura From stimberg at users.sourceforge.net Fri Jan 6 12:46:07 2012 From: stimberg at users.sourceforge.net (Marcel Stimberg) Date: Fri, 6 Jan 2012 13:46:07 +0100 Subject: [Shotwell] Rotating an image In-Reply-To: References: <4F058447.4010309@xyz.pp.se> Message-ID: Hi, > Unless I'm mistaken, if you've got the "save metadata to files" setting > enabled, then rotating the photo should update the exif Rotation value i.e. > it should indeed be "permanent". It seems there is a problem with this currently: http://redmine.yorba.org/issues/4239 > Whether any specific other application > will pay attention to this like it's supposed to, I couldn't say. But if > they don't, that's cause for a bug report to the other app rather than an > enhancement request to shotwell in my opinion ;-) Many applications take the flag into account but unfortunately not all (at least for Ubuntu there are a couple of bug reports for such applications already). Shotwell has a ticket about being able to optionally "physically" rotate the image so that all applications display it correctly: http://redmine.yorba.org/issues/2581 Best Marcel From r.m.krug at gmail.com Fri Jan 6 12:48:45 2012 From: r.m.krug at gmail.com (Rainer M Krug) Date: Fri, 06 Jan 2012 13:48:45 +0100 Subject: [Shotwell] Rotating an image In-Reply-To: References: <4F058447.4010309@xyz.pp.se> Message-ID: <4F06EDAD.2090809@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/12 13:46, Marcel Stimberg wrote: > Hi, > >> Unless I'm mistaken, if you've got the "save metadata to files" >> setting enabled, then rotating the photo should update the exif >> Rotation value i.e. it should indeed be "permanent". > It seems there is a problem with this currently: > http://redmine.yorba.org/issues/4239 > >> Whether any specific other application will pay attention to this >> like it's supposed to, I couldn't say. But if they don't, that's >> cause for a bug report to the other app rather than an >> enhancement request to shotwell in my opinion ;-) > Many applications take the flag into account but unfortunately not > all (at least for Ubuntu there are a couple of bug reports for > such applications already). Shotwell has a ticket about being able > to optionally "physically" rotate the image so that all > applications display it correctly: > http://redmine.yorba.org/issues/2581 That would be a good idea - but please use in the jpeg case losless rotation. Rainer > > Best Marcel _______________________________________________ > Shotwell mailing list Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer at krugs.de Skype: RMkrug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8G7a0ACgkQoYgNqgF2egogtQCgiBtIfli3SaJAiuts9Wiy0f0d rU4AnA8YdQB5y0soao5EcvMcW1mwyb4L =8qbT -----END PGP SIGNATURE----- From rstanley at rsiny.com Fri Jan 6 20:27:02 2012 From: rstanley at rsiny.com (rstanley) Date: Fri, 6 Jan 2012 12:27:02 -0800 (PST) Subject: [Shotwell] Images not removed from camera after import Message-ID: <1325881622918-51858.post@talk.nabble.com> Hello! I am using Shotwell, version 0.11.6, on Debian Testing, fully updated. My camera is a Sony, Cyber-Shot DSC-WX9. After importing the images from the camera, I am presented with an option to remove the images from the camera. Clicking on "Delete" will not remove the images from the camera. I have to do this on the camera after disconnecting from the computer. I assume that different cameras use different commands that need to be sent from Shotwell. Please make whatever adjustment needed. If I am incorrect, please advise if I need to make any changes to Shotwell, or the camera. Thanks! Rick -- View this message in context: http://shotwell.3510.www.nabble.com/Images-not-removed-from-camera-after-import-tp51858p51858.html Sent from the Shotwell mailing list archive at Nabble.com. From adam at yorba.org Sat Jan 7 00:52:23 2012 From: adam at yorba.org (Adam Dingle) Date: Fri, 06 Jan 2012 16:52:23 -0800 Subject: [Shotwell] Fwd: [recipe build #150681] of ~yorba shotwell-daily-build in oneiric: Failed to upload In-Reply-To: <20120107000516.12873.32720.launchpad@cesium.canonical.com> References: <20120107000516.12873.32720.launchpad@cesium.canonical.com> Message-ID: <4F079747.1050705@yorba.org> Eric, it looks like the Shotwell daily build is still broken. I thought you had fixed this - am I wrong? -------- Original Message -------- Subject: [recipe build #150681] of ~yorba shotwell-daily-build in oneiric: Failed to upload Date: Sat, 07 Jan 2012 00:05:16 -0000 From: noreply at launchpad.net Reply-To: noreply at launchpad.net To: Adam Dingle * State: Failed to upload * Recipe: yorba/shotwell-daily-build * Archive: yorba/daily-builds * Distroseries: oneiric * Duration: 4 minutes * Build Log: https://launchpadlibrarian.net/89264880/buildlog.txt.gz * Upload Log: https://launchpad.net/~yorba/+archive/daily-builds/+recipebuild/150681/+files/upload_3241957_log.txt * Builder: https://launchpad.net/builders/nannyberry -- https://launchpad.net/~yorba/+archive/daily-builds/+recipebuild/150681 Your team Yorba is the requester of the build. From okeefe at cybermesa.com Sat Jan 7 22:47:05 2012 From: okeefe at cybermesa.com (BrianO'Keefe) Date: Sat, 07 Jan 2012 15:47:05 -0700 Subject: [Shotwell] Not importing certain pics Message-ID: <4F08CB69.2040000@cybermesa.com> I've imported photos to the correct directory, in my case /Home/me/Pictures, and they show up in my file manager (nautilus) with the correct dates, such as 2011/12/24 as a directory with the photos in it. However, Shotwell for some reason refuses to show that specific event date, 2011/12/24, but other directories with dates are shown for the same month. I've tried renaming the photos in my file manager and reimporting and even moving the photos out of the 2011/12/24 directory into the next previous date, 2011/12/17, but Shotwell still won't import them either into my library or the correct events directory. So why doesn't Shotwell see the 12/24 directory and show it in the side bar? Very strange behavior. I finally was able to import the photos by moving them to a directory on my desktop but of course I'd rather they be in the correct directory. Any ideas? From shotwell at crafthall.co.uk Sun Jan 8 14:19:22 2012 From: shotwell at crafthall.co.uk (Peter Sims) Date: Sun, 08 Jan 2012 14:19:22 +0000 Subject: [Shotwell] dated events Message-ID: <4F09A5EA.8020502@crafthall.co.uk> Shotwell sets up a dated list of events when it imports from say a folder. it seems impossible to set up a dated event any other way. for example I tried importing a batch of photos which didn't have a date on them. Shotwell stored them under "No Event" I tried creating an event and called it "Fri 27 Nov, 2009" instead of putting it in the list at the appropriate date it stored it under "Undated" is there any way to get it to store it under the appropriate date on the events list? Peter From dougie at highmoor.co.uk Sun Jan 8 21:56:43 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 08 Jan 2012 21:56:43 +0000 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: <4E842198.5070506@highmoor.co.uk> References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> Message-ID: <4F0A111B.1000303@highmoor.co.uk> On 29/09/2011 08:43, Dougie Nisbet wrote: > On 29/09/2011 02:43, Eric Gregory wrote: >> On Wed, Sep 28, 2011 at 12:50 PM, Dougie Nisbet >> > wrote: >> >> 1. Selectively removing tags from one or more images. It would be >> great to select a group of images, then right-click, remove tags, >> and have a pop-up list of tags common to the selected images. >> Removing a particular tag from photos seems quite convoluted. >> >> >> The "modify tags" dialog works similar to what you've described. Is >> that not what you're looking for? > > Not really. The 'modify tag' option is fine for single images with > just a few tags, but it is greyed-out for multiple selections. And the > pop-up window size for the 'modify tags' option is so small that it > soon becomes cumbersome for images with lots of tags, where presumable > the way to remove the unwanted tag is to manually delete it from the > text string. Any further thoughts on this? Right now I've selected a batch of photos and they are all mistagged with, say, 'wrongtag'. I want to remove 'wrongtag' from all the photos I've selected, and I can't. Removal of tags in shotwell seems a bit inelegant. I'm not sure how I'm meant to do it. Is it via Modify Tags? I'm doing a lot of retrospective re-organisation and it's exasperating now being able to remove incorrect tags from a batch of photos. Dougie From joel at duckworth.me Sun Jan 8 23:09:00 2012 From: joel at duckworth.me (Joel Duckworth) Date: Mon, 9 Jan 2012 10:09:00 +1100 Subject: [Shotwell] dated events Message-ID: You should be able to set a date and time on the picture by selecting the picture and going to Photos > Adjust date and time... They should then go into the order that you want, Cheers, Joel From adam at yorba.org Mon Jan 9 15:32:31 2012 From: adam at yorba.org (Adam Dingle) Date: Mon, 09 Jan 2012 07:32:31 -0800 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: <4F0A111B.1000303@highmoor.co.uk> References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> <4F0A111B.1000303@highmoor.co.uk> Message-ID: <4F0B088F.9050400@yorba.org> On 01/08/2012 01:56 PM, Dougie Nisbet wrote: > On 29/09/2011 08:43, Dougie Nisbet wrote: >> On 29/09/2011 02:43, Eric Gregory wrote: >>> On Wed, Sep 28, 2011 at 12:50 PM, Dougie Nisbet >>> > wrote: >>> >>> 1. Selectively removing tags from one or more images. It would be >>> great to select a group of images, then right-click, remove tags, >>> and have a pop-up list of tags common to the selected images. >>> Removing a particular tag from photos seems quite convoluted. >>> >>> >>> The "modify tags" dialog works similar to what you've described. Is >>> that not what you're looking for? >> >> Not really. The 'modify tag' option is fine for single images with >> just a few tags, but it is greyed-out for multiple selections. And >> the pop-up window size for the 'modify tags' option is so small that >> it soon becomes cumbersome for images with lots of tags, where >> presumable the way to remove the unwanted tag is to manually delete >> it from the text string. > > Any further thoughts on this? > > Right now I've selected a batch of photos and they are all mistagged > with, say, 'wrongtag'. I want to remove 'wrongtag' from all the photos > I've selected, and I can't. Removal of tags in shotwell seems a bit > inelegant. I'm not sure how I'm meant to do it. Is it via Modify Tags? > I'm doing a lot of retrospective re-organisation and it's exasperating > now being able to remove incorrect tags from a batch of photos. From http://yorba.org/shotwell/help/tag.html : To remove a tag from one or more photos, first select that tag in the sidebar, then select the photos you would like to remove, and chooseTags ?Remove Tag "[name]" from Photosor right-click on the photos and selectRemove Tag "[name]" from Photos. adam From adam at yorba.org Mon Jan 9 16:24:07 2012 From: adam at yorba.org (Adam Dingle) Date: Mon, 09 Jan 2012 08:24:07 -0800 Subject: [Shotwell] [recipe build #150681] of ~yorba shotwell-daily-build in oneiric: Failed to upload In-Reply-To: References: <20120107000516.12873.32720.launchpad@cesium.canonical.com> <4F079747.1050705@yorba.org> Message-ID: <4F0B14A7.8070206@yorba.org> Aha - I see. On 01/06/2012 05:54 PM, Eric Gregory wrote: > This isn't a build failure, it's an upload failure. If I understand > the log correctly, Launchpad rejected the build because no changes > occurred since the last successful build yesterday evening. > > - E > > > On Jan 6, 2012, at 4:52 PM, Adam Dingle wrote: > >> Eric, it looks like the Shotwell daily build is still broken. I >> thought you had fixed this - am I wrong? >> >> -------- Original Message -------- >> Subject: [recipe build #150681] of ~yorba shotwell-daily-build in >> oneiric: Failed to upload >> Date: Sat, 07 Jan 2012 00:05:16 -0000 >> From: noreply at launchpad.net >> Reply-To: noreply at launchpad.net >> To: Adam Dingle >> >> >> >> * State: Failed to upload >> * Recipe: yorba/shotwell-daily-build >> * Archive: yorba/daily-builds >> * Distroseries: oneiric >> * Duration: 4 minutes >> * Build Log:https://launchpadlibrarian.net/89264880/buildlog.txt.gz >> * Upload Log:https://launchpad.net/~yorba/+archive/daily-builds/+recipebuild/150681/+files/upload_3241957_log.txt >> * Builder:https://launchpad.net/builders/nannyberry >> >> -- >> https://launchpad.net/~yorba/+archive/daily-builds/+recipebuild/150681 >> Your team Yorba is the requester of the build. > From dougie at highmoor.co.uk Mon Jan 9 20:01:40 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 09 Jan 2012 20:01:40 +0000 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: <4F0B088F.9050400@yorba.org> References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> <4F0A111B.1000303@highmoor.co.uk> <4F0B088F.9050400@yorba.org> Message-ID: <4F0B47A4.7040109@highmoor.co.uk> On 09/01/2012 15:32, Adam Dingle wrote: > > From http://yorba.org/shotwell/help/tag.html : > > To remove a tag from one or more photos, first select that tag in the > sidebar, then select the photos you would like to remove, and > chooseTags ?Remove Tag "[name]" from Photosor right-click on the > photos and selectRemove Tag "[name]" from Photos. > > adam Thanks Adam. I don't know whether it's because I've come from f-spot or whether it's just my workflow pattern but I find it unintuitive to work this way. It's probably because I tend to browse photos by events, identify faults, select them, then attempt to fix them. I'll rewire my brain :-) Dougie From laura at yorba.org Mon Jan 9 20:28:59 2012 From: laura at yorba.org (Laura Khalil) Date: Mon, 9 Jan 2012 12:28:59 -0800 Subject: [Shotwell] Not importing certain pics In-Reply-To: <4F08CB69.2040000@cybermesa.com> References: <4F08CB69.2040000@cybermesa.com> Message-ID: Hi Brian, What version of Shotwell are you using, what version of Ubuntu are you running? For the photos you're having trouble with, can you please email me the exif data for one of them. If you're comfortable privately emailing me one of the photos in question, please do. Cheers, Laura On Sat, Jan 7, 2012 at 2:47 PM, BrianO'Keefe wrote: > I've imported photos to the correct directory, in my case > /Home/me/Pictures, and they show up in my file manager (nautilus) with the > correct dates, such as 2011/12/24 as a directory with the photos in it. > However, Shotwell for some reason refuses to show that specific event date, > 2011/12/24, but other directories with dates are shown for the same month. > I've tried renaming the photos in my file manager and reimporting and even > moving the photos out of the 2011/12/24 directory into the next previous > date, 2011/12/17, but Shotwell still won't import them either into my > library or the correct events directory. > So why doesn't Shotwell see the 12/24 directory and show it in the side > bar? Very strange behavior. I finally was able to import the photos by > moving them to a directory on my desktop but of course I'd rather they be > in the correct directory. Any ideas? > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From thomas at xyz.pp.se Tue Jan 10 10:54:20 2012 From: thomas at xyz.pp.se (Thomas Novin) Date: Tue, 10 Jan 2012 11:54:20 +0100 Subject: [Shotwell] Rotating an image In-Reply-To: <4F06EDAD.2090809@gmail.com> References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> Message-ID: <4F0C18DC.1080800@xyz.pp.se> Rainer M Krug wrote: > On 06/01/12 13:46, Marcel Stimberg wrote: >>> Unless I'm mistaken, if you've got the "save metadata to files" >>> setting enabled, then rotating the photo should update the exif >>> Rotation value i.e. it should indeed be "permanent". >> It seems there is a problem with this currently: >> http://redmine.yorba.org/issues/4239 >> >>> Whether any specific other application will pay attention to this >>> like it's supposed to, I couldn't say. But if they don't, that's >>> cause for a bug report to the other app rather than an >>> enhancement request to shotwell in my opinion ;-) >> Many applications take the flag into account but unfortunately not >> all (at least for Ubuntu there are a couple of bug reports for >> such applications already). Shotwell has a ticket about being able >> to optionally "physically" rotate the image so that all >> applications display it correctly: >> http://redmine.yorba.org/issues/2581 > > That would be a good idea - but please use in the jpeg case losless > rotation. > > Rainer Yes, please add this feature as not all viewers respect the EXIF-data. We mostly use Shotwell for importing and organizing photos, not viewing them. I would also like an option to make editing changes to the image itself, not just the database (contrary to http://www.yorba.org/shotwell/help/edit-nondestructive.html). F-spot did this nicely I think, if I did a change to a photo it could create a copy of the original. If I was happy with my change I could then remove the original, just keeping my edited copy. Rgds//Thomas From laura at yorba.org Tue Jan 10 19:09:05 2012 From: laura at yorba.org (Laura Khalil) Date: Tue, 10 Jan 2012 11:09:05 -0800 Subject: [Shotwell] Rotating an image In-Reply-To: <4F0C18DC.1080800@xyz.pp.se> References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> Message-ID: > I would also like an option to make editing changes to the image itself, > not just the database (contrary to > http://www.yorba.org/shotwell/help/edit-nondestructive.html). > > F-spot did this nicely I think, if I did a change to a photo it could > create a copy of the original. If I was happy with my change I could then > remove the original, just keeping my edited copy. > > Hi Thomas, We're aware that this is a desired feature. We do have two feature requests open in regards to this: 1798 and 1933 . These are features we would like to implement at some point in the future. Cheers, Laura From dougie at highmoor.co.uk Tue Jan 10 19:32:02 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 10 Jan 2012 19:32:02 +0000 Subject: [Shotwell] Rotating an image In-Reply-To: References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> Message-ID: <4F0C9232.6090009@highmoor.co.uk> On 10/01/2012 19:09, Laura Khalil wrote: >> I would also like an option to make editing changes to the image itself, >> not just the database (contrary to >> http://www.yorba.org/shotwell/help/edit-nondestructive.html). >> >> F-spot did this nicely I think, if I did a change to a photo it could >> create a copy of the original. If I was happy with my change I could then >> remove the original, just keeping my edited copy. >> >> > Hi Thomas, > > We're aware that this is a desired feature. We do have two feature requests > open in regards to this: 1798 and > 1933. These are features we would > like to implement at some point in the future. > > Cheers, > > Laura And another f-spot refugee here, who's *really* missing the 'straighten' feature, which is just a special kinda rotation, surely? :-) Dougie From adam at yorba.org Tue Jan 10 19:34:13 2012 From: adam at yorba.org (Adam Dingle) Date: Tue, 10 Jan 2012 11:34:13 -0800 Subject: [Shotwell] Rotating an image In-Reply-To: <4F0C9232.6090009@highmoor.co.uk> References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> <4F0C9232.6090009@highmoor.co.uk> Message-ID: <4F0C92B5.5010407@yorba.org> On 01/10/2012 11:32 AM, Dougie Nisbet wrote: > On 10/01/2012 19:09, Laura Khalil wrote: >>> I would also like an option to make editing changes to the image >>> itself, >>> not just the database (contrary to >>> http://www.yorba.org/shotwell/help/edit-nondestructive.html). >>> >>> F-spot did this nicely I think, if I did a change to a photo it could >>> create a copy of the original. If I was happy with my change I could >>> then >>> remove the original, just keeping my edited copy. >>> >>> >> Hi Thomas, >> >> We're aware that this is a desired feature. We do have two feature >> requests >> open in regards to this: 1798 and >> 1933. These are features we would >> like to implement at some point in the future. >> >> Cheers, >> >> Laura > > And another f-spot refugee here, who's *really* missing the > 'straighten' feature, which is just a special kinda rotation, surely? :-) Good news: Clinton Rogers here at Yorba has been making good progress on adding a straighten feature, and it's looking very likely this will make 0.12. adam From pt at traversin.org Tue Jan 10 19:57:38 2012 From: pt at traversin.org (pt) Date: Tue, 10 Jan 2012 20:57:38 +0100 Subject: [Shotwell] Rotating an image In-Reply-To: <4F0C9232.6090009@highmoor.co.uk> References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> <4F0C9232.6090009@highmoor.co.uk> Message-ID: On 10 January 2012 20:32, Dougie Nisbet wrote: > On 10/01/2012 19:09, Laura Khalil wrote: >>> >> >> We're aware that this is a desired feature. We do have two feature >> requests >> open in regards to this: 1798 ?and >> 1933. These are features we would >> like to implement at some point in the future. > > > And another f-spot refugee here, who's *really* missing the 'straighten' > feature, which is just a special kinda rotation, surely? :-) AFAIK you can only rotate losslessy a jpeg by 90 degrees steps. The 'straighten' in f-spot is a completely different beast, like the 'rotate' in GIMP, that requires a new compression of the file, hence a 'lossy' transformation. Ciao, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From dougie at highmoor.co.uk Tue Jan 10 20:47:22 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 10 Jan 2012 20:47:22 +0000 Subject: [Shotwell] Rotating an image In-Reply-To: References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> <4F0C9232.6090009@highmoor.co.uk> Message-ID: <4F0CA3DA.3050509@highmoor.co.uk> On 10/01/2012 19:57, pt wrote: > On 10 January 2012 20:32, Dougie Nisbet wrote: >> On 10/01/2012 19:09, Laura Khalil wrote: >>> We're aware that this is a desired feature. We do have two feature >>> requests >>> open in regards to this: 1798 and >>> 1933. These are features we would >>> like to implement at some point in the future. >> >> And another f-spot refugee here, who's *really* missing the 'straighten' >> feature, which is just a special kinda rotation, surely? :-) > AFAIK you can only rotate losslessy a jpeg by 90 degrees steps. > The 'straighten' in f-spot is a completely different beast, like the > 'rotate' in GIMP, that requires a new compression of the file, hence a > 'lossy' transformation. I guessed it might be, although I wasn't sure. I can live with that though. Dougie From r.m.krug at gmail.com Wed Jan 11 08:58:31 2012 From: r.m.krug at gmail.com (Rainer M Krug) Date: Wed, 11 Jan 2012 09:58:31 +0100 Subject: [Shotwell] Rotating an image In-Reply-To: <4F0CA3DA.3050509@highmoor.co.uk> References: <4F058447.4010309@xyz.pp.se> <4F06EDAD.2090809@gmail.com> <4F0C18DC.1080800@xyz.pp.se> <4F0C9232.6090009@highmoor.co.uk> <4F0CA3DA.3050509@highmoor.co.uk> Message-ID: <4F0D4F37.6070409@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/01/12 21:47, Dougie Nisbet wrote: > On 10/01/2012 19:57, pt wrote: >> On 10 January 2012 20:32, Dougie Nisbet >> wrote: >>> On 10/01/2012 19:09, Laura Khalil wrote: >>>> We're aware that this is a desired feature. We do have two >>>> feature requests open in regards to this: >>>> 1798 and >>>> 1933. These are >>>> features we would like to implement at some point in the >>>> future. >>> >>> And another f-spot refugee here, who's *really* missing the >>> 'straighten' feature, which is just a special kinda rotation, >>> surely? :-) >> AFAIK you can only rotate losslessy a jpeg by 90 degrees steps. >> The 'straighten' in f-spot is a completely different beast, like >> the 'rotate' in GIMP, that requires a new compression of the >> file, hence a 'lossy' transformation. > > I guessed it might be, although I wasn't sure. I can live with that > though. My personal opinion is that lossless and lossy operation should be clearly separated, and that lossy operation should not be available in a photo *management* program, but in a photo *editing* software. So it should be made *absolutely* clear, if an operation *degrades* the image / is lossless, and a backup should be created. I would actually also suggest to put lossy operations into a sub-menu, or even have the possibility in the settings to *disable* lossy operations - the risk is to high, that one ends up accidentally with a degraded image. Cheers, Rainer > > Dougie > > _______________________________________________ Shotwell mailing > list Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer at krugs.de Skype: RMkrug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8NTzcACgkQoYgNqgF2egqGrQCbBbiYHQj5ZO6kWJAfRO9bMGno O+AAoIZM2JHrtg6ahrctFVtquvy0c6kh =vVhR -----END PGP SIGNATURE----- From dougie at highmoor.co.uk Thu Jan 12 20:54:36 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 12 Jan 2012 20:54:36 -0000 Subject: [Shotwell] Cropping, retaining original size, and squinting Message-ID: <027d01ccd16c$64cfe0c0$2e6fa240$@highmoor.co.uk> f-spot has a nifty feature in that when you're cropping, and retaining original dimensions, it will automagically switch from portrait to landscape. This is something I found more useful than I realised. With many photos looking better landscape format than portrait, especially on web galleries, I sometimes crop images but try and swap portrait to landscape at the same time, but retaining photo dimensions at the same time, if that makes any sense. There was mention that shotwell would have an option to remember 'original size' on subsequent crops but I can't recall if a feature request was raised for this. Would there be any interest in a portrait-to-landscape switch as described above? Dougie From dougie at highmoor.co.uk Thu Jan 12 20:56:58 2012 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 12 Jan 2012 20:56:58 -0000 Subject: [Shotwell] Cropping, retaining original size, and squinting In-Reply-To: <027d01ccd16c$64cfe0c0$2e6fa240$@highmoor.co.uk> References: <027d01ccd16c$64cfe0c0$2e6fa240$@highmoor.co.uk> Message-ID: <028201ccd16c$b940b300$2bc21900$@highmoor.co.uk> Well isn't that just the way of things! No sooner had that email left my outbox that I discovered there's a 'screen' option, that offers exactly the switch I was talking about. Carry on, as you were, nothing to see ... -----Original Message----- From: shotwell-bounces at lists.yorba.org [mailto:shotwell-bounces at lists.yorba.org] On Behalf Of Dougie Nisbet Sent: 12 January 2012 20:55 To: shotwell at lists.yorba.org Subject: [Shotwell] Cropping, retaining original size, and squinting f-spot has a nifty feature in that when you're cropping, and retaining original dimensions, it will automagically switch from portrait to landscape. This is something I found more useful than I realised. With many photos looking better landscape format than portrait, especially on web galleries, I sometimes crop images but try and swap portrait to landscape at the same time, but retaining photo dimensions at the same time, if that makes any sense. There was mention that shotwell would have an option to remember 'original size' on subsequent crops but I can't recall if a feature request was raised for this. Would there be any interest in a portrait-to-landscape switch as described above? Dougie _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From spacemen12 at yahoo.com Sun Jan 15 03:21:58 2012 From: spacemen12 at yahoo.com (wallace1837) Date: Sat, 14 Jan 2012 19:21:58 -0800 (PST) Subject: [Shotwell] Tag written to file ... sometime Message-ID: <1326597718028-52331.post@talk.nabble.com> Hi, I am using Shotwell 0.11.6 in ubuntu. My "Write metadata to file" is check and has always been check, but the tags are only written to file sometime. I did not notice that until recently when I tries to look at my files in another software. In the other software only a few files are taged to the file and thus seen by the other software. For the file where a tag is present, generally all tags are present. Is there a way to do a "force write tags to file now" in Shotwell, since Shotwell kept track of the tags in its database. Best regards, -- View this message in context: http://shotwell.3510.www.nabble.com/Tag-written-to-file-sometime-tp52331p52331.html Sent from the Shotwell mailing list archive at Nabble.com. From laura at yorba.org Mon Jan 16 19:14:12 2012 From: laura at yorba.org (Laura Khalil) Date: Mon, 16 Jan 2012 11:14:12 -0800 Subject: [Shotwell] Tag written to file ... sometime In-Reply-To: <1326597718028-52331.post@talk.nabble.com> References: <1326597718028-52331.post@talk.nabble.com> Message-ID: Hi, Thanks for reporting this. There are a few known issues with writing metadata to files in Shotwell. To help us debug this issue, I have a couple questions: What file format are the files that do not show metadata? What is the other software you were using to open the files? Cheers, Laura On Sat, Jan 14, 2012 at 7:21 PM, wallace1837 wrote: > Hi, > I am using Shotwell 0.11.6 in ubuntu. My "Write metadata to file" is > check and has always been check, but the tags are only written to file > sometime. > > I did not notice that until recently when I tries to look at my files in > another software. In the other software only a few files are taged to the > file and thus seen by the other software. For the file where a tag is > present, generally all tags are present. > > Is there a way to do a "force write tags to file now" in Shotwell, since > Shotwell kept track of the tags in its database. > > Best regards, > > -- > View this message in context: > http://shotwell.3510.www.nabble.com/Tag-written-to-file-sometime-tp52331p52331.html > Sent from the Shotwell mailing list archive at Nabble.com. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From spacemen12 at yahoo.com Mon Jan 16 19:53:29 2012 From: spacemen12 at yahoo.com (wallace1837) Date: Mon, 16 Jan 2012 11:53:29 -0800 (PST) Subject: [Shotwell] Tag written to file ... sometime In-Reply-To: References: <1326597718028-52331.post@talk.nabble.com> Message-ID: <1326743609627-52407.post@talk.nabble.com> What file format are the files that do not show metadata? > CR2 from a canon 40d and the associated jpeg What is the other software you were using to open the files? > digiKam, exiftool, Geeqie. -- View this message in context: http://shotwell.3510.www.nabble.com/Tag-written-to-file-sometime-tp52331p52407.html Sent from the Shotwell mailing list archive at Nabble.com. From laura at yorba.org Mon Jan 16 20:49:03 2012 From: laura at yorba.org (Laura Khalil) Date: Mon, 16 Jan 2012 12:49:03 -0800 Subject: [Shotwell] Tag written to file ... sometime In-Reply-To: <1326743609627-52407.post@talk.nabble.com> References: <1326597718028-52331.post@talk.nabble.com> <1326743609627-52407.post@talk.nabble.com> Message-ID: Thanks for the additional information. We have a couple known bugs seem very similar to what you're experiencing 4372 and 4156. If comfortable, could you privately send me one of the CR2 photos in question? I would like to try to reproduce this. Cheers, Laura On Mon, Jan 16, 2012 at 11:53 AM, wallace1837 wrote: > What file format are the files that do not show metadata? > > CR2 from a canon 40d and the associated jpeg > > What is the other software you were using to open the files? > > digiKam, exiftool, Geeqie. > > -- > View this message in context: > http://shotwell.3510.www.nabble.com/Tag-written-to-file-sometime-tp52331p52407.html > Sent from the Shotwell mailing list archive at Nabble.com. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From shuihuzhuan at free.fr Fri Jan 20 11:02:36 2012 From: shuihuzhuan at free.fr (shuihuzhuan at free.fr) Date: Fri, 20 Jan 2012 12:02:36 +0100 (CET) Subject: [Shotwell] Use ionice? In-Reply-To: <9238c85b-d52a-4c09-af60-dae623c1a8bb@zimbra14-e2.priv.proxad.net> Message-ID: <4239e74b-4e0c-419a-ba05-2432421fd95e@zimbra14-e2.priv.proxad.net> Hi, I definitly switched to shotwell 1 month ago. It works quite good and I'm very happy. However one thing is really annoying : the big filesystem scan at launch. I only have 16k photos and it takes only 1 or 2 minutes. But during that time, the whole computer interface almost freezes due to a lot of IO on the HD. I had the same problem with rhythmbox. I more or less solved it by using ionice to launch it. I can do it also for shotwell (didn't try for the moment) but it may/should be better addressed by the program itself. Don't know if you already worked on that issue? Thanks PS : I really don't understand the necessity for such a big scan (in a user's point of view, though I understand it may be better in a programmer's point of view). It should be optionnal (but enabled by default). If shotwell isn't synchronized with the filesystem, it's not a big usability problem for the user (he knows it's not synchronized!). When a discrepency is encountered by shotwell (file missing, metadata changed ...), shotwell can tell it to the user and suggest to launch a manual rescan. From laura at yorba.org Fri Jan 20 16:34:58 2012 From: laura at yorba.org (Laura Khalil) Date: Fri, 20 Jan 2012 08:34:58 -0800 Subject: [Shotwell] Use ionice? In-Reply-To: <4239e74b-4e0c-419a-ba05-2432421fd95e@zimbra14-e2.priv.proxad.net> References: <9238c85b-d52a-4c09-af60-dae623c1a8bb@zimbra14-e2.priv.proxad.net> <4239e74b-4e0c-419a-ba05-2432421fd95e@zimbra14-e2.priv.proxad.net> Message-ID: Hi, Glad you're enjoying Shotwell. I believe what you may be experiencing is a known issue for some of our users: http://redmine.yorba.org/issues/3568 Currently the startup scan is necessary. If you'd like to monitor our progress on the issue listed above, or add your own comments, please subscribe to it. Cheers, Laura On Fri, Jan 20, 2012 at 3:02 AM, wrote: > Hi, > > I definitly switched to shotwell 1 month ago. It works quite good and I'm > very happy. > > However one thing is really annoying : the big filesystem scan at launch. > I only have 16k photos and it takes only 1 or 2 minutes. But during that > time, the whole computer interface almost freezes due to a lot of IO on the > HD. > > I had the same problem with rhythmbox. I more or less solved it by using > ionice to launch it. I can do it also for shotwell (didn't try for the > moment) but it may/should be better addressed by the program itself. Don't > know if you already worked on that issue? > > Thanks > > PS : I really don't understand the necessity for such a big scan (in a > user's point of view, though I understand it may be better in a > programmer's point of view). It should be optionnal (but enabled by > default). If shotwell isn't synchronized with the filesystem, it's not a > big usability problem for the user (he knows it's not synchronized!). When > a discrepency is encountered by shotwell (file missing, metadata changed > ...), shotwell can tell it to the user and suggest to launch a manual > rescan. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From spacemen12 at yahoo.com Sun Jan 22 18:21:21 2012 From: spacemen12 at yahoo.com (wallace1837) Date: Sun, 22 Jan 2012 10:21:21 -0800 (PST) Subject: [Shotwell] CR2 files not deleted when "moved to trash" and trash cleaned Message-ID: <1327256480954-52781.post@talk.nabble.com> With CR2+JPEG, when I remove pictures from shotwell (move to trah, then clean the trash), only the JPG file is deleted from the folder. The CR2 file is still there . I am working around by running this in the folder #!/bin/bash for i in *.CR2 do j=`echo $i | sed '$s/....$//'` k=${j}.JPG if [ ! -f $k ]; then rm $i fi done but I should not have to do it! -- View this message in context: http://shotwell.3510.www.nabble.com/CR2-files-not-deleted-when-moved-to-trash-and-trash-cleaned-tp52781p52781.html Sent from the Shotwell mailing list archive at Nabble.com. From andrew at avidandrew.com Mon Jan 23 04:41:19 2012 From: andrew at avidandrew.com (Andrew Martin) Date: Sun, 22 Jan 2012 22:41:19 -0600 Subject: [Shotwell] Import RAW+JPEG Pair From Camera Without Renaming Message-ID: Hello, Thank you for adding the RAW+JPEG pair collapsing view in Shotwell 0.11! The only thing that would make this work better for me is if the imported images both had identical names except for the extension. Currently, Shotwell appends an underscore and then the RAW extension to the JPEG. For example, if I were to import _MG_9934.CR2 and _MG_9934.jpg from my camera, I would expect to have these two files on my computer. However, Shotwell renames the JPEG to be _MG_9932*_CR2*.jpg. Is it possible to somehow configure it to not add this suffix? I have started browsing through the Shotwell source but can't find where this suffix is added - can someone point me to the right file or function? Thanks, Andrew From laura at yorba.org Mon Jan 23 19:33:04 2012 From: laura at yorba.org (Laura Khalil) Date: Mon, 23 Jan 2012 11:33:04 -0800 Subject: [Shotwell] CR2 files not deleted when "moved to trash" and trash cleaned In-Reply-To: <1327256480954-52781.post@talk.nabble.com> References: <1327256480954-52781.post@talk.nabble.com> Message-ID: Hi, Thanks for reporting this. This is a known issue with some of our users and has been documented here: http://redmine.yorba.org/issues/4207 You'll be happy to know that this is high on our list to fix. Cheers, Laura On Sun, Jan 22, 2012 at 10:21 AM, wallace1837 wrote: > With CR2+JPEG, when I remove pictures from shotwell (move to trah, then > clean > the trash), only the JPG file is deleted from the folder. The CR2 file is > still there . I am working around by running this in the folder > > > #!/bin/bash > > for i in *.CR2 > do > j=`echo $i | sed '$s/....$//'` > k=${j}.JPG > if [ ! -f $k ]; > then > rm $i > fi > done > > but I should not have to do it! > > -- > View this message in context: > http://shotwell.3510.www.nabble.com/CR2-files-not-deleted-when-moved-to-trash-and-trash-cleaned-tp52781p52781.html > Sent from the Shotwell mailing list archive at Nabble.com. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From nigeldodd at gmail.com Tue Jan 24 10:23:59 2012 From: nigeldodd at gmail.com (Nigel Dodd) Date: Tue, 24 Jan 2012 10:23:59 +0000 Subject: [Shotwell] stuck importing Message-ID: The last thing I did was import a large number of files from another partition. When I next started Shotwell that partition was not mounted and it assigned those imported files to the "Missing Files" category. Now, when I try to import just a few images on the normal mounted partition Shotwell gets stuck, consuming 100% cpu. I don't really want to scrub the installation. What can I do? ps is there not a forum where we can search for other problems and solutions? Nigel From laura at yorba.org Tue Jan 24 22:20:56 2012 From: laura at yorba.org (Laura Khalil) Date: Tue, 24 Jan 2012 14:20:56 -0800 Subject: [Shotwell] stuck importing In-Reply-To: References: Message-ID: Hi Nigel, Let's figure this one out. First off, what version of Shotwell and what operating system are you on? Also, how many CPUs does your computer have? If you can repeat this, it would be very helpful if you could provide me with the log file and a stack trace when Shotwell gets stuck on import. To learn how to do that, check out this link . Also, you mention that files you imported from another partiton are showing up as missing files when you launch Shotwell (and when the partition in question is not mounted). This is expected behavior. Each time Shotwell starts up, it scans your photo library to verify that all photo files still exist on your hard drive. If Shotwell finds that any photo files are missing, it will not display them in the normal Photos, Events and Tags views, but will instead show them in a separate Missing Files view which will appear in the sidebar. Finally, while we do not run a forum for Shotwell users, if you think you've found a bug, you can search our Redmine bug and issue tracker to see if the bug is known and what its status is. You may also file bug reports in Redmine. Cheers, Laura On Tue, Jan 24, 2012 at 2:23 AM, Nigel Dodd wrote: > > The last thing I did was import a large number of files from another > partition. When I next started Shotwell that partition was not mounted and > it assigned those imported files to the "Missing Files" category. Now, when > I try to import just a few images on the normal mounted partition Shotwell > gets stuck, consuming 100% cpu. > > I don't really want to scrub the installation. What can I do? > > ps is there not a forum where we can search for other problems and > solutions? > > Nigel > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From scott_shotwell at dewie.net.au Sun Jan 29 12:21:30 2012 From: scott_shotwell at dewie.net.au (Scott) Date: Sun, 29 Jan 2012 23:21:30 +1100 Subject: [Shotwell] options for storage of rendered RAW files and/or batch rendering? Message-ID: <4F2539CA.4000704@dewie.net.au> Hi there, Firstly, i'm unsure of wheather i am even in the right place, and as this is my first post (and am unsure of how to check older posts) am unsure wheather this has been raised before even. But my question is, is it possible in future versions to have the option, somewhere in the preferences, of where rendered RAW files are stored? I used to be a little annoyed that it did store those files in the home directory when my collection was stored locally on the hdd. But now, for a few reasons, my collection is on an external hdd, and rendering in the new version is in-line which makes accessing and rendering much slower than it needs to be. For those that do use external drives, a feature like this could be similar to imatch's offline caching of photo's (shotwell is what i replaced imatch with). I am one that would copy the rendered JPG's manually if i needed them and especially if they were in the same folder hirachy as the library. Also - another feature that would be handy is, again in preferences, the option of batch rendering RAW or on-demand as the current version does. I have always liked the batch proccessing of RAW files, especially on first import from a fresh install, but i guess those with in-line rendering would not have this problem. I must say though, i do very much love Shotwell, and especially with what i do the fact that it is non-destructive. A wonderful all-round tool.. Thanks, Scott. From edgimar at gmail.com Mon Jan 30 01:38:23 2012 From: edgimar at gmail.com (Mark Edgington) Date: Sun, 29 Jan 2012 20:38:23 -0500 Subject: [Shotwell] option to have separate video/image import directories Message-ID: I don't know if it's been discussed before, but I would find it useful if I could have shotwell place imported video files in a video folder tree, and images in a photos folder tree. Because videos are often much larger than photos, separating them into different folders can be useful when backing the files up (e.g. one folder can be backed up on some large storage device, and another perhaps via a cloud-based storage). Let me know what you think... From pt at traversin.org Mon Jan 30 08:17:44 2012 From: pt at traversin.org (pt) Date: Mon, 30 Jan 2012 09:17:44 +0100 Subject: [Shotwell] option to have separate video/image import directories In-Reply-To: References: Message-ID: On 30 January 2012 02:38, Mark Edgington wrote: > I don't know if it's been discussed before, but I would find it useful > if I could have shotwell place imported video files in a video folder > tree, and images in a photos folder tree. ?Because videos are often Yes, every now and then this subject comes out in the mailing list ;-) Any way, I agree with you, even if I do all the imports 'manually'. +1 In my opinion the best thing would be to have in the 'Importing' section of the preferences a 'Filter' box (pretty much the same of the 'custom import' one) with a pattern to match and a destination folder (or folder structure). Cheers, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From laura at yorba.org Mon Jan 30 18:39:57 2012 From: laura at yorba.org (Laura Khalil) Date: Mon, 30 Jan 2012 10:39:57 -0800 Subject: [Shotwell] option to have separate video/image import directories In-Reply-To: References: Message-ID: Hi Piergi, Mark, Thanks for letting us know this feature is important to you. We already have a feature request in Redmine which corresponds: http://redmine.yorba.org/issues/2697 This is not a feature we'll be implementing in the near term, but we are always improving Shotwell and may get to it in the future. To follow the progress on this feature you can choose to watch the ticket in Redmine for updates. Cheers, Laura On Mon, Jan 30, 2012 at 12:17 AM, pt wrote: > On 30 January 2012 02:38, Mark Edgington wrote: > > I don't know if it's been discussed before, but I would find it useful > > if I could have shotwell place imported video files in a video folder > > tree, and images in a photos folder tree. Because videos are often > > > Yes, every now and then this subject comes out in the mailing list ;-) > > Any way, I agree with you, even if I do all the imports 'manually'. +1 > > In my opinion the best thing would be to have in the 'Importing' > section of the preferences a 'Filter' box (pretty much the same of the > 'custom import' one) with a pattern to match and a destination folder > (or folder structure). > > Cheers, > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From joseph.bylund at gmail.com Mon Jan 30 18:47:55 2012 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Mon, 30 Jan 2012 13:47:55 -0500 Subject: [Shotwell] option to have separate video/image import directories In-Reply-To: References: Message-ID: <4F26E5DB.1080500@gmail.com> Dear all, Not that I don't think that would be a great feature, but it seems to be more a feature of backup software than photo management software. So for me personally, there are other things I'd be more excited about. Just my $0.02. -Joe On 01/30/2012 01:39 PM, Laura Khalil wrote: > Hi Piergi, Mark, > > Thanks for letting us know this feature is important to you. We already > have a feature request in Redmine which corresponds: > > http://redmine.yorba.org/issues/2697 > > This is not a feature we'll be implementing in the near term, but we are > always improving Shotwell and may get to it in the future. To follow the > progress on this feature you can choose to watch the ticket in Redmine for > updates. > > Cheers, > > Laura > > On Mon, Jan 30, 2012 at 12:17 AM, pt wrote: > >> On 30 January 2012 02:38, Mark Edgington wrote: >>> I don't know if it's been discussed before, but I would find it useful >>> if I could have shotwell place imported video files in a video folder >>> tree, and images in a photos folder tree. Because videos are often >> >> Yes, every now and then this subject comes out in the mailing list ;-) >> >> Any way, I agree with you, even if I do all the imports 'manually'. +1 >> >> In my opinion the best thing would be to have in the 'Importing' >> section of the preferences a 'Filter' box (pretty much the same of the >> 'custom import' one) with a pattern to match and a destination folder >> (or folder structure). >> >> Cheers, >> Piergi >> -- >> Web: http://traversin.org >> GNU/Linux user 190604 >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From edgimar at gmail.com Mon Jan 30 19:52:21 2012 From: edgimar at gmail.com (Mark Edgington) Date: Mon, 30 Jan 2012 14:52:21 -0500 Subject: [Shotwell] option to have separate video/image import directories Message-ID: Maybe an alternative to doing this which would be more useful would be to implement feature #2782 (http://redmine.yorba.org/issues/2872), allowing some of the virtual directories of the FUSE filesystem to split on filetype. By the way, I assume that just because this isn't a current focus of the Yorba team doesn't mean that external contributors couldn't work on it, right? Or would it not be worth it for someone to work on it because it wouldn't likely be incorporated into Shotwell? From brunogirin at gmail.com Mon Jan 30 20:50:45 2012 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 30 Jan 2012 20:50:45 +0000 Subject: [Shotwell] option to have separate video/image import directories In-Reply-To: References: Message-ID: <4F2702A5.1020405@gmail.com> On 30/01/12 19:52, Mark Edgington wrote: > Maybe an alternative to doing this which would be more useful would be > to implement feature #2782 (http://redmine.yorba.org/issues/2872), > allowing some of the virtual directories of the FUSE filesystem to > split on filetype. By the way, I assume that just because this isn't > a current focus of the Yorba team doesn't mean that external > contributors couldn't work on it, right? Or would it not be worth it > for someone to work on it because it wouldn't likely be incorporated > into Shotwell? Speaking from past experience, I can confirm that if you contribute a patch for it, the Yorba team will be very receptive and will help you get it right. The more contributors, the better. Vala is not a difficult language to learn if you know Java or C# and if you've got basic understanding of GTK+, so go ahead and hack it! Cheers, Bruno From adam at yorba.org Mon Jan 30 21:43:19 2012 From: adam at yorba.org (Adam Dingle) Date: Mon, 30 Jan 2012 13:43:19 -0800 Subject: [Shotwell] option to have separate video/image import directories In-Reply-To: References: Message-ID: <4F270EF7.1070601@yorba.org> On 01/30/2012 11:52 AM, Mark Edgington wrote: > Maybe an alternative to doing this which would be more useful would be > to implement feature #2782 (http://redmine.yorba.org/issues/2872), > allowing some of the virtual directories of the FUSE filesystem to > split on filetype. I don't see how that would lead to separate image and video import directories. Feature #2782 is about exposing Shotwell's database via FUSE; it wouldn't affect where Shotwell actually stores photos and videos. > By the way, I assume that just because this isn't > a current focus of the Yorba team doesn't mean that external > contributors couldn't work on it, right? Or would it not be worth it > for someone to work on it because it wouldn't likely be incorporated > into Shotwell? In general any open ticket represents something that the team is open to having in Shotwell. But for a large project like a FUSE module it's a good idea to discuss the design on this mailing list and/or on the corresponding ticket before delving into an implementation, just to make sure that we all agree about what we want. adam From adam at yorba.org Tue Jan 31 18:50:39 2012 From: adam at yorba.org (Adam Dingle) Date: Tue, 31 Jan 2012 10:50:39 -0800 Subject: [Shotwell] options for storage of rendered RAW files and/or batch rendering? In-Reply-To: <4F2539CA.4000704@dewie.net.au> References: <4F2539CA.4000704@dewie.net.au> Message-ID: <4F2837FF.6000503@yorba.org> Scott, On 01/29/2012 04:21 AM, Scott wrote: > Hi there, > > Firstly, i'm unsure of wheather i am even in the right place, and as > this is my first post (and am unsure of how to check older posts) am > unsure wheather this has been raised before even. You're in the right place. To check older posts, look at the archive of messages previously sent to this list at http://lists.yorba.org/pipermail/shotwell/ . > > But my question is, is it possible in future versions to have the > option, somewhere in the preferences, of where rendered RAW files are > stored? I used to be a little annoyed that it did store those files > in the home directory when my collection was stored locally on the > hdd. But now, for a few reasons, my collection is on an external hdd, > and rendering in the new version is in-line which makes accessing and > rendering much slower than it needs to be. Are you sure that storing the external hard drive is really the bottleneck? Which operations seem to be slow? In the Shotwell preferences, have you set RAW Developer to Shotwell or Camera? Unfortunately this is an area of Shotwell which is quite buggy at this time - see http://redmine.yorba.org/issues/4691 and http://redmine.yorba.org/issues/4692, for example. Our intent in 0.11 was that if the user sets the RAW Developer preference to Camera then Shotwell should never develop a photo itself, which will greatly speed importing and rendering. Unfortunately due to these bugs this is not the case, and that may be the true cause of the slowness you're perceiving. I hope we can improve the situation for 0.12. > > For those that do use external drives, a feature like this could be > similar to imatch's offline caching of photo's (shotwell is what i > replaced imatch with). I am one that would copy the rendered JPG's > manually if i needed them and especially if they were in the same > folder hirachy as the library. > > Also - another feature that would be handy is, again in preferences, > the option of batch rendering RAW or on-demand as the current version > does. I have always liked the batch proccessing of RAW files, > especially on first import from a fresh install, but i guess those > with in-line rendering would not have this problem. I'm not sure I understand what this preference would do. If you set RAW Developer to Shotwell, then Shotwell should render all RAW photos at import time so they are available to display immediately when you open them. If you set RAW Developer to Camera, then they should always be immediately available since there is no rendering to be done. Again, due to bugs this isn't exactly how things work today, but that's the intent. I'm not sure whether you all call this "batch" or "on-demand". Does this behavior seem reasonable to you, or do you want the option for things to work differently? adam