From Sebastian at SSpaeth.de Wed Sep 1 07:30:41 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Wed, 01 Sep 2010 09:30:41 +0200 Subject: [Shotwell] Photo-viewer and importing photos. In-Reply-To: <224515.1872.qm@web33707.mail.mud.yahoo.com> References: <4C7BE0B8.9000009@yorba.org> <4C7C0991.6000709@yorba.org> <20100830195009.GA5411@talktalkplc.com> <224515.1872.qm@web33707.mail.mud.yahoo.com> Message-ID: <87sk1tly3i.fsf@SSpaeth.de> On 2010-08-31, Lu Timdale wrote: > proposing is that > a) users don't usually rotate pictures .... fail > b) when they do, they only usually rotate one way.... fail > c) when they want to rotate the other way, they have to know to hover over and > then very intuitively hold the control key while clicking the rotate button... > fail x3 Oh come on, the point about screen estate is a very valid one. And yes: a) users won't usually rotate pictures if they are auto-rotated according to the camera orientation. b) Given that pictures are auto-rotated according to orientation when taking, I know that my mother has no problems pressing that button 3 times. If she used that functionality more often, she would discover the ctrl-click when hovering and reading the tooltip. c) If it's described in the tooltip, it is actually discoverable. Cut the developers some slack :). If it proves to be the worst usability decision in human history, I am sure we'll get another icon sooner or later. Until then, there are bigger fish to fry. Sebastian From Sebastian at SSpaeth.de Wed Sep 1 07:30:53 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Wed, 01 Sep 2010 09:30:53 +0200 Subject: [Shotwell] Photo-viewer and importing photos. In-Reply-To: <224515.1872.qm@web33707.mail.mud.yahoo.com> References: <4C7BE0B8.9000009@yorba.org> <4C7C0991.6000709@yorba.org> <20100830195009.GA5411@talktalkplc.com> <224515.1872.qm@web33707.mail.mud.yahoo.com> Message-ID: <87r5hdly36.fsf@SSpaeth.de> On 2010-08-31, Lu Timdale wrote: > proposing is that > a) users don't usually rotate pictures .... fail > b) when they do, they only usually rotate one way.... fail > c) when they want to rotate the other way, they have to know to hover over and > then very intuitively hold the control key while clicking the rotate button... > fail x3 Oh come on, the point about screen estate is a very valid one. And yes: a) users won't usually rotate pictures if they are auto-rotated according to the camera orientation. b) Given that pictures are auto-rotated according to orientation when taking, I know that my mother has no problems pressing that button 3 times. If she used that functionality more often, she would discover the ctrl-click when hovering and reading the tooltip. c) If it's described in the tooltip, it is actually discoverable. Cut the developers some slack :). If it proves to be the worst usability decision in human history, I am sure we'll get another icon sooner or later. Until then, there are bigger fish to fry. Sebastian From pdo.smith at gmail.com Wed Sep 1 11:26:26 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Wed, 1 Sep 2010 13:26:26 +0200 Subject: [Shotwell] Photo-viewer and importing photos. In-Reply-To: References: Message-ID: Chris, Within Shotwell the Del button works in the following views 1) the icon view 2) the intermediate view after double click 3) the full screen view after F11 These are all the views of the main Shotwell program. I tried opening the Shotwell viewer from the file manager as you described and then the Del button does not work. Considering it works within ALL the normal views I would guess that the developers may have intended not to allow deletion from there, or alternatively it was an oversight and it is good that we should bring it to their attention. But the developers will know. Either way, can I suggest we strive for some civility in these discussions? We are all on the same side and have no need to prove a point. On Wed, Sep 1, 2010 at 12:17 AM, Chris Game wrote: > > > Chris, the Del button is a convenient shortcut that works in all views. > > > (All together now) Oh no it doesn't! > > Try opening a folder of photos in the file manager, r-click on one and > 'Open in Shotwell Photo Viewer'; in the SPV hit 'Delete', result: no > action! > > (Give me some credit for trying that for goodness sake!) > > On the arrow usability issue there's an old piece of advice worth > bearing in mind: 'Keep things as simple as possible', it reduces the > chance of mistakes however experienced you are. Relying on shortcuts > or tooltips is making things complicated. > > Regards, Chris Game > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Wed Sep 1 16:12:34 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 01 Sep 2010 09:12:34 -0700 Subject: [Shotwell] Photo-viewer and importing photos. In-Reply-To: References: Message-ID: <4C7E7B72.1020709@yorba.org> On 09/01/2010 04:26 AM, Peter DO Smith wrote: > Chris, > Within Shotwell the Del button works in the following views > 1) the icon view > 2) the intermediate view after double click > 3) the full screen view after F11 > These are all the views of the main Shotwell program. > > I tried opening the Shotwell viewer from the file manager as you described > and then the Del button does not work. Considering it works within ALL the > normal views I would guess that the developers may have intended not to > allow deletion from there, or alternatively it was an oversight and it is > good that we should bring it to their attention. But the developers will > know. > Yes - we'd like to implement deletion in the Shotwell viewer, but haven't gotten to that yet. The ticket http://trac.yorba.org/ticket/2231 tracks this. This is a popular request, so I've just upped the ticket priority to high; I hope we can implement this for 0.8. cheers adam > Either way, can I suggest we strive for some civility in these discussions? > We are all on the same side and have no need to prove a point. > > On Wed, Sep 1, 2010 at 12:17 AM, Chris Game wrote: > > >> >>> Chris, the Del button is a convenient shortcut that works in all views. >>> >>> >> (All together now) Oh no it doesn't! >> >> Try opening a folder of photos in the file manager, r-click on one and >> 'Open in Shotwell Photo Viewer'; in the SPV hit 'Delete', result: no >> action! >> >> (Give me some credit for trying that for goodness sake!) >> >> On the arrow usability issue there's an old piece of advice worth >> bearing in mind: 'Keep things as simple as possible', it reduces the >> chance of mistakes however experienced you are. Relying on shortcuts >> or tooltips is making things complicated. >> >> Regards, Chris Game >> _______________________________________________ >> 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 lutimdale at yahoo.com Wed Sep 1 21:44:32 2010 From: lutimdale at yahoo.com (Lu Timdale) Date: Wed, 1 Sep 2010 14:44:32 -0700 (PDT) Subject: [Shotwell] Photo-viewer and importing photos. In-Reply-To: <87r5hdly36.fsf@SSpaeth.de> References: <4C7BE0B8.9000009@yorba.org> <4C7C0991.6000709@yorba.org> <20100830195009.GA5411@talktalkplc.com> <224515.1872.qm@web33707.mail.mud.yahoo.com> <87r5hdly36.fsf@SSpaeth.de> Message-ID: <804668.26672.qm@web33708.mail.mud.yahoo.com> > a) users won't usually rotate pictures if they are auto-rotated > according to the camera orientation. Yes, I agree that in the case that the camera captures the autorotate setting, it's not used at all or hardly at all. I purchased an underwater camera only a year ago that doesn't do this.... so believe it or not, not all cameras do autorotation / setting the exif rotate flag. > Cut the developers some slack :). If it proves to be the worst usability > decision in human history, I am sure we'll get another icon sooner or > later. Until then, there are bigger fish to fry. Slack cut... :-) and yes I agree that it's not the biggest issue. But it would still be nice to have that icon as I find it would help me. I don't see this as a large implementation effort. Would you consider a patch? I would need to get my hands dirty with Vala for the first time and find time for it, but it may be fun. :-) > From Peter DO Smith... > Either way, can I suggest we strive for some civility in these discussions? > We are all on the same side and have no need to prove a point. I didn't mean to come off too harsh. (see 3 fail references) Sorry about that. However, it seems like certain opinions are not given much consideration prior to being completely shut down. Also, some of these discussions/decisions could be made simpler if UI guidelines existed that focused on minimizing mouse clicks for example. Lu Timdale lutimdale at yahoo.com ----- Original Message ---- From: Sebastian Spaeth To: shotwell at lists.yorba.org Sent: Wed, September 1, 2010 3:30:53 AM Subject: Re: [Shotwell] Photo-viewer and importing photos. On 2010-08-31, Lu Timdale wrote: > proposing is that > a) users don't usually rotate pictures .... fail > b) when they do, they only usually rotate one way.... fail > c) when they want to rotate the other way, they have to know to hover over and > then very intuitively hold the control key while clicking the rotate button... > fail x3 Oh come on, the point about screen estate is a very valid one. And yes: a) users won't usually rotate pictures if they are auto-rotated according to the camera orientation. b) Given that pictures are auto-rotated according to orientation when taking, I know that my mother has no problems pressing that button 3 times. If she used that functionality more often, she would discover the ctrl-click when hovering and reading the tooltip. c) If it's described in the tooltip, it is actually discoverable. Cut the developers some slack :). If it proves to be the worst usability decision in human history, I am sure we'll get another icon sooner or later. Until then, there are bigger fish to fry. Sebastian _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From fields.emmett at gmail.com Wed Sep 1 23:02:34 2010 From: fields.emmett at gmail.com (e.m.fields) Date: Wed, 1 Sep 2010 19:02:34 -0400 Subject: [Shotwell] XCF / Versioning support? Message-ID: Hi. Ubuntu user, I've been running around trying to nail down which of the photomanager applications can suit my needs, between f-spot and digikam. Checking out shotwell now, as it's moving to standard in 10.10 "Maverick" release. Looks good. Main feature requests that I've found has (too late) been added in F-spot is the much-needed XCF support, as well as decent versioning system for images, and file-folder monitoring. I would like to know if these exist in shotwell, or if plans to do so are in near-future. 1. XCF support XCF is the native GIMP image editor image format, necessary for users who rely heavily on this standard linux application. i . Make sure that shotwell is able to index and view XCF files. ii. Make an edit in gimp, export as JPEG/PNG and have this edit added to shotwell iii. Open in GIMP for an edit, and save as XCF, and have this edit added to shotwell. 2. Versioning F-spot has a great versioning system, and digikam has moved in this direction as well. Multiple versions of one image can be "stacked" on top of the original, and user can select between versions, as well as designate new images as versions of another. i. Does versioning exist in shotwell? ii. Can other files be added and linked as a version of the same image? 3. Filesystem folder monitoring A big feature request, and I think people would really agree with me here after experiencing it - Monitoring of folders, aka "Watching folders for new images". use case: I add an image to a folder designated as a "watched folder" in shotwell, and shotwell automatically recognizes and imports this image on next startup. HUGELY important if you're going to be shifting around your image files in any other way, which is one of my biggest gripes with F-Spot. i. Does it exist for shotwell? ii. Are there any plans for adding this in the future? Thanks! - e.m.fields chapel hill, nc From chrisgame at pobox.com Thu Sep 2 10:28:27 2010 From: chrisgame at pobox.com (Chris Game) Date: Thu, 2 Sep 2010 11:28:27 +0100 (BST) Subject: [Shotwell] Shotwell Digest, Vol 14, Issue 2 In-Reply-To: References: Message-ID: > > Yes - we'd like to implement deletion in the Shotwell viewer, but > haven't gotten to that yet. The ticket > http://trac.yorba.org/ticket/2231 tracks this. This is a popular > request, so I've just upped the ticket priority to high; I hope we can > implement this for 0.8. > Thanks for the reference - that ticket makes interesting reading, with some good suggestions for easy modification to the Viewer code. I hope the developers aren't spending so much time frying the big fish that these simple oversights in the user interface just get overlooked. New users like me are likely to be put off by this kind of 'bug' that we notice in the first few uses of the program. One or two critics aside - I like the general tone of the group and the developer involvement with openness to suggestions, which is unusual in such groups these days. I know there is a lot of interest in esoteric features, but it is as well to get the things that everybody uses right first. Regds, Chris Game From adam at yorba.org Thu Sep 2 17:36:33 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 02 Sep 2010 10:36:33 -0700 Subject: [Shotwell] XCF / Versioning support? In-Reply-To: References: Message-ID: <4C7FE0A1.2050703@yorba.org> On 09/01/2010 04:02 PM, e.m.fields wrote: > Hi. Ubuntu user, I've been running around trying to nail down which of the > photomanager applications can suit my needs, between f-spot and digikam. > Checking out shotwell now, as it's moving to standard in 10.10 "Maverick" > release. Looks good. > Hello! > Main feature requests that I've found has (too late) been added in F-spot is > the much-needed XCF support, as well as decent versioning system for images, > and file-folder monitoring. I would like to know if these exist in > shotwell, or if plans to do so are in near-future. > > 1. XCF support > XCF is the native GIMP image editor image format, necessary for users who > rely heavily on this standard linux application. > i . Make sure that shotwell is able to index and view XCF files. > ii. Make an edit in gimp, export as JPEG/PNG and have this edit added to > shotwell > iii. Open in GIMP for an edit, and save as XCF, and have this edit added to > shotwell. > Shotwell has no support for XCF today. Regarding your question (ii): Shotwell can open a photo in an external editor, and if you open a JPEG photo in GIMP from within Shotwell and save your changes in JPEG format, Shotwell will notice the change and update its thumbnails. (If you open the photo from GIMP *outside* Shotwell and save, then Shotwell 0.7 will not notice the change, but the trunk build will since we've implemented this recently.) I've just added a ticket for us to support XCF format (and/or its possible successor, OpenRaster): http://trac.yorba.org/ticket/2509 . This is probably not near the top of our priority list for the next couple of releases, but patches are gladly accepted! :) > 2. Versioning > F-spot has a great versioning system, and digikam has moved in this > direction as well. Multiple versions of one image can be "stacked" on top > of the original, and user can select between versions, as well as designate > new images as versions of another. > i. Does versioning exist in shotwell? > > ii. Can other files be added and linked as a version of the same image? > Shotwell's versioning system today is primitive. Each photo essentially has two versions: the original and the edited version (which incorporates both external edits and edits performed within Shotwell). You can view the original version of any photo by pressing the Shift key within Shotwell, and the Revert to Original command reverts back to the original version. We've thought about more complex versioning schemes and are potentially open to those, though it's very important to us to keep the user experience simple, so we've made no decisions about this. See http://trac.yorba.org/ticket/2474 . > 3. Filesystem folder monitoring > A big feature request, and I think people would really agree with me here > after experiencing it - > Monitoring of folders, aka "Watching folders for new images". > use case: I add an image to a folder designated as a "watched folder" in > shotwell, and shotwell automatically recognizes and imports this image on > next startup. HUGELY important if you're going to be shifting around your > image files in any other way, which is one of my biggest gripes with > F-Spot. > i. Does it exist for shotwell? > > ii. Are there any plans for adding this in the future? > Folder monitoring is not in 0.7, but we've just implemented this in the trunk, so it will be in 0.8. Note that we auto-import from the library directory only. I hope that in a future release we'll support multiple watched folders. If you want to try this in the trunk, you need to specify --auto-import on the command line when you run Shotwell (this option will go away soon). See http://trac.yorba.org/ticket/2478 . cheers adam From pdo.smith at gmail.com Thu Sep 2 18:54:58 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Thu, 2 Sep 2010 20:54:58 +0200 Subject: [Shotwell] XCF / Versioning support? In-Reply-To: References: <4C7FE0A1.2050703@yorba.org> Message-ID: ---------- Forwarded message ---------- From: Peter DO Smith Date: Thu, Sep 2, 2010 at 8:52 PM Subject: Re: [Shotwell] XCF / Versioning support? To: Adam Dingle Sorry, this should have gone to the mailing list Adam, re the versioning issue you might want to take a look at NILFS, a continuous snapshotting system developed by NEC. It is now included in the kernel. I have used it, with some success, as the basis for a versioning system for documentation in the pharmaceutical industry. regards, Peter On Thu, Sep 2, 2010 at 7:36 PM, Adam Dingle wrote: > On 09/01/2010 04:02 PM, e.m.fields wrote: > > Hi. Ubuntu user, I've been running around trying to nail down which of > the > > photomanager applications can suit my needs, between f-spot and digikam. > > Checking out shotwell now, as it's moving to standard in 10.10 "Maverick" > > release. Looks good. > > > > Hello! > > > Main feature requests that I've found has (too late) been added in F-spot > is > > the much-needed XCF support, as well as decent versioning system for > images, > > and file-folder monitoring. I would like to know if these exist in > > shotwell, or if plans to do so are in near-future. > > > > 1. XCF support > > XCF is the native GIMP image editor image format, necessary for users who > > rely heavily on this standard linux application. > > i . Make sure that shotwell is able to index and view XCF files. > > ii. Make an edit in gimp, export as JPEG/PNG and have this edit added to > > shotwell > > iii. Open in GIMP for an edit, and save as XCF, and have this edit added > to > > shotwell. > > > > Shotwell has no support for XCF today. Regarding your question (ii): > Shotwell can open a photo in an external editor, and if you open a JPEG > photo in GIMP from within Shotwell and save your changes in JPEG format, > Shotwell will notice the change and update its thumbnails. (If you open > the photo from GIMP *outside* Shotwell and save, then Shotwell 0.7 will > not notice the change, but the trunk build will since we've implemented > this recently.) > > I've just added a ticket for us to support XCF format (and/or its > possible successor, OpenRaster): http://trac.yorba.org/ticket/2509 . > This is probably not near the top of our priority list for the next > couple of releases, but patches are gladly accepted! :) > > > 2. Versioning > > F-spot has a great versioning system, and digikam has moved in this > > direction as well. Multiple versions of one image can be "stacked" on > top > > of the original, and user can select between versions, as well as > designate > > new images as versions of another. > > i. Does versioning exist in shotwell? > > > > ii. Can other files be added and linked as a version of the same image? > > > > Shotwell's versioning system today is primitive. Each photo essentially > has two versions: the original and the edited version (which > incorporates both external edits and edits performed within Shotwell). > You can view the original version of any photo by pressing the Shift key > within Shotwell, and the Revert to Original command reverts back to the > original version. > > We've thought about more complex versioning schemes and are potentially > open to those, though it's very important to us to keep the user > experience simple, so we've made no decisions about this. See > http://trac.yorba.org/ticket/2474 . > > > > 3. Filesystem folder monitoring > > A big feature request, and I think people would really agree with me here > > after experiencing it - > > Monitoring of folders, aka "Watching folders for new images". > > use case: I add an image to a folder designated as a "watched folder" in > > shotwell, and shotwell automatically recognizes and imports this image on > > next startup. HUGELY important if you're going to be shifting around > your > > image files in any other way, which is one of my biggest gripes with > > F-Spot. > > i. Does it exist for shotwell? > > > > ii. Are there any plans for adding this in the future? > > > > Folder monitoring is not in 0.7, but we've just implemented this in the > trunk, so it will be in 0.8. Note that we auto-import from the library > directory only. I hope that in a future release we'll support multiple > watched folders. > > If you want to try this in the trunk, you need to specify --auto-import > on the command line when you run Shotwell (this option will go away > soon). See http://trac.yorba.org/ticket/2478 . > > cheers > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From take at nerd.fi Fri Sep 3 07:33:46 2010 From: take at nerd.fi (Take) Date: Fri, 03 Sep 2010 10:33:46 +0300 Subject: [Shotwell] Shotwell over NFS + shared access Message-ID: <4C80A4DA.4020305@nerd.fi> Hello. I recently installed shotwell and imported my photo directory. Even if shotwell isn't perfect (nor ready) yet I'm already quite impressed. Before this I haven't found any sofware which could've even managed to import my ~26000 photos. Here's some initial toughts of mine, I'm quite sure someone else has already suggested these, so if someone gets annoyed by 'repost' I'm sorry. However, even with shotwell there's this one design/ideology issue which isn't even near optimal on todays world. Every application, including shotwell, thinks that there's "My photos", not "Our photos". So, even if it's possible, the default setting is that there's no one else on same computer/network who'd want to access those family photos as well. Obviously that's a problem to balance between easy setup and additional features, but I'd really like to see support for some 'real' database in addition to sqlite. Currently I'm running shotwell on NFS-share, which kind-of-works, but I can't use shotwell simultaneously from multiple computers due to database access. The same scenario applies with multiuser-computer, since if user A has shotwell running and user B tries to open it in a new session it doesn't work either. Optimal solution would be to add setting/something for MySQL/PSql/Sqlite so that if user doesn't want (or can't) setup an real database sqlite would do and for "experienced" users it'd still be an option. Another issue I ran into, related to shared access, is that for some reason shotwell starts up _really_ slowly when I access database and photos over wifi-link & NFS. Startup takes several minutes and most of the time waiting there's little or no traffic at all on wlan0. I understand that ie. opening sqlite over slow(ish) link takes some time, but since there's no traffic I don't know what's taking so long. Startup progress goes up to 48% and stalls there for a good while. Most likely this would be solved with "real" database server instead of sqlite, but that's a bit annoying anyways. Anyways, keep up the good work! I really do like and appreciate the work of dev-team so far. Thank you all. -- Take From adam at yorba.org Fri Sep 3 17:05:16 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 03 Sep 2010 10:05:16 -0700 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C80A4DA.4020305@nerd.fi> References: <4C80A4DA.4020305@nerd.fi> Message-ID: <4C812ACC.2020100@yorba.org> Take, thanks for your thoughts, and I'm glad that you like Shotwell overall! It's true that Shotwell today is designed for the single-user case and does not work well when your library is on an NFS share or when several users run it on the same machine. Lots of users want to be able to share photos easily on a local network (or across the Internet), and we want to extend Shotwell to be able to handle that use case: see http://trac.yorba.org/ticket/1292 . That might involve using a 'real' database (e.g. MySQL) as you suggest and/or some sort of peer-to-peer communication between Shotwell instances; we haven't yet decided exactly how this will work. In any case, this feature won't be in the next release (0.8) but I hope we'll get to it in the next few releases since lots and lots of people want this. :) cheers adam On 09/03/2010 12:33 AM, Take wrote: > Hello. > > I recently installed shotwell and imported my photo directory. Even if > shotwell isn't perfect (nor ready) yet I'm already quite impressed. > Before this I haven't found any sofware which could've even managed to > import my ~26000 photos. Here's some initial toughts of mine, I'm quite > sure someone else has already suggested these, so if someone gets > annoyed by 'repost' I'm sorry. > > However, even with shotwell there's this one design/ideology issue which > isn't even near optimal on todays world. Every application, including > shotwell, thinks that there's "My photos", not "Our photos". So, even if > it's possible, the default setting is that there's no one else on same > computer/network who'd want to access those family photos as well. > > Obviously that's a problem to balance between easy setup and additional > features, but I'd really like to see support for some 'real' database in > addition to sqlite. Currently I'm running shotwell on NFS-share, which > kind-of-works, but I can't use shotwell simultaneously from multiple > computers due to database access. The same scenario applies with > multiuser-computer, since if user A has shotwell running and user B > tries to open it in a new session it doesn't work either. > > Optimal solution would be to add setting/something for MySQL/PSql/Sqlite > so that if user doesn't want (or can't) setup an real database sqlite > would do and for "experienced" users it'd still be an option. > > > Another issue I ran into, related to shared access, is that for some > reason shotwell starts up _really_ slowly when I access database and > photos over wifi-link& NFS. Startup takes several minutes and most of > the time waiting there's little or no traffic at all on wlan0. I > understand that ie. opening sqlite over slow(ish) link takes some time, > but since there's no traffic I don't know what's taking so long. Startup > progress goes up to 48% and stalls there for a good while. Most likely > this would be solved with "real" database server instead of sqlite, but > that's a bit annoying anyways. > > > Anyways, keep up the good work! I really do like and appreciate the work > of dev-team so far. Thank you all. > > From douglas.m.stanley at gmail.com Fri Sep 3 18:04:25 2010 From: douglas.m.stanley at gmail.com (Douglas Stanley) Date: Fri, 3 Sep 2010 14:04:25 -0400 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C812ACC.2020100@yorba.org> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> Message-ID: What about couchdb? It comes with every ubuntu desktop now, and I thought there are some pre-built libs to make it easy to access. Plus, as for "peer to peer" stuff, that seems to be what couchdb was designed for. You can synch your couch to another one remotely over plain http. Plus, you might be able to hook into Ubuntu One easier (contacts and what not are already stored in couchdb for sync'ing with ubuntu one). Just a thought. Doug On Fri, Sep 3, 2010 at 1:05 PM, Adam Dingle wrote: > Take, > > thanks for your thoughts, and I'm glad that you like Shotwell overall! > It's true that Shotwell today is designed for the single-user case and > does not work well when your library is on an NFS share or when several > users run it on the same machine. ?Lots of users want to be able to > share photos easily on a local network (or across the Internet), and we > want to extend Shotwell to be able to handle that use case: see > http://trac.yorba.org/ticket/1292 . ?That might involve using a 'real' > database (e.g. MySQL) as you suggest and/or some sort of peer-to-peer > communication between Shotwell instances; we haven't yet decided exactly > how this will work. ?In any case, this feature won't be in the next > release (0.8) but I hope we'll get to it in the next few releases since > lots and lots of people want this. ?:) > > cheers > adam > > On 09/03/2010 12:33 AM, Take wrote: >> Hello. >> >> I recently installed shotwell and imported my photo directory. Even if >> shotwell isn't perfect (nor ready) yet I'm already quite impressed. >> Before this I haven't found any sofware which could've even managed to >> import my ~26000 photos. Here's some initial toughts of mine, I'm quite >> sure someone else has already suggested these, so if someone gets >> annoyed by 'repost' I'm sorry. >> >> However, even with shotwell there's this one design/ideology issue which >> isn't even near optimal on todays world. Every application, including >> shotwell, thinks that there's "My photos", not "Our photos". So, even if >> it's possible, the default setting is that there's no one else on same >> computer/network who'd want to access those family photos as well. >> >> Obviously that's a problem to balance between easy setup and additional >> features, but I'd really like to see support for some 'real' database in >> addition to sqlite. Currently I'm running shotwell on NFS-share, which >> kind-of-works, but I can't use shotwell simultaneously from multiple >> computers due to database access. The same scenario applies with >> multiuser-computer, since if user A has shotwell running and user B >> tries to open it in a new session it doesn't work either. >> >> Optimal solution would be to add setting/something for MySQL/PSql/Sqlite >> so that if user doesn't want (or can't) setup an real database sqlite >> would do and for "experienced" users it'd still be an option. >> >> >> Another issue I ran into, related to shared access, is that for some >> reason shotwell starts up _really_ slowly when I access database and >> photos over wifi-link& ?NFS. Startup takes several minutes and most of >> the time waiting there's little or no traffic at all on wlan0. I >> understand that ie. opening sqlite over slow(ish) link takes some time, >> but since there's no traffic I don't know what's taking so long. Startup >> progress goes up to 48% and stalls there for a good while. Most likely >> this would be solved with "real" database server instead of sqlite, but >> that's a bit annoying anyways. >> >> >> Anyways, keep up the good work! I really do like and appreciate the work >> of dev-team so far. Thank you all. >> >> > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From take at nerd.fi Fri Sep 3 18:54:19 2010 From: take at nerd.fi (Take) Date: Fri, 03 Sep 2010 21:54:19 +0300 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C812ACC.2020100@yorba.org> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> Message-ID: <4C81445B.2030309@nerd.fi> On 09/03/2010 08:05 PM, Adam Dingle wrote: > http://trac.yorba.org/ticket/1292 . That might involve using a 'real' > database (e.g. MySQL) as you suggest and/or some sort of peer-to-peer > communication between Shotwell instances; we haven't yet decided exactly > how this will work. In any case, this feature won't be in the next By all means I'm not an expert in any level with this, but based on what I found this should be possible to achieve with just sqlite. Unless I've understood something badly wrong, the support has been available since version 3.0.0 (http://www.sqlite.org/lockingv3.html). I have some programming experience with Perl and PHP so I just might try this one out if I found any spare time, or atleast check if that's possible with two sqlite3 processes accessing the same database. HTH. -- Take From brunogirin at gmail.com Sat Sep 4 14:30:26 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sat, 04 Sep 2010 15:30:26 +0100 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C812ACC.2020100@yorba.org> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> Message-ID: <1283610626.1783.22.camel@nuuk> On Fri, 2010-09-03 at 10:05 -0700, Adam Dingle wrote: > Take, > > thanks for your thoughts, and I'm glad that you like Shotwell overall! > It's true that Shotwell today is designed for the single-user case and > does not work well when your library is on an NFS share or when several > users run it on the same machine. Lots of users want to be able to > share photos easily on a local network (or across the Internet), and we > want to extend Shotwell to be able to handle that use case: see > http://trac.yorba.org/ticket/1292 . That might involve using a 'real' > database (e.g. MySQL) as you suggest and/or some sort of peer-to-peer > communication between Shotwell instances; we haven't yet decided exactly > how this will work. In any case, this feature won't be in the next > release (0.8) but I hope we'll get to it in the next few releases since > lots and lots of people want this. :) I think the first thing to do would be to de-couple the Shotwell storage layer into an external library. I know there is a ticket about that somewhere but I can't find it. That would mean creating an official API for it, after which it is a lot easier to implement sharing and server options. Also note that the DB only contains the meta-data so sync'ing the DB would not actually sync the files; in addition, you may not want to sync all the files: for instance, I don't have enough disk space on my laptop to store a copy of all the photographs I have on my server so I'd like to use the server as an archive and the laptop as a working repository where I only have the latest photos. I put together a simple diagram that shows how a de-coupled store could work to provide the ability to share photos between users on the same or different computers and potentially using different databases to store the meta-data (OO.o Draw format): http://ubuntuone.com/p/EtI/ This would also enable things like: * other applications (like Lombard) to have access to the media store * the media store to be installed on a server with no GUI and act as a media server * the inclusion of non-Shotwell stores (such as a UPnP server or a Flickr pool) Of course this opens up a whole new level of complexity, such as how do you search for a given tag across multiple stores? And should you be able to assign your own tags to photos that are stored into a store you're not the owner of? Cheers, Bruno From brunogirin at gmail.com Sun Sep 5 19:35:00 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sun, 05 Sep 2010 20:35:00 +0100 Subject: [Shotwell] Quick intro to the alien database import code Message-ID: <1283715300.7462.6.camel@nuuk> Hi all, Having written the import from F-Spot feature for Shotwell 0.7, I thought it'd be a good idea to write an introduction to the generic classes that were produced along the way and that, in theory, should make it easy for other people to contribute other types of import features. You'll find it all here: http://brunogirin.blogspot.com/2010/09/adding-support-for-alien-database.html So if anybody feels like writing an "import from Picasa" feature, you should find everything you need to get started in that post. If there's anything that's unclear or missing, please tell me as eventually I'd like to transform it into a piece that's of good enough quality to be included in the Shotwell wiki. Cheers, Bruno From take at nerd.fi Mon Sep 6 08:42:00 2010 From: take at nerd.fi (Take) Date: Mon, 06 Sep 2010 11:42:00 +0300 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <1283610626.1783.22.camel@nuuk> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> Message-ID: <4C84A958.8060602@nerd.fi> On 09/04/2010 05:30 PM, Bruno Girin wrote: > options. Also note that the DB only contains the meta-data so sync'ing > the DB would not actually sync the files; in addition, you may not want > to sync all the files: for instance, I don't have enough disk space on The solution I had in mind doesn't involve any kind of "sync", since files are on NFS/Samba/whatever and database connection is made via an actual TCP-socket (ie. MySQL). This way any computer on (local) network could access the files and database simultaneously. IMO there should anyways be just one shared storage for actual files, since, as you know, it's quite huge PITA to maintain sync for multiple storages. And, a leap to the future, when shotwell is ported for ie. maemo/iphone/android the storage can't be shared (or atleast my N900 can't hold my ~150GB photo storage ;)) However, it'd be great if there was an setting for 'root directory', so if I have machine A which has NFS-mount on /mnt/Photo and machine B where that same mount is on /media/Photo I could just tell shotwell that root directory is ie. /media/Photo and everything in database would be related to that. > Of course this opens up a whole new level of complexity, such as how do > you search for a given tag across multiple stores? And should you be > able to assign your own tags to photos that are stored into a store > you're not the owner of? That'd be really neat. And with reasonable API I suppose that could be achieved as well. That's "a bit" more complex than what I had in mind, but I could use that kind of system as well. IE. I have an folder on my ~/public_html which contains photos and simple perl-wrapper around that to maintain thumbnails etc. and with that kind of API I could build 'data storage' by myself for uploading photos for that perl-thingy I have. However this (again) adds more complexity. If photos are stored on local hard drive in RAW -format and the same photo is stored to flickr in JPEG (maybe with watermark) etc, how these relations and 'duplicates' are handled? TGhat "shotwell server" is anyways a neat idea. Via that it'd be possible to access ie. scaled version of the pictures over slow WAN-link or for small devices. I'm actually not quite sure if that should even be on shotwell-project, or should there be a separate project, 'shotwell-server', so that the ease of installation for simple environment would stay the same. Anyways, the first step towards this kind of approach is (IMO) the database API. I'd be more than happy to see shared database in the first place since actual file storage is quite simple to share over LAN (and even over WAN, with obvious limitations with transfer rate etc). There's a lots of issues around the 'shotwell-server', and that's not the topic on this thread, but if there'll be more discussion around that I'll be happy to take part in that. -- Take From florian at manach.fr Mon Sep 6 14:17:52 2010 From: florian at manach.fr (Florian Manach) Date: Mon, 06 Sep 2010 16:17:52 +0200 Subject: [Shotwell] Sharpening tool Message-ID: <1283782672.11722.1.camel@florian-desktop> Hi everyone. I just wanted to know if advanced retouching and editing tools like "Sharpenning" are planned for the next versions. Thx in advance. Florian From B.Candler at pobox.com Mon Sep 6 19:28:22 2010 From: B.Candler at pobox.com (Brian Candler) Date: Mon, 6 Sep 2010 20:28:22 +0100 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C84A958.8060602@nerd.fi> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> Message-ID: <20100906192822.GA5731@talktalkplc.com> On Mon, Sep 06, 2010 at 11:42:00AM +0300, Take wrote: > The solution I had in mind doesn't involve any kind of "sync", since > files are on NFS/Samba/whatever and database connection is made via an > actual TCP-socket (ie. MySQL). This way any computer on (local) network > could access the files and database simultaneously. > > IMO there should anyways be just one shared storage for actual files, > since, as you know, it's quite huge PITA to maintain sync for multiple > storages. That's one usage model. In my case I like to sync files to my laptop using "unison" - I have fast off-line access to them, and it acts as a backup. Having the tags within the image files would probably be the best fit for me, even though retagging a photo would cause unison to copy the whole file across. Each side would have to notice when a file had changed, and update its database accordingly. To take things to the other extreme: use couchdb, not only for the metadata, but for the photos themselves (as binary attachments). You could then point shotwell either at a local couchdb instance, or a remote couchdb server. It solves the separation of images from metadata, and backup to UbuntuOne would be a bonus. Unfortunately, whatever you do isn't going to please everyone :-( Regards, Brian. From podollb at gmail.com Tue Sep 7 03:09:32 2010 From: podollb at gmail.com (Ben Podoll) Date: Mon, 6 Sep 2010 22:09:32 -0500 Subject: [Shotwell] support to publish to blogspot (blogger) Message-ID: Is there a way (or is it in the roadmap) to publish to blogspot.com(blogger)? We've been using Picasa for the last few years since we never really liked F-Spot, and we wanted easy support to publish to our blogs. I really like how Shotwell is coming along, and support for publishing to blogspot would be ideal. Thoughts/Comments? From valentin.david at gmail.com Tue Sep 7 12:42:48 2010 From: valentin.david at gmail.com (Valentin David) Date: Tue, 7 Sep 2010 14:42:48 +0200 Subject: [Shotwell] Using GNU Autotools In-Reply-To: References: Message-ID: I take the freedom to send you a patch to make use of the GNU Autotools (i.e. Automake, Autoconf and Libtool) for the project Shotwell. http://www.valentindavid.com/files/shotwell-autotools.patch The integration of Vala into Automake is still fishy, and would not work properly for your project. Actually your project was an interesting example on the limitations of Vala integration into Automake. So in the patch here, the support is made by hand. However I will try to file bugs to the Automake project so that you will be able to use easily Vala with the future versions of Automake. The integration of gettext is also weird in Automake. But at least it works. However seeing their mailing list it will probably easier to use it in the future. I noticed that some languages had errors that gettext would report. I fixed jp.po. I also disabled bad entries in pl.po. This last one should be carefully checked. I am not really used with using gettext, and I had no ideas how to fix those entries. Automake proposes a nice way add a test-suite. Specially since 1.11 (with colors and in parallel). I recommend you start to use it. (I think it answers your #1068). If you have an example of test case you want to add, I can show you how. The patch would certainly work with Autoconf 2.65. But I set the requirement to 2.67. I advise you to use recent versions of the Autotools. After all it distributes all it needs in the tarball, so anybody who wants to compile from the source tarball does not need to have the autotools. Except if they desire to change the makefiles or the configuration script. So no point to lower the requirements on them for portability. To make a distribution tarball, it is advised to use "make -j distcheck" and fix any problem until you get a nice message like that: ====================================================== shotwell-0.7.1+trunk archives ready for distribution: shotwell-0.7.1+trunk.tar.gz shotwell-0.7.1+trunk.tar.bz2 ====================================================== Then you know that the package is sane. For example someone might want to compile in a separate directory from the source directory. And this works smoothly with Automake. Also you are sure that all your clean rules are right. And all your tests succeeded. To test the patch: $ svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell $ cd shotwell $?wget -O - http://www.valentindavid.com/files/shotwell-autotools.patch | patch -p0 $ chmod +x bootstrap # the patch does not do it, but a svn commit would save it $ ./bootstrap $?./configure $ make -j $ make -j distcheck By default it uses silent rules (I think it is nice like that), so that you do not see very complex command lines. If you wish to see what is called use: make V=1 I did not try it on mingw, but I tried to make the rules and configuration so that it works as the old Makefile. The debian scripts should probably be updated. Feel free to ask me to help fixing the rest if you desire to apply the patch. I can do the same for gexiv2 if you wish. Best regards, -- Valentin David valentin.david at gmail.com From adam at yorba.org Tue Sep 7 17:11:38 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 07 Sep 2010 10:11:38 -0700 Subject: [Shotwell] support to publish to blogspot (blogger) In-Reply-To: References: Message-ID: <4C86724A.3010100@yorba.org> Ben, that's a reasonable idea, so I've created a ticket for this at http://trac.yorba.org/ticket/2522 . I hope that within the next few releases Shotwell will support plugins which can implement exporting to various hosting sites (http://trac.yorba.org/ticket/182), which may make this easier. adam On 09/06/2010 08:09 PM, Ben Podoll wrote: > Is there a way (or is it in the roadmap) to publish to > blogspot.com(blogger)? We've been using Picasa for the last few years > since we never > really liked F-Spot, and we wanted easy support to publish to our blogs. I > really like how Shotwell is coming along, and support for publishing to > blogspot would be ideal. Thoughts/Comments? > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Tue Sep 7 17:32:57 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 07 Sep 2010 10:32:57 -0700 Subject: [Shotwell] Sharpening tool In-Reply-To: <1283782672.11722.1.camel@florian-desktop> References: <1283782672.11722.1.camel@florian-desktop> Message-ID: <4C867749.2080309@yorba.org> Florian, sharpening (http://trac.yorba.org/ticket/690) is currently at priority 'high' in our ticket database, which means we think there's some chance it will make 0.8, though it's not on our top list of features for 0.8 (which are listed on our Wiki page at http://trac.yorba.org/wiki/Shotwell). If it doesn't make 0.8 then I think it will be a strong candidate for 0.9. Patches gladly accepted. :) adam On 09/06/2010 07:17 AM, Florian Manach wrote: > Hi everyone. > > I just wanted to know if advanced retouching and editing tools like > "Sharpenning" are planned for the next versions. > > Thx in advance. > > Florian > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From valentin.david at gmail.com Tue Sep 7 01:03:31 2010 From: valentin.david at gmail.com (Valentin David) Date: Tue, 7 Sep 2010 03:03:31 +0200 Subject: [Shotwell] Using GNU Autotools Message-ID: I take the freedom to send you a patch to make use of the GNU Autotools (i.e. Automake, Autoconf and Libtool) for the project Shotwell. The integration of Vala into Automake is still fishy, and would not work properly for your project. Actually your project was an interesting example on the limitations of Vala integration into Automake. So in the patch here, the support is made by hand. However I will try to file bugs to the Automake project so that you will be able to use easily Vala with the future versions of Automake. The integration of gettext is also weird in Automake. But at least it works. However seeing their mailing list it will probably easier to use it in the future. I noticed that some languages had errors that gettext would report. I fixed jp.po. I also disabled bad entries in pl.po. This last one should be carefully checked. I am not really used with using gettext, and I had no ideas how to fix those entries. Automake proposes a nice way add a test-suite. Specially since 1.11 (with colors and in parallel). I recommend you start to use it. (I think it answers your #1068). If you have an example of test case you want to add, I can show you how. The patch would certainly work with Autoconf 2.65. But I set the requirement to 2.67. I advise you to use recent versions of the Autotools. After all it distributes all it needs in the tarball, so anybody who wants to compile from the source tarball does not need to have the autotools. Except if they desire to change the makefiles or the configuration script. So no point to lower the requirements on them for portability. To make a distribution tarball, it is advised to use "make -j distcheck" and fix any problem until you get a nice message like that: ====================================================== shotwell-0.7.1+trunk archives ready for distribution: shotwell-0.7.1+trunk.tar.gz shotwell-0.7.1+trunk.tar.bz2 ====================================================== Then you know that the package is sane. For example someone might want to compile in a separate directory from the source directory. And this works smoothly with Automake. Also you are sure that all your clean rules are right. And all your tests succeeded. To test the patch: svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell cd shotwell patch -p0 <../shotwell-autotools.patch chmod +x bootstrap # the patch does not do it, but a svn commit would save it ./bootstrap ./configure make -j make -j distcheck By default it uses silent rules (I think it is nice like that), so that you do not see very complex command lines. If you wish to see what is called use: make V=1 I did not try it on mingw, but I tried to make the rules and configuration so that it works as the old Makefile. The debian scripts should probably be updated. Feel free to ask me to help fixing the rest if you desire to apply the patch. I can do the same for gexiv2 if you wish. Best regards, -- Valentin David valentin.david at gmail.com From robert at rycee.net Tue Sep 7 18:33:01 2010 From: robert at rycee.net (Robert Helgesson) Date: Tue, 7 Sep 2010 18:33:01 +0000 (UTC) Subject: [Shotwell] Shotwell over NFS + shared access References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> <20100906192822.GA5731@talktalkplc.com> Message-ID: Hello, Just a quick note. > Having the tags within the image files would probably be the best fit for > me, even though retagging a photo would cause unison to copy the whole file > across. Each side would have to notice when a file had changed, and update > its database accordingly. I used to manage my photos using a program called JBrout that does write tags to the actual JPEG files directly. I also use unison to synchronize my photos to a central location. My observation is that synchronizing changed tags was always quite quick. I assume that changing the tags only alter a very small portion of the file. So, since unison uses the rsync algorithm, it will only transfer these changes and not the entire file. Cheers /Robert From adam at yorba.org Tue Sep 7 20:38:02 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 07 Sep 2010 13:38:02 -0700 Subject: [Shotwell] Using GNU Autotools In-Reply-To: References: Message-ID: <4C86A2AA.90400@yorba.org> Valentin, obviously you've put a lot of work into this patch, and we appreciate that. The fact that Shotwell doesn't use autotools, isn't a bug, though - it's a feature. :) The Shotwell team explicitly decided not to use autotools for our project because we find autotools to be hackish, bloated, and slow. We really like the fact that you can check out Shotwell and build immediately, which would not be possible with autotools. We've tried hard to write our Makefile to conform to the GNU Makefile conventions (http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html) so that it is as compatible as possible with those generated by autotools. So it's not obvious to me what problem we would solve in Shotwell by switching to autotools - if our Makefile is currently limiting packagers in some way, please let me know and we can try to fix it. Some other people would also like to see GNOME move away from Autotools. You can read one such proposal here: http://aruiz.synaptia.net/siliconisland/2010/03/buildj-build-configuration-for-the-mases.html Finally, I'll say that we're not opposed to build systems in general - we just don't like Autotools. If you wanted to submit a patch to make Shotwell build with waf, for example, I think that might be fine. cheers adam On 09/07/2010 05:42 AM, Valentin David wrote: > I take the freedom to send you a patch to make use of the GNU > Autotools (i.e. Automake, Autoconf and Libtool) for the project > Shotwell. > > http://www.valentindavid.com/files/shotwell-autotools.patch > > The integration of Vala into Automake is still fishy, and would not > work properly for your project. Actually your project was an > interesting example on the limitations of Vala integration into > Automake. So in the patch here, the support is made by hand. However I > will try to file bugs to the Automake project so that you will be able > to use easily Vala with the future versions of Automake. > > The integration of gettext is also weird in Automake. But at least it > works. However seeing their mailing list it will probably easier to > use it in the future. I noticed that some languages had errors that > gettext would report. I fixed jp.po. I also disabled bad entries in > pl.po. This last one should be carefully checked. I am not really used > with using gettext, and I had no ideas how to fix those entries. > > Automake proposes a nice way add a test-suite. Specially since 1.11 > (with colors and in parallel). I recommend you start to use it. (I > think it answers your #1068). If you have an example of test case you > want to add, I can show you how. > > The patch would certainly work with Autoconf 2.65. But I set the > requirement to 2.67. I advise you to use recent versions of the > Autotools. After all it distributes all it needs in the tarball, so > anybody who wants to compile from the source tarball does not need to > have the autotools. Except if they desire to change the makefiles or > the configuration script. So no point to lower the requirements on > them for portability. > > To make a distribution tarball, it is advised to use "make -j > distcheck" and fix any problem until you get a nice message like that: > > ====================================================== > shotwell-0.7.1+trunk archives ready for distribution: > shotwell-0.7.1+trunk.tar.gz > shotwell-0.7.1+trunk.tar.bz2 > ====================================================== > > Then you know that the package is sane. For example someone might want > to compile in a separate directory from the source directory. And this > works smoothly with Automake. Also you are sure that all your clean > rules are right. And all your tests succeeded. > > To test the patch: > > $ svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell > $ cd shotwell > $ wget -O - http://www.valentindavid.com/files/shotwell-autotools.patch > | patch -p0 > $ chmod +x bootstrap # the patch does not do it, but a svn commit would save it > $ ./bootstrap > $ ./configure > $ make -j > $ make -j distcheck > > > By default it uses silent rules (I think it is nice like that), so > that you do not see very complex command lines. If you wish to see > what is called use: > make V=1 > > I did not try it on mingw, but I tried to make the rules and > configuration so that it works as the old Makefile. The debian scripts > should probably be updated. Feel free to ask me to help fixing the > rest if you desire to apply the patch. > > I can do the same for gexiv2 if you wish. > > Best regards, > From lucas at yorba.org Tue Sep 7 20:55:33 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 7 Sep 2010 13:55:33 -0700 Subject: [Shotwell] support to publish to blogspot (blogger) In-Reply-To: <4C86724A.3010100@yorba.org> References: <4C86724A.3010100@yorba.org> Message-ID: Hi Ben, Since Blogger and Picasa Web Albums are both horses in the Google stable, they're exceptionally well integrated. If you upload a photo to Picasa Web Albums, it's trivial to publish it to a Blogger blog; see http://picasa.google.com/support/bin/answer.py?hl=en&answer=31292 for more information. Since version 0.5, Shotwell has supported uploading photos to Picasa Web Albums. Regards, Lucas From lucas at yorba.org Tue Sep 7 21:04:45 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 7 Sep 2010 14:04:45 -0700 Subject: [Shotwell] support to publish to blogspot (blogger) In-Reply-To: References: <4C86724A.3010100@yorba.org> Message-ID: Hi Ben, Sorry. The link I sent you was actually instructions for integrating the Picasa desktop application with Blogger; instructions for integrating Picasa Web Albums with blogger can be found here: http://picasa.google.com/support/bin/answer.py?hl=en&answer=150419. Cheers, Lucas From kenny3794 at gmail.com Wed Sep 8 03:09:19 2010 From: kenny3794 at gmail.com (Kenneth Jernigan) Date: Tue, 7 Sep 2010 23:09:19 -0400 Subject: [Shotwell] Picasa Upload Fail Message-ID: I see someone created a new ticket 2530 for a similar problem. I've connected via Shotwell to my Picasa account and can see existing albums and create new albums. But when Shotwell tries to upload a picture, Shotwell crashes without any error message. I have been able to publish to Facebook and export images as well as edit photos without any problems. I am running Ubuntu Lucid and Shotwell 0.7.1. Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised). However, I am running with the Shotwell database on a permanent NTFS partition. The Shotwell database folder is hard-linked to the NTFS partition folder. As for my photos, they are stored in ~/Pictures, which is a hard link to a different permanent NTFS partition. The NTFS partitions are from legacy dual-boot installs which I've not entirely purged. I do share the database and pictures directory between two users, but I always ensure that only one of us is running Shotwell. I doubt this setup attributes to the problem, but wanted to share it. Let me know if there is anything I can do to provide debug information. Ken From kenny3794 at gmail.com Wed Sep 8 03:32:54 2010 From: kenny3794 at gmail.com (Kenneth Jernigan) Date: Tue, 7 Sep 2010 23:32:54 -0400 Subject: [Shotwell] Picasa Upload Fail In-Reply-To: References: Message-ID: I owe a correction and more information. The database file ended up on the root drive (a ReiserFS partition...). Anyhow, I found the method to call the Shotwell with the debug commands. And here is what I receive: L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ... L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema version 8 created by app version 0.7.0 L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to Gtk.main() ** ERROR **: AppDirs.vala:106: Unable to create temporary directory /home/kjernigan/.shotwell/tmp/13887 aborting... Aborted The folder /home/kjernigan/.shotwell links to the folder /usr/share/shotwell/.shotwell Both users are members of a group that has full read/write access to the /usr/share/shotwell/.shotwell directory. Any ideas? Thanks, Ken On Tue, Sep 7, 2010 at 11:09 PM, Kenneth Jernigan wrote: > I see someone created a new ticket 2530 for a similar problem. I've > connected via Shotwell to my Picasa account and can see existing albums and > create new albums. But when Shotwell tries to upload a picture, Shotwell > crashes without any error message. I have been able to publish to Facebook > and export images as well as edit photos without any problems. I am running > Ubuntu Lucid and Shotwell 0.7.1. > > Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised). > However, I am running with the Shotwell database on a permanent NTFS > partition. The Shotwell database folder is hard-linked to the NTFS > partition folder. As for my photos, they are stored in ~/Pictures, which is > a hard link to a different permanent NTFS partition. The NTFS partitions > are from legacy dual-boot installs which I've not entirely purged. I do > share the database and pictures directory between two users, but I always > ensure that only one of us is running Shotwell. I doubt this setup > attributes to the problem, but wanted to share it. > > Let me know if there is anything I can do to provide debug information. > > Ken > From mahfiaz at gmail.com Wed Sep 8 05:37:02 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 08 Sep 2010 08:37:02 +0300 Subject: [Shotwell] Picasa Upload Fail In-Reply-To: References: Message-ID: <1283924222.29034.3.camel@antiloop> ?hel kenal p?eval, T, 2010-09-07 kell 23:32, kirjutas Kenneth Jernigan: > I owe a correction and more information. The database file ended up on the > root drive (a ReiserFS partition...). Anyhow, I found the method to call > the Shotwell with the debug commands. And here is what I receive: > > L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ... > L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema > version 8 created by app version 0.7.0 > L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to > Gtk.main() > > ** ERROR **: AppDirs.vala:106: Unable to create temporary directory > /home/kjernigan/.shotwell/tmp/13887 > aborting... > Aborted > > > > The folder /home/kjernigan/.shotwell links to the folder > /usr/share/shotwell/.shotwell > > Both users are members of a group that has full read/write access to the > /usr/share/shotwell/.shotwell directory. Any ideas? You probably have already checked this, but do the users have rw access to /usr/share/shotwell/.shotwell/tmp/ too? Btw, using /usr for personal data (or even links for that) is very uncommon, /var is usually used for that, and /usr only for program files. Mattias From adam at yorba.org Wed Sep 8 10:25:40 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 08 Sep 2010 03:25:40 -0700 Subject: [Shotwell] Picasa Upload Fail In-Reply-To: References: Message-ID: <4C8764A4.90809@yorba.org> Ken, thanks for your bug report and helpful sleuthing. I just looked at AppDirs.vala and saw that if Shotwell is unable to create any of several directories under .shotwell then it will exit unexpectedly. Instead, in this situation we should display a dialog with an error message and then exit. I've ticketed this at http://trac.yorba.org/ticket/2532 . I hope we can fix this for the upcoming 0.7.2 release. And as for just why Shotwell can't create /home/kjernigan/.shotwell/tmp/13887 in your particular case, well, I don't know. I'd stare at the file/directory permissions very carefully. :) cheers adam On 09/07/2010 08:32 PM, Kenneth Jernigan wrote: > I owe a correction and more information. The database file ended up on the > root drive (a ReiserFS partition...). Anyhow, I found the method to call > the Shotwell with the debug commands. And here is what I receive: > > L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ... > L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema > version 8 created by app version 0.7.0 > L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to > Gtk.main() > > ** ERROR **: AppDirs.vala:106: Unable to create temporary directory > /home/kjernigan/.shotwell/tmp/13887 > aborting... > Aborted > > > > The folder /home/kjernigan/.shotwell links to the folder > /usr/share/shotwell/.shotwell > > Both users are members of a group that has full read/write access to the > /usr/share/shotwell/.shotwell directory. Any ideas? > > Thanks, > Ken > > On Tue, Sep 7, 2010 at 11:09 PM, Kenneth Jerniganwrote: > > >> I see someone created a new ticket 2530 for a similar problem. I've >> connected via Shotwell to my Picasa account and can see existing albums and >> create new albums. But when Shotwell tries to upload a picture, Shotwell >> crashes without any error message. I have been able to publish to Facebook >> and export images as well as edit photos without any problems. I am running >> Ubuntu Lucid and Shotwell 0.7.1. >> >> Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised). >> However, I am running with the Shotwell database on a permanent NTFS >> partition. The Shotwell database folder is hard-linked to the NTFS >> partition folder. As for my photos, they are stored in ~/Pictures, which is >> a hard link to a different permanent NTFS partition. The NTFS partitions >> are from legacy dual-boot installs which I've not entirely purged. I do >> share the database and pictures directory between two users, but I always >> ensure that only one of us is running Shotwell. I doubt this setup >> attributes to the problem, but wanted to share it. >> >> Let me know if there is anything I can do to provide debug information. >> >> Ken >> >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From florian at manach.fr Thu Sep 9 15:00:26 2010 From: florian at manach.fr (=?utf-8?B?RmxvcmlhbiBNYW5hY2g=?=) Date: Thu, 09 Sep 2010 17:00:26 +0200 Subject: [Shotwell] =?utf-8?q?Export_pictures_misorientated?= Message-ID: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> Hi, I think I found a bug yesterday. I took portraits with my d90 wich store the orientation in education and imported them into sw, retouch and exported them as files on my desktop. Problem is : the thumbnail of the exported file is good but the actual image seems to be stored in the wrong orientation. When I upload this file in Facebook or when I open it in the Gimp, the image is shown in landscape orientation. -- Cordialement, Florian Manach From mahfiaz at gmail.com Thu Sep 9 15:13:07 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Thu, 09 Sep 2010 18:13:07 +0300 Subject: [Shotwell] Export pictures misorientated In-Reply-To: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> References: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> Message-ID: <1284045187.2012.492.camel@antiloop> ?hel kenal p?eval, N, 2010-09-09 kell 17:00, kirjutas Florian Manach: > Hi, > > I think I found a bug yesterday. > > I took portraits with my d90 wich store the orientation in education and imported them into sw, retouch and exported them as files on my desktop. > > Problem is : the thumbnail of the exported file is good but the actual image seems to be stored in the wrong orientation. > > When I upload this file in Facebook or when I open it in the Gimp, the image is shown in landscape orientation. JPG files can contain EXIF data, which specifies it's orientation. This is good, because JPEG is lossy format and every time you reencode it, you loose some information. Doing real rotate in file is not possible without reencoding. The problem is, not all software can handle EXIF rotate right. But GIMP can, it asks on opening, whether to rotate the image or not (since it has to reencode it anyway). Mattias > > -- > Cordialement, > Florian Manach > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From mahfiaz at gmail.com Thu Sep 9 15:15:07 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Thu, 09 Sep 2010 18:15:07 +0300 Subject: [Shotwell] XMP files outside photo Message-ID: <1284045307.2012.496.camel@antiloop> I found a new string from F-Spot today: "Never modify image files.\n" "Write XMP files next to the images instead." This option might be worth considering for Shotwell as well, at least for importing. Best regard Mattias From adam at yorba.org Thu Sep 9 15:48:12 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 09 Sep 2010 08:48:12 -0700 Subject: [Shotwell] XMP files outside photo In-Reply-To: <1284045307.2012.496.camel@antiloop> References: <1284045307.2012.496.camel@antiloop> Message-ID: <4C8901BC.8090304@yorba.org> Yes - we've thought about this too. See this ticket: http://trac.yorba.org/ticket/1879 adam On 09/09/2010 08:15 AM, Mattias P?ldaru wrote: > I found a new string from F-Spot today: > "Never modify image files.\n" > "Write XMP files next to the images instead." > > This option might be worth considering for Shotwell as well, at least > for importing. > > Best regard > Mattias > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From zbr at ioremap.net Thu Sep 9 15:16:08 2010 From: zbr at ioremap.net (Evgeniy Polyakov) Date: Thu, 9 Sep 2010 19:16:08 +0400 Subject: [Shotwell] [PATCH] add support for Yandex.Fotki web photo hosting Message-ID: <20100909151608.GA32399@ioremap.net> Hi. Attached patch adds support for Yandex.Fotki photo hosting site, which is the biggest photo hosting in Russia and east Europe, it has about 2 millions of users and I believe quite a few of them use Linux. There are more than 500 Tb of photos already. Anyway, having Yandex.Fotki support in Shotwell will be a good stimulus to start using Linux :) Or maybe not, who knows. Patch is very non-intrusive for Shotwell core, it just adds another class construction into web publishing process, generic set/load/clear gconf helpers and json-glib-1.0 dep in makefile (this lib is already installed in glib package require by Shotwell). What we can: * upload photos into existing album * create album if needed * set access permissions as well as XXX/hide original/forbid comments metadata flags * upload photos with local tags * set local tag which prevents upload (to eliminate copies, one can remove tag and upload will succeed of course) * use OAuth 2.0 for authorization (using embedded webkit toolkit to request tokens if they are missed as well as allowing to register new user just from Shotwell) * cache username/tokens in gconf There is a small caveat thogh: Yandex did not yet release OAuth for photos, so I use 'undocumented' server names and client ids. One can edit special gconf keys to add proper strings which will change server names and client id. When OAuth for photo hosting will be released for public I will send updated patch to change default names of course. This is just for the case that you will suddenly make a new release, which will miss Yandex.Fotki functionality :) Please review, comment and apply. Thank you. Index: src/Config.vala =================================================================== --- src/Config.vala (revision 2145) +++ src/Config.vala (working copy) @@ -287,6 +287,21 @@ return get_string("/apps/shotwell/sharing/picasa/auth_token"); } + public string? get_gconf_string(string id, string key) { + return get_string(_("/apps/shotwell/sharing/%s/%s").printf(id, key)); + } + + public void set_gconf_string(string id, string key, string value) { + set_string(_("/apps/shotwell/sharing/%s/%s").printf(id, key), value); + } + + public void unset_gconf_string(string id, string key) { + try { + client.recursive_unset(_("/apps/shotwell/sharing/%s/%s").printf(id, key), GConf.UnsetFlags.NAMES); + } catch (GLib.Error err) { + } + } + public bool set_printing_content_layout(int layout_code) { return set_int("/apps/shotwell/printing/content_layout", layout_code + 1); } Index: src/WebConnectors.vala =================================================================== --- src/WebConnectors.vala (revision 2145) +++ src/WebConnectors.vala (working copy) @@ -1094,6 +1094,7 @@ result += "Facebook"; result += "Flickr"; result += "Picasa Web Albums"; + result += "Yandex.Fotki"; return result; } @@ -1105,6 +1106,8 @@ return new FlickrConnector.Interactor(host); } else if (service_name == "Picasa Web Albums") { return new PicasaConnector.Interactor(host); + } else if (service_name == "Yandex.Fotki") { + return new YandexConnector.Interactor(host); } else { error("ServiceInteractor: unsupported service '%s'", service_name); } Index: src/YandexConnector.vala =================================================================== --- src/YandexConnector.vala (revision 0) +++ src/YandexConnector.vala (revision 0) @@ -0,0 +1,871 @@ +/* Copyright 2010+ Evgeniy Polyakov + * + * This software is licensed under the GNU LGPL (version 2.1 or later). + * See the COPYING file in this distribution. + */ + +#if !NO_PUBLISHING + +namespace YandexConnector { + private const string SERVICE_WELCOME_MESSAGE = _("You are not currently logged into Yandex.Fotki."); + private const string RESTART_ERROR_MESSAGE = _("You have already logged in and out of Yandex.Fotki during this Shotwell session.\nTo continue publishing to Yandex.Fotki, quit and restart Shotwell, then try publishing again."); + + private string client_id; + private string auth_host; + private string service_host; + + private string service_url; + + private const string yandex_upload_tag = "yandex_uploaded"; + + public class YandexLoginWelcomePane : PublishingDialogPane { + private Gtk.Button login_button; + private Gtk.Entry username_entry; + + public signal void login_requested(string text); + + private void on_login_clicked() + { + login_requested(username_entry.text); + } + + public YandexLoginWelcomePane(string service_welcome_message) { + Gtk.SeparatorToolItem top_space = new Gtk.SeparatorToolItem(); + top_space.set_draw(false); + Gtk.SeparatorToolItem bottom_space = new Gtk.SeparatorToolItem(); + bottom_space.set_draw(false); + add(top_space); + + Gtk.Table content_layouter = new Gtk.Table(2, 1, false); + + Gtk.Label not_logged_in_label = new Gtk.Label(""); + not_logged_in_label.set_use_markup(true); + not_logged_in_label.set_markup(service_welcome_message); + not_logged_in_label.set_line_wrap(true); + not_logged_in_label.set_size_request(PublishingDialog.STANDARD_CONTENT_LABEL_WIDTH, -1); + content_layouter.attach(not_logged_in_label, 0, 1, 0, 1, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, 6, 0); + not_logged_in_label.set_size_request(PublishingDialog.STANDARD_CONTENT_LABEL_WIDTH, 112); + not_logged_in_label.set_alignment(0.5f, 0.0f); + + login_button = new Gtk.Button.with_mnemonic(_("_Login")); + login_button.set_size_request(PublishingDialog.STANDARD_ACTION_BUTTON_WIDTH, -1); + login_button.clicked.connect(on_login_clicked); + + username_entry = new Gtk.Entry(); + Gtk.Label username_label = new Gtk.Label("Username"); + + auth_host = "oauth.morelia.yandex.ru"; + service_host = "fimp.apodora.yandex.ru"; + client_id = "ce22bf30fdbb413fa71436295fe803d1"; + + var auth = yandex_session.load_auth_host(); + if (auth != null) + auth_host = auth; + + var service = yandex_session.load_service_host(); + if (service != null) + service_host = service; + + var cid = yandex_session.load_client_id(); + if (cid != null) + client_id = cid; + + var username = yandex_session.load_username(); + if (username != null) + username_entry.set_text(username); + + service_url =_("http://%s/api/users/").printf(service_host); + + var hbox = new Gtk.HBox (false, 20); + hbox.pack_start(username_label, false, true, 0); + hbox.pack_start(username_entry, false, true, 0); + hbox.pack_start(login_button, false, true, 0); + + Gtk.Alignment login_button_aligner = new Gtk.Alignment(0.5f, 0.5f, 0.0f, 0.0f); + login_button_aligner.add(hbox); + + content_layouter.attach(login_button_aligner, 0, 1, 1, 2, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, 6, 0); + add(content_layouter); + + add(bottom_space); + bottom_space.set_size_request(-1, 112); + } + } + + public class yandex_transaction: RESTTransaction { + private void add_headers(yandex_session session) + { + if (session.is_authenticated()) + add_header("Authorization", _("OAuth %s").printf(session.get_access_token())); + } + + public yandex_transaction.with_url(yandex_session session, string url, HttpMethod method = HttpMethod.GET) + { + base.with_endpoint_url(session, url, method); + add_headers(session); + } + + public yandex_transaction(yandex_session session, HttpMethod method = HttpMethod.GET) + { + base(session, method); + add_headers(session); + } + + public void add_data(string type, string data) + { + set_custom_payload(data, type); + } + } + + public class Interactor: ServiceInteractor { + private WebAuthenticationPane web_auth_pane = null; + private ProgressPane progress_pane; + private yandex_session session = null; + private TransformablePhoto []photos; + + public override string get_name() { return "Yandex"; } + public override void cancel_interaction() { session.stop_transactions(); } + + public Interactor(PublishingDialog host) + { + base(host); + } + + public void service_get_album_list_error(RESTTransaction t, PublishingError err) + { + stderr.printf("failed to get album list\n"); + t.completed.disconnect(service_get_album_list_complete); + t.network_error.disconnect(service_get_album_list_error); + yandex_request_web_auth(); + //post_error(err); + } + + public void service_get_album_list_complete(RESTTransaction t) + { + t.completed.disconnect(service_get_album_list_complete); + t.network_error.disconnect(service_get_album_list_error); + + debug("service_get_album_list_complete: %s\n", t.get_response()); + + session.save_tokens(); + + parse_album_list(t.get_response()); + + PublishingOptionsPane publishing_options_pane = new PublishingOptionsPane(session); + + publishing_options_pane.publish.connect(on_publish); + publishing_options_pane.logout.connect(on_logout); + get_host().install_pane(publishing_options_pane); + } + + private void on_logout() + { + debug("Logout\n"); + start_interaction(); + } + + private void on_upload_complete(BatchUploader uploader, int num_published) + { + uploader.status_updated.disconnect(progress_pane.set_status); + uploader.upload_complete.disconnect(on_upload_complete); + uploader.upload_error.disconnect(on_upload_error); + + // TODO: add a descriptive, translatable error message string here + if (num_published == 0) + post_error(new PublishingError.LOCAL_FILE_ERROR("")); + + get_host().unlock_service(); + get_host().set_close_button_mode(); + + get_host().install_pane(new SuccessPane()); + } + + private void on_upload_error(BatchUploader uploader, PublishingError err) + { + uploader.status_updated.disconnect(progress_pane.set_status); + uploader.upload_complete.disconnect(on_upload_complete); + uploader.upload_error.disconnect(on_upload_error); + + post_error(err); + //yandex_request_web_auth(); + } + + private void start_upload() + { + debug("Publishing to %s : %s\n", session.get_destination_album(), session.get_destination_album_url()); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + + progress_pane = new ProgressPane(); + get_host().install_pane(progress_pane); + + Uploader uploader = new Uploader(session, photos); + + uploader.status_updated.connect(progress_pane.set_status); + + uploader.upload_complete.connect(on_upload_complete); + uploader.upload_error.connect(on_upload_error); + + uploader.upload(); + } + + private void on_publish() + { + if (session.get_destination_album_url() == null) + create_destination_album(); + else + start_upload(); + } + + public void service_get_album_list() + { + string url = session.get_album_list_url(); + + debug("getting album list from %s\n", url); + + yandex_transaction t = new yandex_transaction.with_url(session, url); + t.completed.connect(service_get_album_list_complete); + t.network_error.connect(service_get_album_list_error); + t.execute(); + } + + public void service_doc_transaction_error(RESTTransaction t, PublishingError err) + { + t.completed.disconnect(service_doc_transaction_complete); + t.network_error.disconnect(service_doc_transaction_error); + yandex_request_web_auth(); + //post_error(err); + } + + public void service_doc_transaction_complete(RESTTransaction t) + { + t.completed.disconnect(service_doc_transaction_complete); + t.network_error.disconnect(service_doc_transaction_error); + + debug("service_doc completed: %s", t.get_response()); + + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(t.get_response(), check_response); + Xml.Node* root = doc.get_root_node(); + + for (Xml.Node* work = root->children ; work != null; work = work->next) { + if (work->name != "workspace") + continue; + for (Xml.Node* c = work->children ; c != null; c = c->next) { + if (c->name != "collection") + continue; + + if (c->get_prop("id") == "album-list") { + session.set_album_list_url(c->get_prop("href")); + + service_get_album_list(); + break; + } + } + } + } catch (PublishingError err) { + post_error(err); + } + } + + private new string? check_response(RESTXmlDocument doc) + { + return null; + } + + private void parse_album_entry(Xml.Node *e) throws PublishingError + { + string title = null; + string link = null; + + for (Xml.Node* c = e->children ; c != null; c = c->next) { + if (c->name == "title") + title = c->get_content(); + + if ((c->name == "link") && (c->get_prop("rel") == "photos")) + link = c->get_prop("href"); + + if (title != null && link != null) { + session.add_album(title, link); + title = null; + link = null; + break; + } + } + } + + public void parse_album_creation(string data) + { + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(data, check_response); + Xml.Node *root = doc.get_root_node(); + + parse_album_entry(root); + } catch (PublishingError err) { + post_error(err); + } + } + + public void parse_album_list(string data) + { + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(data, check_response); + Xml.Node *root = doc.get_root_node(); + + for (Xml.Node *e = root->children ; e != null; e = e->next) { + if (e->name != "entry") + continue; + + parse_album_entry(e); + } + } catch (PublishingError err) { + post_error(err); + } + } + + private void on_web_auth_pane_token_check_required(string access_token, string refresh_token) + { + session.set_tokens(access_token, refresh_token); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + + yandex_transaction t = new yandex_transaction(session); + t.completed.connect(service_doc_transaction_complete); + t.network_error.connect(service_doc_transaction_error); + t.execute(); + } + + private void yandex_request_web_auth() + { + session.want_web_check = false; + session.set_tokens(null, null); + web_auth_pane = new WebAuthenticationPane(_("http://%s/authorize?client_id=%s&response_type=code").printf(auth_host, client_id)); + web_auth_pane.token_check_required.connect(on_web_auth_pane_token_check_required); + get_host().install_pane(web_auth_pane); + } + + private void yandex_login_pane(string username) + { + session = new yandex_session(username); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + get_host().set_large_window_mode(); + + if (!session.is_authenticated()) { + yandex_request_web_auth(); + } else { + session.want_web_check = true; + on_web_auth_pane_token_check_required(session.get_access_token(), session.get_refresh_token()); + } + } + + public override void start_interaction() + { + debug("Yandex.Interactor: starting iteractor\n"); + + photos = get_host().get_photos(); + + var total = photos.length; + var tagged = 0; + + foreach (TransformablePhoto p in photos) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(p.get_photo_id()); + var contains = Tag.for_name(yandex_upload_tag).contains(lphoto); + + if (contains) + tagged++; + } + + if (total == tagged) { + get_host().lock_service(); + get_host().set_cancel_button_mode(); + get_host().install_pane(new StaticMessagePane(_("There are no selected untagged photos to upload.\nPlease remove tag '%s' from selected photos if you want to upload them.").printf(yandex_upload_tag))); + return; + } + + TransformablePhoto []photos_tmp = new TransformablePhoto[total - tagged]; + var pos = 0; + foreach (TransformablePhoto p in photos) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(p.get_photo_id()); + var contains = Tag.for_name(yandex_upload_tag).contains(lphoto); + + if (contains) + continue; + + if (pos < photos_tmp.length) { + photos_tmp[pos] = p; + pos++; + } + } + + photos = photos_tmp; + + get_host().unlock_service(); + get_host().set_cancel_button_mode(); + + YandexLoginWelcomePane p = new YandexLoginWelcomePane(SERVICE_WELCOME_MESSAGE); + p.login_requested.connect(yandex_login_pane); + + get_host().install_pane(p); + } + + private void album_creation_error(RESTTransaction t, PublishingError err) + { + t.completed.disconnect(album_creation_complete); + t.network_error.disconnect(album_creation_error); + yandex_request_web_auth(); + //post_error(err); + } + + private void album_creation_complete(RESTTransaction t) + { + t.completed.disconnect(album_creation_complete); + t.network_error.disconnect(album_creation_error); + + parse_album_creation(t.get_response()); + + if (session.get_destination_album_url() != null) + start_upload(); + else + post_error(new PublishingError.PROTOCOL_ERROR("Server did not create album")); + } + + private void create_destination_album() + { + string album = session.get_destination_album(); + string url = _("%s/albums/").printf(session.get_endpoint_url()); + string data = _("%s").printf(album); + + yandex_transaction t = new yandex_transaction.with_url(session, url, HttpMethod.POST); + + t.add_data("application/atom+xml; charset=utf-8; type=entry", data); + + t.completed.connect(album_creation_complete); + t.network_error.connect(album_creation_error); + t.execute(); + } + } + + public class yandex_publish_options { + public bool xxx = false; + public bool disable_comments = false; + public bool hide_original = false; + public string access_type; + } + + public class yandex_session: RESTSession { + private string access_token = null; + private string refresh_token = null; + private string album_list_url = null; + public Gee.HashMap album_list = null; + private string destination_album = null; + public yandex_publish_options options; + private string username = null; + public Gee.HashMap transactions = null; + + public bool want_web_check = false; + + public void set_tokens(string? access_token, string? refresh_token) + { + debug("session: setting tokens: %s %s\n", access_token, refresh_token); + this.access_token = access_token; + this.refresh_token = refresh_token; + + if ((access_token == null) || (refresh_token == null)) + save_tokens(); + } + + public yandex_session(string username) + { + Config config = Config.get_instance(); + base(_("%s%s/").printf(service_url, username)); + + transactions = new Gee.HashMap(); + + if (yandex_session.load_username() != username) { + config.unset_gconf_string("yandex", "access_token"); + config.unset_gconf_string("yandex", "refresh_token"); + } else { + access_token = config.get_gconf_string("yandex", "access_token"); + refresh_token = config.get_gconf_string("yandex", "refresh_token"); + } + + save_username(username); + this.username = username; + + album_list = new Gee.HashMap(); + options = new yandex_publish_options(); + } + + public string get_username() { return username; } + + public bool is_authenticated() + { + return access_token != null; + } + public string get_access_token() + { + assert(is_authenticated()); + return access_token; + } + public string get_refresh_token() + { + assert(is_authenticated()); + return refresh_token; + } + + public void set_album_list_url(string url) + { + this.album_list_url = url; + } + + public bool has_album_list_url() + { + return album_list_url != null; + } + public string get_album_list_url() + { + assert(has_album_list_url()); + return album_list_url; + } + + public void add_album(string title, string link) + { + debug("add album: %s %s\n", title, link); + album_list.set(title, link); + } + + public void set_destination_album(string album) + { + destination_album = album; + } + public string get_destination_album_url() + { + return album_list[destination_album]; + } + public string get_destination_album() + { + return destination_album; + } + + public static void save_username(string username) + { + Config.get_instance().set_gconf_string("yandex", "username", username); + } + + public static string? load_username() + { + return Config.get_instance().get_gconf_string("yandex", "username"); + } + + public static string? load_auth_host() + { + return Config.get_instance().get_gconf_string("yandex", "auth_host"); + } + + public static string? load_client_id() + { + return Config.get_instance().get_gconf_string("yandex", "client_id"); + } + + public static string? load_service_host() + { + return Config.get_instance().get_gconf_string("yandex", "service_host"); + } + + public void save_tokens() + { + Config client = Config.get_instance(); + if (access_token == null) { + client.unset_gconf_string("yandex", "access_token"); + client.unset_gconf_string("yandex", "refresh_token"); + } else { + client.set_gconf_string("yandex", "access_token", access_token); + client.set_gconf_string("yandex", "refresh_token", refresh_token); + } + } + } + + private class Uploader: BatchUploader { + private yandex_session session; + + public Uploader(yandex_session session, TransformablePhoto []photos) + { + base(photos); + + this.session = session; + } + + protected override bool prepare_file(BatchUploader.TemporaryFileDescriptor file) + { + try { + file.source_photo.export(file.temp_file, + Scaling.for_original(), + Jpeg.Quality.MAXIMUM, + PhotoFileFormat.JFIF); + } catch(Error e) { + return false; + } + + return true; + } + + private void on_file_uploaded(RESTTransaction txn) { + if (txn in session.transactions) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(session.transactions[txn]); + Tag.for_name(yandex_upload_tag).attach(lphoto); + session.transactions.unset(txn); + } else { + stderr.printf("Failed to match photo ID to transaction: %s\n", txn.get_response()); + return; + } + } + + protected override RESTTransaction create_transaction_for_file(BatchUploader.TemporaryFileDescriptor file) + { + RESTTransaction t = new upload_transaction(session, file.temp_file.get_path(), file.source_photo); + + session.transactions.set(t, file.source_photo.get_photo_id()); + t.completed.connect(on_file_uploaded); + return t; + } + } + + private class upload_transaction: yandex_transaction { + public upload_transaction(yandex_session session, string source_file, TransformablePhoto photo) + { + base.with_url(session, session.get_destination_album_url(), HttpMethod.POST); + + set_custom_payload("qwe", "image/jpeg", 1); + + add_header("Slug", photo.get_name()); + debug("Uploading %s '%s' -> %s : %s\n", source_file, photo.get_name(), session.get_destination_album(), session.get_destination_album_url()); + + LibraryPhoto lphoto = LibraryPhoto.global.fetch(photo.get_photo_id()); + + Gee.List? photo_tags = Tag.global.fetch_for_photo(lphoto); + string tags = ""; + if (photo_tags != null) { + foreach (Tag tag in photo_tags) { + tags += _("%s;").printf(tag.get_name()); + } + + add_header("Tags", tags); + } + debug("photo: '%s', tags: '%s'", photo.get_name(), tags); + + Soup.Multipart message_parts = new Soup.Multipart("multipart/form-data"); + message_parts.append_form_string("tag", tags); + message_parts.append_form_string("title", photo.get_name()); + message_parts.append_form_string("xxx", session.options.xxx.to_string()); + message_parts.append_form_string("hide_original", session.options.hide_original.to_string()); + message_parts.append_form_string("disable_comments", session.options.disable_comments.to_string()); + message_parts.append_form_string("access", session.options.access_type.down()); + + string photo_data; + size_t data_length; + + try { + FileUtils.get_contents(source_file, out photo_data, out data_length); + } catch (FileError e) { + error("YandexUploadTransaction: couldn't read data from file '%s'", source_file); + } + + int image_part_num = message_parts.get_length(); + + Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); + message_parts.append_form_file("", source_file, "image/jpeg", bindable_data); + + unowned Soup.MessageHeaders image_part_header; + unowned Soup.Buffer image_part_body; + message_parts.get_part(image_part_num, out image_part_header, out image_part_body); + + GLib.HashTable result = new GLib.HashTable(GLib.str_hash, GLib.str_equal); + result.insert("name", "data"); + result.insert("filename", photo.get_name()); + + image_part_header.set_content_disposition("form-data", result); + + Soup.Message outbound_message = Soup.form_request_new_from_multipart(get_endpoint_url(), message_parts); + outbound_message.request_headers.append("Authorization", _("OAuth %s").printf(session.get_access_token())); + set_message(outbound_message); + } + } + + private class WebAuthenticationPane: PublishingDialogPane { + private string token_str_http = _("http://%s/token").printf(auth_host); + private string token_str_https = _("https://%s/token").printf(auth_host); + + private WebKit.WebView webview = null; + private Gtk.ScrolledWindow webview_frame = null; + private Gtk.Layout white_pane = null; + private string login_url; + + private int started_token_recv = 0; + + public signal void token_check_required(string access_token, string refresh_token); + + public WebAuthenticationPane(string login_url) + { + this.login_url = login_url; + + Gdk.Color white_color; + Gdk.Color.parse("white", out white_color); + Gtk.Adjustment layout_pane_adjustment = new Gtk.Adjustment(0.5, 0.0, 1.0, 0.01, 0.1, 0.1); + white_pane = new Gtk.Layout(layout_pane_adjustment, layout_pane_adjustment); + white_pane.modify_bg(Gtk.StateType.NORMAL, white_color); + add(white_pane); + + webview_frame = new Gtk.ScrolledWindow(null, null); + webview_frame.set_shadow_type(Gtk.ShadowType.ETCHED_IN); + webview_frame.set_policy(Gtk.PolicyType.AUTOMATIC, Gtk.PolicyType.AUTOMATIC); + + webview = new WebKit.WebView(); + webview.load_finished.connect(on_load_finished); + webview.load_started.connect(on_load_started); + webview.navigation_requested.connect(navigation_requested); + webview.mime_type_policy_decision_requested.connect(mime_type_policy_decision_requested); + + webview_frame.add(webview); + white_pane.add(webview_frame); + webview.set_size_request(853, 587); + } + + private bool mime_type_policy_decision_requested (WebKit.WebFrame p0, WebKit.NetworkRequest p1, string p2, WebKit.WebPolicyDecision p3) + { + if (started_token_recv == 1) { + if (p2 != "application/json") { + debug("Trying to get yandex token: unsupported mime type '%s'.\n", p2); + stderr.printf("Trying to get yandex token: unsupported mime type '%s'.\n", p2); + + started_token_recv = 2; + } + } + return true; + } + + private WebKit.NavigationResponse navigation_requested (WebKit.WebFrame frame, WebKit.NetworkRequest req) + { + debug("Navigating to '%s', token: '%s'\n", req.uri, token_str_https); + if (req.uri == token_str_https || req.uri == token_str_http) + started_token_recv = 1; + return WebKit.NavigationResponse.ACCEPT; + } + + private void on_load_finished(WebKit.WebFrame frame) + { + if (started_token_recv != 1) { + show_page(); + return; + } + + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.LEFT_PTR)); + + WebKit.WebDataSource data = frame.get_data_source(); + string s = data.get_data().str; + Json.Parser p = new Json.Parser(); + + try { + p.load_from_data(s, -1); + var root = p.get_root().get_object(); + + debug("data: %s\n", s); + debug("%s %s\n", root.get_string_member("access_token"), root.get_string_member("refresh_token")); + + token_check_required(root.get_string_member("access_token"), root.get_string_member("refresh_token")); + } catch (Error e) { + stderr.printf("Invalid yandex token: %s.\n", s); + } + } + + private void on_load_started(WebKit.WebFrame frame) + { + webview_frame.hide(); + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.WATCH)); + } + + public void show_page() + { + webview_frame.show(); + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.LEFT_PTR)); + } + + public override void installed() + { + webview.open(login_url); + } + } + + private class PublishingOptionsPane: PublishingDialogPane { + private Gtk.Builder builder; + private Gtk.Button logout_button; + private Gtk.Button publish_button; + private Gtk.ComboBoxEntry album_list; + private yandex_session session; + + public signal void publish(); + public signal void logout(); + + public PublishingOptionsPane(yandex_session session) + { + this.session = session; + + try { + builder = new Gtk.Builder(); + builder.add_from_file(Resources.get_ui("yandex_publish_model.glade").get_path()); + builder.connect_signals(null); + var align = builder.get_object("alignment") as Gtk.Alignment; + + album_list = builder.get_object ("album_list") as Gtk.ComboBoxEntry; + foreach (var entry in session.album_list) { + album_list.append_text(entry.key); + } + album_list.set_active(0); + + publish_button = builder.get_object("publish_button") as Gtk.Button; + logout_button = builder.get_object("logout_button") as Gtk.Button; + + publish_button.clicked.connect(on_publish_clicked); + logout_button.clicked.connect(on_logout_clicked); + + align.reparent(this); + } catch (Error e) { + stderr.printf ("Could not load UI: %s\n", e.message); + } + } + + private void on_logout_clicked() + { + logout(); + } + + private void on_publish_clicked() + { + session.set_destination_album(album_list.get_active_text()); + + var tmp = builder.get_object("xxx_check") as Gtk.CheckButton; + session.options.xxx = tmp.active; + + tmp = builder.get_object("hide_original_check") as Gtk.CheckButton; + session.options.hide_original = tmp.active; + + tmp = builder.get_object("disable_comments_check") as Gtk.CheckButton; + session.options.disable_comments = tmp.active; + + var access_type = builder.get_object("access_type_list") as Gtk.ComboBoxEntry; + session.options.access_type = access_type.get_active_text(); + + publish(); + } + } + +} + +#endif Index: ui/yandex_publish_model.glade =================================================================== --- ui/yandex_publish_model.glade (revision 0) +++ ui/yandex_publish_model.glade (revision 0) @@ -0,0 +1,174 @@ + + + + + + + + True + 0.10000000149011612 + 0.10000000149011612 + + + True + + + True + 2 + 2 + + + True + Albums (or write new) + + + 1 + 2 + + + + + True + Access type + + + 2 + + + + + True + liststore1 + 0 + 0 + + + 1 + 2 + 1 + + + + + True + liststore2 + 0 + 0 + + + 1 + 2 + 1 + 2 + 1 + + + + + 0 + + + + + Disable comments + True + True + False + True + + + 2 + 1 + + + + + Mark as XXX + True + True + False + True + + + 2 + 2 + + + + + Forbid getting photo's original + True + True + False + True + + + 3 + + + + + True + 2 + spread + + + Logout + True + True + True + + + False + False + 0 + + + + + Publish + True + True + True + + + False + False + 1 + + + + + 2 + 4 + + + + + + + + + + + + + + + Public + + + Friends + + + Private + + + + + + + + + + Index: Makefile =================================================================== --- Makefile (revision 2145) +++ Makefile (working copy) @@ -97,6 +97,7 @@ SlideshowPage.vala \ LibraryFiles.vala \ FlickrConnector.vala \ + YandexConnector.vala \ Printing.vala \ Tag.vala \ TagPage.vala \ @@ -150,6 +151,7 @@ tags.ui \ trash.ui \ offline.ui \ + yandex_publish_model.glade \ shotwell.glade SYS_INTEGRATION_FILES = \ @@ -268,7 +270,8 @@ glib-2.0 \ libexif \ sqlite3 \ - gexiv2 + gexiv2 \ + json-glib-1.0 LIBRAW_PKG = \ libraw -- Evgeniy Polyakov From mahfiaz at gmail.com Thu Sep 9 20:18:51 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Thu, 09 Sep 2010 23:18:51 +0300 Subject: [Shotwell] XMP files outside photo In-Reply-To: <4C8901BC.8090304@yorba.org> References: <1284045307.2012.496.camel@antiloop> <4C8901BC.8090304@yorba.org> Message-ID: <1284063531.2012.803.camel@antiloop> ?hel kenal p?eval, N, 2010-09-09 kell 08:48, kirjutas Adam Dingle: > Yes - we've thought about this too. See this ticket: > > http://trac.yorba.org/ticket/1879 > > adam It's so nice, whatever idea new to me I happen to stumble on, Yorba team already has it planned for Shotwell :) Mattias > > On 09/09/2010 08:15 AM, Mattias P?ldaru wrote: > > I found a new string from F-Spot today: > > "Never modify image files.\n" > > "Write XMP files next to the images instead." > > > > This option might be worth considering for Shotwell as well, at least > > for importing. > > > > Best regard > > Mattias > > > > > > _______________________________________________ > > 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 florian at manach.fr Thu Sep 9 21:29:37 2010 From: florian at manach.fr (Florian Manach) Date: Thu, 09 Sep 2010 23:29:37 +0200 Subject: [Shotwell] XMP files outside photo In-Reply-To: <1284063531.2012.803.camel@antiloop> References: <1284045307.2012.496.camel@antiloop> <4C8901BC.8090304@yorba.org> <1284063531.2012.803.camel@antiloop> Message-ID: <1284067777.14640.2.camel@compaq> I thought there was a ticket submitted by Ubuntu to save the modification in a copy of the original jpeg so the modified version is always accessible on the filesystem itself. Am I wrong ? Le jeudi 09 septembre 2010 ? 23:18 +0300, Mattias P?ldaru a ?crit : > ?hel kenal p?eval, N, 2010-09-09 kell 08:48, kirjutas Adam Dingle: > > Yes - we've thought about this too. See this ticket: > > > > http://trac.yorba.org/ticket/1879 > > > > adam > > It's so nice, whatever idea new to me I happen to stumble on, Yorba team > already has it planned for Shotwell :) > > Mattias > > > > > > On 09/09/2010 08:15 AM, Mattias P?ldaru wrote: > > > I found a new string from F-Spot today: > > > "Never modify image files.\n" > > > "Write XMP files next to the images instead." > > > > > > This option might be worth considering for Shotwell as well, at least > > > for importing. > > > > > > Best regard > > > Mattias > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From zbr at ioremap.net Thu Sep 9 22:42:14 2010 From: zbr at ioremap.net (Evgeniy Polyakov) Date: Fri, 10 Sep 2010 02:42:14 +0400 Subject: [Shotwell] [PATCH] take2: add support for Yandex.Fotki web photo hosting In-Reply-To: <20100909151608.GA32399@ioremap.net> References: <20100909151608.GA32399@ioremap.net> Message-ID: <20100909224214.GA15314@ioremap.net> Hi all. I believe I've addressed all comments at http://trac.yorba.org/ticket/2536#comment:2 either in private email to Jim or here. Please review and commit. I also added all people in tracker's CC list here, hope its ok. Patch attached. -- Evgeniy Polyakov -------------- next part -------------- Index: src/Config.vala =================================================================== --- src/Config.vala (revision 2214) +++ src/Config.vala (working copy) @@ -287,6 +287,21 @@ return get_string("/apps/shotwell/sharing/picasa/auth_token"); } + public string? get_gconf_string(string id, string key) { + return get_string(_("/apps/shotwell/sharing/%s/%s").printf(id, key)); + } + + public void set_gconf_string(string id, string key, string value) { + set_string(_("/apps/shotwell/sharing/%s/%s").printf(id, key), value); + } + + public void unset_gconf_string(string id, string key) { + try { + client.recursive_unset(_("/apps/shotwell/sharing/%s/%s").printf(id, key), GConf.UnsetFlags.NAMES); + } catch (GLib.Error err) { + } + } + public bool set_printing_content_layout(int layout_code) { return set_int("/apps/shotwell/printing/content_layout", layout_code + 1); } Index: src/WebConnectors.vala =================================================================== --- src/WebConnectors.vala (revision 2214) +++ src/WebConnectors.vala (working copy) @@ -1110,6 +1110,7 @@ result += "Facebook"; result += "Flickr"; result += "Picasa Web Albums"; + result += "Yandex.Fotki"; return result; } @@ -1121,6 +1122,8 @@ return new FlickrConnector.Interactor(host); } else if (service_name == "Picasa Web Albums") { return new PicasaConnector.Interactor(host); + } else if (service_name == "Yandex.Fotki") { + return new YandexConnector.Interactor(host); } else { error("ServiceInteractor: unsupported service '%s'", service_name); } Index: src/YandexConnector.vala =================================================================== --- src/YandexConnector.vala (revision 0) +++ src/YandexConnector.vala (revision 0) @@ -0,0 +1,829 @@ +/* Copyright 2010+ Evgeniy Polyakov + * + * This software is licensed under the GNU LGPL (version 2.1 or later). + * See the COPYING file in this distribution. + */ + +#if !NO_PUBLISHING + +namespace YandexConnector { + private const string SERVICE_WELCOME_MESSAGE = _("You are not currently logged into Yandex.Fotki."); + private const string RESTART_ERROR_MESSAGE = _("You have already logged in and out of Yandex.Fotki during this Shotwell session.\nTo continue publishing to Yandex.Fotki, quit and restart Shotwell, then try publishing again."); + + private string client_id; + private string auth_host; + private string service_host; + + private string service_url; + + private const string yandex_upload_tag = "yandex_uploaded"; + + private class YandexLoginWelcomePane : PublishingDialogPane { + private weak Interactor interactor; + private Gtk.Button login_button; + private Gtk.Entry username_entry; + + public signal void login_requested(string text); + + private void on_login_clicked() { + login_requested(username_entry.text); + } + + private void on_username_changed() { + login_button.set_sensitive(username_entry.get_text() != ""); + } + + public YandexLoginWelcomePane(Interactor interactor, string service_welcome_message) { + this.interactor = interactor; + + Gtk.SeparatorToolItem top_space = new Gtk.SeparatorToolItem(); + top_space.set_draw(false); + Gtk.SeparatorToolItem bottom_space = new Gtk.SeparatorToolItem(); + bottom_space.set_draw(false); + add(top_space); + + Gtk.Table content_layouter = new Gtk.Table(2, 1, false); + + Gtk.Label not_logged_in_label = new Gtk.Label(""); + not_logged_in_label.set_use_markup(true); + not_logged_in_label.set_markup(service_welcome_message); + not_logged_in_label.set_line_wrap(true); + not_logged_in_label.set_size_request(PublishingDialog.STANDARD_CONTENT_LABEL_WIDTH, -1); + content_layouter.attach(not_logged_in_label, 0, 1, 0, 1, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, 6, 0); + not_logged_in_label.set_size_request(PublishingDialog.STANDARD_CONTENT_LABEL_WIDTH, 112); + not_logged_in_label.set_alignment(0.5f, 0.0f); + + login_button = new Gtk.Button.with_mnemonic(_("_Login")); + login_button.set_size_request(PublishingDialog.STANDARD_ACTION_BUTTON_WIDTH, -1); + login_button.clicked.connect(on_login_clicked); + + username_entry = new Gtk.Entry(); + + Gtk.Label username_label = new Gtk.Label("Username:"); + + auth_host = "oauth.morelia.yandex.ru"; + service_host = "fimp.apodora.yandex.ru"; + client_id = "ce22bf30fdbb413fa71436295fe803d1"; + + var auth = yandex_session.load_auth_host(); + if (auth != null) + auth_host = auth; + + var service = yandex_session.load_service_host(); + if (service != null) + service_host = service; + + var cid = yandex_session.load_client_id(); + if (cid != null) + client_id = cid; + + var username = yandex_session.load_username(); + if (username != null) + username_entry.set_text(username); + username_entry.changed.connect(on_username_changed); + + username_label.set_mnemonic_widget(username_entry); + + service_url =_("http://%s/api/users/").printf(service_host); + + var hbox = new Gtk.HBox (false, 20); + hbox.pack_start(username_label, false, true, 0); + hbox.pack_start(username_entry, false, true, 0); + hbox.pack_start(login_button, false, true, 0); + + Gtk.Alignment login_button_aligner = new Gtk.Alignment(0.5f, 0.5f, 0.0f, 0.0f); + login_button_aligner.add(hbox); + + content_layouter.attach(login_button_aligner, 0, 1, 1, 2, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, + Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL, 6, 0); + add(content_layouter); + + add(bottom_space); + bottom_space.set_size_request(-1, 112); + } + + public override void installed() { + username_entry.grab_focus(); + username_entry.set_activates_default(true); + login_button.can_default = true; + interactor.get_host().set_default(login_button); + } + } + + public class yandex_transaction: RESTTransaction { + private void add_headers(yandex_session session) { + if (session.is_authenticated()) + add_header("Authorization", _("OAuth %s").printf(session.get_access_token())); + } + + public yandex_transaction.with_url(yandex_session session, string url, HttpMethod method = HttpMethod.GET) { + base.with_endpoint_url(session, url, method); + add_headers(session); + } + + public yandex_transaction(yandex_session session, HttpMethod method = HttpMethod.GET) { + base(session, method); + add_headers(session); + } + + public void add_data(string type, string data) { + set_custom_payload(data, type); + } + } + + public class Interactor: ServiceInteractor { + private WebAuthenticationPane web_auth_pane = null; + private ProgressPane progress_pane; + private yandex_session session = null; + private Photo []photos; + + public override string get_name() { return "Yandex"; } + public override void cancel_interaction() { session.stop_transactions(); } + + public Interactor(PublishingDialog host) { + base(host); + } + + internal new PublishingDialog get_host() { + return base.get_host(); + } + + public void service_get_album_list_error(RESTTransaction t, PublishingError err) { + stderr.printf("failed to get album list\n"); + t.completed.disconnect(service_get_album_list_complete); + t.network_error.disconnect(service_get_album_list_error); + yandex_request_web_auth(); + } + + public void service_get_album_list_complete(RESTTransaction t) { + t.completed.disconnect(service_get_album_list_complete); + t.network_error.disconnect(service_get_album_list_error); + + debug("service_get_album_list_complete: %s\n", t.get_response()); + + session.save_tokens(); + + parse_album_list(t.get_response()); + + PublishingOptionsPane publishing_options_pane = new PublishingOptionsPane(session); + + publishing_options_pane.publish.connect(on_publish); + publishing_options_pane.logout.connect(on_logout); + get_host().install_pane(publishing_options_pane); + } + + private void on_logout() { + debug("Logout\n"); + start_interaction(); + } + + private void on_upload_complete(BatchUploader uploader, int num_published) { + uploader.status_updated.disconnect(progress_pane.set_status); + uploader.upload_complete.disconnect(on_upload_complete); + uploader.upload_error.disconnect(on_upload_error); + + if (num_published == 0) + post_error(new PublishingError.LOCAL_FILE_ERROR("")); + + get_host().unlock_service(); + get_host().set_close_button_mode(); + + get_host().install_pane(new SuccessPane()); + } + + private void on_upload_error(BatchUploader uploader, PublishingError err) { + uploader.status_updated.disconnect(progress_pane.set_status); + uploader.upload_complete.disconnect(on_upload_complete); + uploader.upload_error.disconnect(on_upload_error); + + post_error(err); + } + + private void start_upload() { + debug("Publishing to %s : %s\n", session.get_destination_album(), session.get_destination_album_url()); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + + progress_pane = new ProgressPane(); + get_host().install_pane(progress_pane); + + Uploader uploader = new Uploader(session, photos); + + uploader.status_updated.connect(progress_pane.set_status); + + uploader.upload_complete.connect(on_upload_complete); + uploader.upload_error.connect(on_upload_error); + + uploader.upload(); + } + + private void on_publish() { + if (session.get_destination_album_url() == null) + create_destination_album(); + else + start_upload(); + } + + public void service_get_album_list() { + string url = session.get_album_list_url(); + + debug("getting album list from %s\n", url); + + yandex_transaction t = new yandex_transaction.with_url(session, url); + t.completed.connect(service_get_album_list_complete); + t.network_error.connect(service_get_album_list_error); + t.execute(); + } + + public void service_doc_transaction_error(RESTTransaction t, PublishingError err) { + t.completed.disconnect(service_doc_transaction_complete); + t.network_error.disconnect(service_doc_transaction_error); + yandex_request_web_auth(); + } + + public void service_doc_transaction_complete(RESTTransaction t) { + t.completed.disconnect(service_doc_transaction_complete); + t.network_error.disconnect(service_doc_transaction_error); + + debug("service_doc completed: %s", t.get_response()); + + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(t.get_response(), check_response); + Xml.Node* root = doc.get_root_node(); + + for (Xml.Node* work = root->children ; work != null; work = work->next) { + if (work->name != "workspace") + continue; + for (Xml.Node* c = work->children ; c != null; c = c->next) { + if (c->name != "collection") + continue; + + if (c->get_prop("id") == "album-list") { + session.set_album_list_url(c->get_prop("href")); + + service_get_album_list(); + break; + } + } + } + } catch (PublishingError err) { + post_error(err); + } + } + + private new string? check_response(RESTXmlDocument doc) { + return null; + } + + private void parse_album_entry(Xml.Node *e) throws PublishingError { + string title = null; + string link = null; + + for (Xml.Node* c = e->children ; c != null; c = c->next) { + if (c->name == "title") + title = c->get_content(); + + if ((c->name == "link") && (c->get_prop("rel") == "photos")) + link = c->get_prop("href"); + + if (title != null && link != null) { + session.add_album(title, link); + title = null; + link = null; + break; + } + } + } + + public void parse_album_creation(string data) { + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(data, check_response); + Xml.Node *root = doc.get_root_node(); + + parse_album_entry(root); + } catch (PublishingError err) { + post_error(err); + } + } + + public void parse_album_list(string data) { + try { + RESTXmlDocument doc = RESTXmlDocument.parse_string(data, check_response); + Xml.Node *root = doc.get_root_node(); + + for (Xml.Node *e = root->children ; e != null; e = e->next) { + if (e->name != "entry") + continue; + + parse_album_entry(e); + } + } catch (PublishingError err) { + post_error(err); + } + } + + private void on_web_auth_pane_token_check_required(string access_token, string refresh_token) { + session.set_tokens(access_token, refresh_token); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + + yandex_transaction t = new yandex_transaction(session); + t.completed.connect(service_doc_transaction_complete); + t.network_error.connect(service_doc_transaction_error); + t.execute(); + } + + private void yandex_request_web_auth() { + session.want_web_check = false; + session.set_tokens(null, null); + web_auth_pane = new WebAuthenticationPane(_("http://%s/authorize?client_id=%s&response_type=code").printf(auth_host, client_id)); + web_auth_pane.token_check_required.connect(on_web_auth_pane_token_check_required); + get_host().install_pane(web_auth_pane); + } + + private void yandex_login_pane(string username) { + session = new yandex_session(username); + + get_host().lock_service(); + get_host().set_cancel_button_mode(); + get_host().set_large_window_mode(); + + if (!session.is_authenticated()) { + yandex_request_web_auth(); + } else { + session.want_web_check = true; + on_web_auth_pane_token_check_required(session.get_access_token(), session.get_refresh_token()); + } + } + + public override void start_interaction() { + debug("Yandex.Interactor: starting iteractor\n"); + + photos = get_host().get_photos(); + + var total = photos.length; + var tagged = 0; + + foreach (Photo p in photos) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(p.get_photo_id()); + var contains = Tag.for_name(yandex_upload_tag).contains(lphoto); + + if (contains) + tagged++; + } + + if (total == tagged) { + get_host().lock_service(); + get_host().set_cancel_button_mode(); + get_host().install_pane(new StaticMessagePane(_("There are no selected untagged photos to upload.\nPlease remove tag '%s' from selected photos if you want to upload them.").printf(yandex_upload_tag))); + return; + } + + Photo []photos_tmp = new Photo[total - tagged]; + var pos = 0; + foreach (Photo p in photos) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(p.get_photo_id()); + var contains = Tag.for_name(yandex_upload_tag).contains(lphoto); + + if (contains) + continue; + + if (pos < photos_tmp.length) { + photos_tmp[pos] = p; + pos++; + } + } + + photos = photos_tmp; + + get_host().unlock_service(); + get_host().set_cancel_button_mode(); + + YandexLoginWelcomePane p = new YandexLoginWelcomePane(this, SERVICE_WELCOME_MESSAGE); + p.login_requested.connect(yandex_login_pane); + + get_host().install_pane(p); + } + + private void album_creation_error(RESTTransaction t, PublishingError err) { + t.completed.disconnect(album_creation_complete); + t.network_error.disconnect(album_creation_error); + yandex_request_web_auth(); + } + + private void album_creation_complete(RESTTransaction t) { + t.completed.disconnect(album_creation_complete); + t.network_error.disconnect(album_creation_error); + + parse_album_creation(t.get_response()); + + if (session.get_destination_album_url() != null) + start_upload(); + else + post_error(new PublishingError.PROTOCOL_ERROR("Server did not create album")); + } + + private void create_destination_album() { + string album = session.get_destination_album(); + string url = _("%s/albums/").printf(session.get_endpoint_url()); + string data = _("%s").printf(album); + + yandex_transaction t = new yandex_transaction.with_url(session, url, HttpMethod.POST); + + t.add_data("application/atom+xml; charset=utf-8; type=entry", data); + + t.completed.connect(album_creation_complete); + t.network_error.connect(album_creation_error); + t.execute(); + } + } + + public class yandex_publish_options { + public bool xxx = false; + public bool disable_comments = false; + public bool hide_original = false; + public string access_type; + } + + public class yandex_session: RESTSession { + private string access_token = null; + private string refresh_token = null; + private string album_list_url = null; + public Gee.HashMap album_list = null; + private string destination_album = null; + public yandex_publish_options options; + private string username = null; + public Gee.HashMap transactions = null; + + public bool want_web_check = false; + + public void set_tokens(string? access_token, string? refresh_token) { + debug("session: setting tokens: %s %s\n", access_token, refresh_token); + this.access_token = access_token; + this.refresh_token = refresh_token; + + if ((access_token == null) || (refresh_token == null)) + save_tokens(); + } + + public yandex_session(string username) { + Config config = Config.get_instance(); + base(_("%s%s/").printf(service_url, username)); + + transactions = new Gee.HashMap(); + + if (yandex_session.load_username() != username) { + config.unset_gconf_string("yandex", "access_token"); + config.unset_gconf_string("yandex", "refresh_token"); + } else { + access_token = config.get_gconf_string("yandex", "access_token"); + refresh_token = config.get_gconf_string("yandex", "refresh_token"); + } + + save_username(username); + this.username = username; + + album_list = new Gee.HashMap(); + options = new yandex_publish_options(); + } + + public string get_username() { return username; } + + public bool is_authenticated() { + return access_token != null; + } + public string get_access_token() { + assert(is_authenticated()); + return access_token; + } + public string get_refresh_token() { + assert(is_authenticated()); + return refresh_token; + } + + public void set_album_list_url(string url) { + this.album_list_url = url; + } + + public bool has_album_list_url() { + return album_list_url != null; + } + public string get_album_list_url() { + assert(has_album_list_url()); + return album_list_url; + } + + public void add_album(string title, string link) { + debug("add album: %s %s\n", title, link); + album_list.set(title, link); + } + + public void set_destination_album(string album) { + destination_album = album; + } + public string get_destination_album_url() { + return album_list[destination_album]; + } + public string get_destination_album() { + return destination_album; + } + + public static void save_username(string username) { + Config.get_instance().set_gconf_string("yandex", "username", username); + } + + public static string? load_username() { + return Config.get_instance().get_gconf_string("yandex", "username"); + } + + public static string? load_auth_host() { + return Config.get_instance().get_gconf_string("yandex", "auth_host"); + } + + public static string? load_client_id() { + return Config.get_instance().get_gconf_string("yandex", "client_id"); + } + + public static string? load_service_host() { + return Config.get_instance().get_gconf_string("yandex", "service_host"); + } + + public void save_tokens() { + Config client = Config.get_instance(); + if (access_token == null) { + client.unset_gconf_string("yandex", "access_token"); + client.unset_gconf_string("yandex", "refresh_token"); + } else { + client.set_gconf_string("yandex", "access_token", access_token); + client.set_gconf_string("yandex", "refresh_token", refresh_token); + } + } + } + + private class Uploader: BatchUploader { + private yandex_session session; + + public Uploader(yandex_session session, Photo []photos) { + base(photos); + + this.session = session; + } + + protected override bool prepare_file(BatchUploader.TemporaryFileDescriptor file) { + try { + file.source_photo.export(file.temp_file, + Scaling.for_original(), + Jpeg.Quality.MAXIMUM, + PhotoFileFormat.JFIF); + } catch(Error e) { + return false; + } + + return true; + } + + private void on_file_uploaded(RESTTransaction txn) { + if (txn in session.transactions) { + LibraryPhoto lphoto = LibraryPhoto.global.fetch(session.transactions[txn]); + Tag.for_name(yandex_upload_tag).attach(lphoto); + session.transactions.unset(txn); + } else { + stderr.printf("Failed to match photo ID to transaction: %s\n", txn.get_response()); + return; + } + } + + protected override RESTTransaction create_transaction_for_file(BatchUploader.TemporaryFileDescriptor file) { + RESTTransaction t = new upload_transaction(session, file.temp_file.get_path(), file.source_photo); + + session.transactions.set(t, file.source_photo.get_photo_id()); + t.completed.connect(on_file_uploaded); + return t; + } + } + + private class upload_transaction: yandex_transaction { + public upload_transaction(yandex_session session, string source_file, Photo photo) { + base.with_url(session, session.get_destination_album_url(), HttpMethod.POST); + + set_custom_payload("qwe", "image/jpeg", 1); + + add_header("Slug", photo.get_name()); + debug("Uploading %s '%s' -> %s : %s\n", source_file, photo.get_name(), session.get_destination_album(), session.get_destination_album_url()); + + LibraryPhoto lphoto = LibraryPhoto.global.fetch(photo.get_photo_id()); + + Gee.List? photo_tags = Tag.global.fetch_for_photo(lphoto); + string tags = ""; + if (photo_tags != null) { + foreach (Tag tag in photo_tags) { + tags += _("%s;").printf(tag.get_name()); + } + + add_header("Tags", tags); + } + debug("photo: '%s', tags: '%s'", photo.get_name(), tags); + + Soup.Multipart message_parts = new Soup.Multipart("multipart/form-data"); + message_parts.append_form_string("tag", tags); + message_parts.append_form_string("title", photo.get_name()); + message_parts.append_form_string("xxx", session.options.xxx.to_string()); + message_parts.append_form_string("hide_original", session.options.hide_original.to_string()); + message_parts.append_form_string("disable_comments", session.options.disable_comments.to_string()); + message_parts.append_form_string("access", session.options.access_type.down()); + + string photo_data; + size_t data_length; + + try { + FileUtils.get_contents(source_file, out photo_data, out data_length); + } catch (FileError e) { + error("YandexUploadTransaction: couldn't read data from file '%s'", source_file); + } + + int image_part_num = message_parts.get_length(); + + Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); + message_parts.append_form_file("", source_file, "image/jpeg", bindable_data); + + unowned Soup.MessageHeaders image_part_header; + unowned Soup.Buffer image_part_body; + message_parts.get_part(image_part_num, out image_part_header, out image_part_body); + + GLib.HashTable result = new GLib.HashTable(GLib.str_hash, GLib.str_equal); + result.insert("name", "data"); + result.insert("filename", photo.get_name()); + + image_part_header.set_content_disposition("form-data", result); + + Soup.Message outbound_message = Soup.form_request_new_from_multipart(get_endpoint_url(), message_parts); + outbound_message.request_headers.append("Authorization", _("OAuth %s").printf(session.get_access_token())); + set_message(outbound_message); + } + } + + private class WebAuthenticationPane: PublishingDialogPane { + private string token_str_http = _("http://%s/token").printf(auth_host); + private string token_str_https = _("https://%s/token").printf(auth_host); + + private WebKit.WebView webview = null; + private Gtk.ScrolledWindow webview_frame = null; + private Gtk.Layout white_pane = null; + private string login_url; + + private int started_token_recv = 0; + + public signal void token_check_required(string access_token, string refresh_token); + + public WebAuthenticationPane(string login_url) { + this.login_url = login_url; + + Gdk.Color white_color; + Gdk.Color.parse("white", out white_color); + Gtk.Adjustment layout_pane_adjustment = new Gtk.Adjustment(0.5, 0.0, 1.0, 0.01, 0.1, 0.1); + white_pane = new Gtk.Layout(layout_pane_adjustment, layout_pane_adjustment); + white_pane.modify_bg(Gtk.StateType.NORMAL, white_color); + add(white_pane); + + webview_frame = new Gtk.ScrolledWindow(null, null); + webview_frame.set_shadow_type(Gtk.ShadowType.ETCHED_IN); + webview_frame.set_policy(Gtk.PolicyType.AUTOMATIC, Gtk.PolicyType.AUTOMATIC); + + webview = new WebKit.WebView(); + webview.load_finished.connect(on_load_finished); + webview.load_started.connect(on_load_started); + webview.navigation_requested.connect(navigation_requested); + webview.mime_type_policy_decision_requested.connect(mime_type_policy_decision_requested); + + webview_frame.add(webview); + white_pane.add(webview_frame); + webview.set_size_request(853, 587); + } + + private bool mime_type_policy_decision_requested (WebKit.WebFrame p0, WebKit.NetworkRequest p1, string p2, WebKit.WebPolicyDecision p3) { + if (started_token_recv == 1) { + if (p2 != "application/json") { + debug("Trying to get yandex token: unsupported mime type '%s'.\n", p2); + stderr.printf("Trying to get yandex token: unsupported mime type '%s'.\n", p2); + + started_token_recv = 2; + } + } + return true; + } + + private WebKit.NavigationResponse navigation_requested (WebKit.WebFrame frame, WebKit.NetworkRequest req) { + debug("Navigating to '%s', token: '%s'\n", req.uri, token_str_https); + if (req.uri == token_str_https || req.uri == token_str_http) + started_token_recv = 1; + return WebKit.NavigationResponse.ACCEPT; + } + + private void on_load_finished(WebKit.WebFrame frame) { + if (started_token_recv != 1) { + show_page(); + return; + } + + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.LEFT_PTR)); + + WebKit.WebDataSource data = frame.get_data_source(); + string s = data.get_data().str; + Json.Parser p = new Json.Parser(); + + try { + p.load_from_data(s, -1); + var root = p.get_root().get_object(); + + debug("data: %s\n", s); + debug("%s %s\n", root.get_string_member("access_token"), root.get_string_member("refresh_token")); + + token_check_required(root.get_string_member("access_token"), root.get_string_member("refresh_token")); + } catch (Error e) { + stderr.printf("Invalid yandex token: %s.\n", s); + } + } + + private void on_load_started(WebKit.WebFrame frame) { + webview_frame.hide(); + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.WATCH)); + } + + public void show_page() { + webview_frame.show(); + window.set_cursor(new Gdk.Cursor(Gdk.CursorType.LEFT_PTR)); + } + + public override void installed() { + webview.open(login_url); + } + } + + private class PublishingOptionsPane: PublishingDialogPane { + private Gtk.Builder builder; + private Gtk.Button logout_button; + private Gtk.Button publish_button; + private Gtk.ComboBoxEntry album_list; + private yandex_session session; + + public signal void publish(); + public signal void logout(); + + public PublishingOptionsPane(yandex_session session) { + this.session = session; + + try { + builder = new Gtk.Builder(); + builder.add_from_file(Resources.get_ui("yandex_publish_model.glade").get_path()); + builder.connect_signals(null); + var align = builder.get_object("alignment") as Gtk.Alignment; + + album_list = builder.get_object ("album_list") as Gtk.ComboBoxEntry; + foreach (var entry in session.album_list) { + album_list.append_text(entry.key); + } + album_list.set_active(0); + + publish_button = builder.get_object("publish_button") as Gtk.Button; + logout_button = builder.get_object("logout_button") as Gtk.Button; + + publish_button.clicked.connect(on_publish_clicked); + logout_button.clicked.connect(on_logout_clicked); + + align.reparent(this); + } catch (Error e) { + stderr.printf ("Could not load UI: %s\n", e.message); + } + } + + private void on_logout_clicked() { + logout(); + } + + private void on_publish_clicked() { + session.set_destination_album(album_list.get_active_text()); + + var tmp = builder.get_object("xxx_check") as Gtk.CheckButton; + session.options.xxx = tmp.active; + + tmp = builder.get_object("hide_original_check") as Gtk.CheckButton; + session.options.hide_original = tmp.active; + + tmp = builder.get_object("disable_comments_check") as Gtk.CheckButton; + session.options.disable_comments = tmp.active; + + var access_type = builder.get_object("access_type_list") as Gtk.ComboBoxEntry; + session.options.access_type = access_type.get_active_text(); + + publish(); + } + } + +} + +#endif Index: ui/yandex_publish_model.glade =================================================================== --- ui/yandex_publish_model.glade (revision 0) +++ ui/yandex_publish_model.glade (revision 0) @@ -0,0 +1,174 @@ + + + + + + + + True + 0.10000000149011612 + 0.10000000149011612 + + + True + + + True + 2 + 2 + + + True + Albums (or write new) + + + 1 + 2 + + + + + True + Access type + + + 2 + + + + + True + liststore1 + 0 + 0 + + + 1 + 2 + 1 + + + + + True + liststore2 + 0 + 0 + + + 1 + 2 + 1 + 2 + 1 + + + + + 0 + + + + + Disable comments + True + True + False + True + + + 2 + 1 + + + + + Mark as XXX + True + True + False + True + + + 2 + 2 + + + + + Forbid getting photo's original + True + True + False + True + + + 3 + + + + + True + 2 + spread + + + Logout + True + True + True + + + False + False + 0 + + + + + Publish + True + True + True + + + False + False + 1 + + + + + 2 + 4 + + + + + + + + + + + + + + + Public + + + Friends + + + Private + + + + + + + + + + Index: Makefile =================================================================== --- Makefile (revision 2214) +++ Makefile (working copy) @@ -97,6 +97,7 @@ SlideshowPage.vala \ LibraryFiles.vala \ FlickrConnector.vala \ + YandexConnector.vala \ Printing.vala \ Tag.vala \ TagPage.vala \ @@ -151,6 +152,7 @@ tags.ui \ trash.ui \ offline.ui \ + yandex_publish_model.glade \ shotwell.glade SYS_INTEGRATION_FILES = \ @@ -271,7 +273,8 @@ glib-2.0 \ libexif \ sqlite3 \ - gexiv2 + gexiv2 \ + json-glib-1.0 LIBRAW_PKG = \ libraw @@ -312,6 +315,7 @@ webkit-1.0 >= 1.1.5 \ gudev-1.0 >= 145 \ dbus-glib-1 >= 0.80 + libjson-glib-1.0 >= 0.7 endif PKGS = $(EXT_PKGS) $(LOCAL_PKGS) $(LIBRAW_PKG) From adam at yorba.org Fri Sep 10 00:00:29 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 09 Sep 2010 17:00:29 -0700 Subject: [Shotwell] XMP files outside photo In-Reply-To: <1284067777.14640.2.camel@compaq> References: <1284045307.2012.496.camel@antiloop> <4C8901BC.8090304@yorba.org> <1284063531.2012.803.camel@antiloop> <1284067777.14640.2.camel@compaq> Message-ID: <4C89751D.9020203@yorba.org> Florian, you're not wrong about this. This is also in our ticket database here: http://trac.yorba.org/ticket/1798 There are two separate questions here: 1. Where should Shotwell store metadata (such as keywords)? a) only in its own database b) in sidecar XMP files c) in the image files themselves 2) Where should Shotwell store full-resolution JPEGs of edited photos? a) in memory only b) in a separate file in the same directory as the original JPEG c) in the original JPEG file (renaming the original to something like photo007.orig.jpg) Today, we've implemented only 1a and 2a. Eventually I think it would be great if these could be user options, since I think it's unlikely that any particular choices here will make everyone happy. adam On 09/09/2010 02:29 PM, Florian Manach wrote: > I thought there was a ticket submitted by Ubuntu to save the > modification in a copy of the original jpeg so the modified version is > always accessible on the filesystem itself. > > Am I wrong ? > > Le jeudi 09 septembre 2010 ? 23:18 +0300, Mattias P?ldaru a ?crit : >> ?hel kenal p?eval, N, 2010-09-09 kell 08:48, kirjutas Adam Dingle: >>> Yes - we've thought about this too. See this ticket: >>> >>> http://trac.yorba.org/ticket/1879 >>> >>> adam >> It's so nice, whatever idea new to me I happen to stumble on, Yorba team >> already has it planned for Shotwell :) >> >> Mattias >> >> >>> On 09/09/2010 08:15 AM, Mattias P?ldaru wrote: >>>> I found a new string from F-Spot today: >>>> "Never modify image files.\n" >>>> "Write XMP files next to the images instead." >>>> >>>> This option might be worth considering for Shotwell as well, at least >>>> for importing. >>>> >>>> Best regard >>>> Mattias >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From florian at manach.fr Fri Sep 10 07:58:09 2010 From: florian at manach.fr (Florian Manach) Date: Fri, 10 Sep 2010 09:58:09 +0200 Subject: [Shotwell] Some new feature proposal Message-ID: <1284105489.1001.51.camel@florian-desktop> Hi everyone, After several weeks observing the Shotwell developpement and testing the application, I finnaly jumped in an began to use it. So during these weeks, I said several times to myself "It would be good if gnagnagnagnagna..." So I thought I could suggest you these features. I already suggested a few of them, those remaining are mostly relative to the tags. - Copyright Informations : For those who can't store copyright, artist or author information with a function of theire camera, I think it should be good to have a way, inside Shotwell or at the import, to store that in the picture. - Give the same title to multiple files : It's impossible as far as I know and it's a pain to add the same title to my 300 photos of the Eiffel Tower. - Preset the title with the event name : as an option, just for people who don't want to entitle their 5 kilophotos. It's just some feature proposal, as I see you are very aware of our feedbacks... Thx again for the great work, Florian From p.ixiemotion at gmail.com Fri Sep 10 12:47:20 2010 From: p.ixiemotion at gmail.com (Kevin Brubeck Unhammer) Date: Fri, 10 Sep 2010 14:47:20 +0200 Subject: [Shotwell] Using Shotwell as camera importer in KDE Message-ID: Hi, I know KDE users are supposed to use DigiKam, but it's way too huge and slow for what I need; Shotwell however seems to have exactly the features I want while staying quick and responsive :-) The one thing I'm wondering about is if there's a way to make the usb notifier go straight to camera import when I click it. In KDE's system settings for device actions, the digikam command is: /usr/share/apps/digikam/utils/digikam-camera downloadFromUdi %i where %i is the "device ID" (something like .../freedesktop/...). Is there a similar way to start up shotwell, to take it straight to the camera import page? (Not that the extra click is a major inconvenience, but it would make the whole experience that much slicker.) best regards, Kevin Brubeck Unhammer From adam at yorba.org Fri Sep 10 15:47:37 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 10 Sep 2010 08:47:37 -0700 Subject: [Shotwell] Some new feature proposal In-Reply-To: <1284105489.1001.51.camel@florian-desktop> References: <1284105489.1001.51.camel@florian-desktop> Message-ID: <4C8A5319.2060505@yorba.org> Florian, glad you're now using Shotwell! :) Thanks for your suggestions, which sound reasonable. I've ticketed them here: http://trac.yorba.org/ticket/2539 http://trac.yorba.org/ticket/2540 adam On 09/10/2010 12:58 AM, Florian Manach wrote: > Hi everyone, > > After several weeks observing the Shotwell developpement and testing the > application, I finnaly jumped in an began to use it. > > So during these weeks, I said several times to myself "It would be good > if gnagnagnagnagna..." So I thought I could suggest you these features. > > I already suggested a few of them, those remaining are mostly relative > to the tags. > > - Copyright Informations : For those who can't store copyright, artist > or author information with a function of theire camera, I think it > should be good to have a way, inside Shotwell or at the import, to store > that in the picture. > > - Give the same title to multiple files : It's impossible as far as I > know and it's a pain to add the same title to my 300 photos of the > Eiffel Tower. > > - Preset the title with the event name : as an option, just for people > who don't want to entitle their 5 kilophotos. > > > It's just some feature proposal, as I see you are very aware of our > feedbacks... > > Thx again for the great work, > > Florian > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From jim at yorba.org Fri Sep 10 19:42:02 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 10 Sep 2010 12:42:02 -0700 Subject: [Shotwell] Using Shotwell as camera importer in KDE In-Reply-To: References: Message-ID: Hello, Yes, Shotwell does have something like this. You need to put the path to the camera device on the command-line in URI format, much like what you're describing. There's no additional arguments; Shotwell will detect if it's a URI and map it into the device. If you look at the shotwell.desktop file (shotwell.desktop.head in the tar ball), you'll see how it's described there: shotwell %U Where %U is the file path in URL format. -- Jim On Fri, Sep 10, 2010 at 5:47 AM, Kevin Brubeck Unhammer < p.ixiemotion at gmail.com> wrote: > Hi, > > I know KDE users are supposed to use DigiKam, but it's way too huge > and slow for what I need; Shotwell however seems to have exactly the > features I want while staying quick and responsive :-) > > The one thing I'm wondering about is if there's a way to make the usb > notifier go straight to camera import when I click it. In KDE's system > settings for device actions, the digikam command is: > > /usr/share/apps/digikam/utils/digikam-camera downloadFromUdi %i > > where %i is the "device ID" (something like .../freedesktop/...). Is > there a similar way to start up shotwell, to take it straight to the > camera import page? (Not that the extra click is a major > inconvenience, but it would make the whole experience that much > slicker.) > > > best regards, > Kevin Brubeck Unhammer > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Sat Sep 11 02:10:31 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 10 Sep 2010 19:10:31 -0700 Subject: [Shotwell] Announcement: Shotwell 0.7.2 released Message-ID: Yorba has released Shotwell 0.7.2, an update to our digital photo organizer. This release includes crucial fixes and translation updates. It's highly recommended that all users upgrade. This release includes the following: * Fixed major startup problem when the user's Pictures directory is actually a symbolic link. * Fixed potential crasher when the user's Pictures directory contains a large number of subdirectories. * No longer asking if copying or linking if importing from Pictures directory (which will always be linked). * Fixed issue when logging in to PicasaWeb with a password with a '+' character. * Fixed update problem when using an external editor on a photo that was edited externally in an earlier session. * Various bug fixes. * Updated translations Download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ Binaries for Ubuntu Lucid and Maverick are available at Yorba's Launchpad PPA: https://launchpad.net/~yorba/+archive/ppa Cheers, -- Jim Nelson From p.ixiemotion at gmail.com Sat Sep 11 06:42:51 2010 From: p.ixiemotion at gmail.com (Kevin Brubeck Unhammer) Date: Sat, 11 Sep 2010 08:42:51 +0200 Subject: [Shotwell] Using Shotwell as camera importer in KDE In-Reply-To: References: Message-ID: 2010/9/10 Jim Nelson : > Hello, > > Yes, Shotwell does have something like this.? You need to put the path to > the camera device on the command-line in URI format, much like what you're > describing.? There's no additional arguments; Shotwell will detect if it's a > URI and map it into the device. > > If you look at the shotwell.desktop file (shotwell.desktop.head in the tar > ball), you'll see how it's described there: > > shotwell %U > > Where %U is the file path in URL format. When I try using %i (device ID, which is what digikam uses) I get the following error: /org/freedesktop/Hal/devices/usb_device_4a9_319a_noserial_if0 does not exist. while the two other choices (%f - mount point for storage devices, and %d - device node address for block devices) have the same effect as not having an argument at all. I tried running shotwell "file://org/freedesktop/Hal/devices/usb_device_4a9_319a_noserial_if0" but that too was as if I had given no argument... is that what is meant by URL format? -Kevin > On Fri, Sep 10, 2010 at 5:47 AM, Kevin Brubeck Unhammer > wrote: >> >> Hi, >> >> I know KDE users are supposed to use DigiKam, but it's way too huge >> and slow for what I need; Shotwell however seems to have exactly the >> features I want while staying quick and responsive :-) >> >> The one thing I'm wondering about is if there's a way to make the usb >> notifier go straight to camera import when I click it. In KDE's system >> settings for device actions, the digikam command is: >> >> /usr/share/apps/digikam/utils/digikam-camera downloadFromUdi %i >> >> where %i is the "device ID" (something like .../freedesktop/...). Is >> there a similar way to start up shotwell, to take it straight to the >> camera import page? (Not that the extra click is a major >> inconvenience, but it would make the whole experience that much >> slicker.) >> >> >> best regards, >> Kevin Brubeck Unhammer >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From caccolangrifata at gmail.com Sat Sep 11 10:35:23 2010 From: caccolangrifata at gmail.com (caccolangrifata) Date: Sat, 11 Sep 2010 12:35:23 +0200 Subject: [Shotwell] Duplicate a photo Message-ID: <1284201323.2671.12.camel@mind> Hi! I use Shotwell since 0.4 version bla bla :) and you're doing a great work. I'm writing here because I think "Duplicate" command must work differently. When a photo is duplicated a copy of that photo is created in "~/Immagini/YYYY/MM/DD/" folder even if the photo is linked. I think duplicated photo file must be saved in the same folder of the origin file, because if I link photo I don't want save my photo to Shotwell default folder. -- Emanuele Grande OpenPGP key: 1024D/BF9328A7 | j.mp/cJTR3C 9F22 91FE F054 185D 3376 910E 62B3 85D6 BF93 28A7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From adam at yorba.org Sun Sep 12 13:02:24 2010 From: adam at yorba.org (Adam Dingle) Date: Sun, 12 Sep 2010 06:02:24 -0700 Subject: [Shotwell] Duplicate a photo In-Reply-To: <1284201323.2671.12.camel@mind> References: <1284201323.2671.12.camel@mind> Message-ID: Emanuele, 2010/9/11 caccolangrifata > Hi! > > I use Shotwell since 0.4 version bla bla :) and you're doing a great > work. > Thanks! > > I'm writing here because I think "Duplicate" command must work > differently. > When a photo is duplicated a copy of that photo is created in > "~/Immagini/YYYY/MM/DD/" folder even if the photo is linked. > I think duplicated photo file must be saved in the same folder of the > origin file, because if I link photo I don't want save my photo to > Shotwell default folder. That's a reasonable suggestion. Since Shotwell is non-destructive, it might even be nice if the Duplicate command didn't create any new photo file at all - the duplicate copy in Shotwell could simply share the original file. In any case, I've created a ticket here: http://trac.yorba.org/ticket/2545 adam From weirdit at gmail.com Mon Sep 13 07:57:28 2010 From: weirdit at gmail.com (Tim) Date: Mon, 13 Sep 2010 17:57:28 +1000 Subject: [Shotwell] Export pictures misorientated In-Reply-To: <1284045187.2012.492.camel@antiloop> References: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> <1284045187.2012.492.camel@antiloop> Message-ID: On 10 September 2010 01:13, Mattias P?ldaru wrote: > JPG files can contain EXIF data, which specifies it's orientation. This > is good, because JPEG is lossy format and every time you reencode it, > you loose some information. Doing real rotate in file is not possible > without reencoding. > The problem is, not all software can handle EXIF rotate right. But GIMP > can, it asks on opening, whether to rotate the image or not (since it > has to reencode it anyway). Apparently this isn't so. jpegtran (in package libjpeg-progs in Ubuntu/Debian) has a lossless rotator (plus a few other functions). >From the man page. jpegtran works by rearranging the compressed data (DCT coefficients), without ever fully decoding the image. Therefore, its transformations are lossless: there is no image degradation at all, which would not be true if you used djpeg followed by cjpeg to accomplish the same conver? sion. But by the same token, jpegtran cannot perform lossy operations such as changing the image quality. More information should be at http://jpegclub.org/ I believe not every JPEG can be rotated in this fasion, but a good number can be. Personally, I prefer if the camera ether rotates it, or the final viewing software rotates it. But maybe an option at import time to rotate images would be good? My old camera import script would run all my photos through exiftran which does the same lossless rotations as jpegtran but also updates the exif information to reflect the rotation (and got the rotation direction from the exif). http://linux.bytesex.org/fbida/ for exiftran Tim -- Timothy White - Somewhere in Australia From mahfiaz at gmail.com Mon Sep 13 08:17:02 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Mon, 13 Sep 2010 11:17:02 +0300 Subject: [Shotwell] Export pictures misorientated In-Reply-To: References: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> <1284045187.2012.492.camel@antiloop> Message-ID: <1284365822.17221.215.camel@antiloop> ?hel kenal p?eval, E, 2010-09-13 kell 17:57, kirjutas Tim: > On 10 September 2010 01:13, Mattias P?ldaru wrote: > > JPG files can contain EXIF data, which specifies it's orientation. This > > is good, because JPEG is lossy format and every time you reencode it, > > you loose some information. Doing real rotate in file is not possible > > without reencoding. > > The problem is, not all software can handle EXIF rotate right. But GIMP > > can, it asks on opening, whether to rotate the image or not (since it > > has to reencode it anyway). > > Apparently this isn't so. jpegtran (in package libjpeg-progs in > Ubuntu/Debian) has a lossless rotator (plus a few other functions). > > From the man page. > > jpegtran works by rearranging the compressed data (DCT coefficients), > without ever fully decoding the image. Therefore, its transformations > are lossless: there is no image degradation at all, which would not be > true if you used djpeg followed by cjpeg to accomplish the same conver? > sion. But by the same token, jpegtran cannot perform lossy operations > such as changing the image quality. > > More information should be at http://jpegclub.org/ > I believe not every JPEG can be rotated in this fasion, but a good > number can be. > > Personally, I prefer if the camera ether rotates it, or the final > viewing software rotates it. But maybe an option at import time to > rotate images would be good? My old camera import script would run all > my photos through exiftran which does the same lossless rotations as > jpegtran but also updates the exif information to reflect the rotation > (and got the rotation direction from the exif). > http://linux.bytesex.org/fbida/ for exiftran > > Tim > Thank you for clarification. I really didn't know about jpegtran. Would you file a feature request for this? Such an option on importing from camera sounds reasonable (this would also need removing the EXIF rotation information). I hope developers agree :) Mattias From jim at yorba.org Mon Sep 13 22:18:23 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 13 Sep 2010 15:18:23 -0700 Subject: [Shotwell] Using Shotwell as camera importer in KDE In-Reply-To: References: Message-ID: No. Under GNOME / GVFS, cameras are mounted as gphoto2: or disk: URIs. Shotwell will attempt to convert a file: URI to a gPhoto2 camera object, but the file URI you listed is for a HAL device, not a GVFS mount point. That's the key here -- you have to be running GVFS to have a URI that can be converted to a gPhoto camera object. I don't know enough about KDE to know if that's possible or how to go about doing it. You may be running it right now, but those are not the URIs Shotwell needs to see. -- Jim On Fri, Sep 10, 2010 at 11:42 PM, Kevin Brubeck Unhammer < p.ixiemotion at gmail.com> wrote: > 2010/9/10 Jim Nelson : > > Hello, > > > > Yes, Shotwell does have something like this. You need to put the path to > > the camera device on the command-line in URI format, much like what > you're > > describing. There's no additional arguments; Shotwell will detect if > it's a > > URI and map it into the device. > > > > If you look at the shotwell.desktop file (shotwell.desktop.head in the > tar > > ball), you'll see how it's described there: > > > > shotwell %U > > > > Where %U is the file path in URL format. > > When I try using %i (device ID, which is what digikam uses) I get the > following error: > > /org/freedesktop/Hal/devices/usb_device_4a9_319a_noserial_if0 does not > exist. > > while the two other choices (%f - mount point for storage devices, and > %d - device node address for block devices) have the same effect as > not having an argument at all. > > I tried running > > shotwell > "file://org/freedesktop/Hal/devices/usb_device_4a9_319a_noserial_if0" > > but that too was as if I had given no argument... is that what is > meant by URL format? > > > -Kevin > > > On Fri, Sep 10, 2010 at 5:47 AM, Kevin Brubeck Unhammer > > wrote: > >> > >> Hi, > >> > >> I know KDE users are supposed to use DigiKam, but it's way too huge > >> and slow for what I need; Shotwell however seems to have exactly the > >> features I want while staying quick and responsive :-) > >> > >> The one thing I'm wondering about is if there's a way to make the usb > >> notifier go straight to camera import when I click it. In KDE's system > >> settings for device actions, the digikam command is: > >> > >> /usr/share/apps/digikam/utils/digikam-camera downloadFromUdi %i > >> > >> where %i is the "device ID" (something like .../freedesktop/...). Is > >> there a similar way to start up shotwell, to take it straight to the > >> camera import page? (Not that the extra click is a major > >> inconvenience, but it would make the whole experience that much > >> slicker.) > >> > >> > >> best regards, > >> Kevin Brubeck Unhammer > >> _______________________________________________ > >> Shotwell mailing list > >> Shotwell at lists.yorba.org > >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > From weirdit at gmail.com Tue Sep 14 00:26:28 2010 From: weirdit at gmail.com (Tim) Date: Tue, 14 Sep 2010 10:26:28 +1000 Subject: [Shotwell] Export pictures misorientated In-Reply-To: <1284365822.17221.215.camel@antiloop> References: <20100909145943.B1BF8135DF@relay2-v.mail.gandi.net> <1284045187.2012.492.camel@antiloop> <1284365822.17221.215.camel@antiloop> Message-ID: Filed: http://trac.yorba.org/ticket/2555 On 13 September 2010 18:17, Mattias P?ldaru wrote: > ?hel kenal p?eval, E, 2010-09-13 kell 17:57, kirjutas Tim: >> On 10 September 2010 01:13, Mattias P?ldaru wrote: >> > JPG files can contain EXIF data, which specifies it's orientation. This >> > is good, because JPEG is lossy format and every time you reencode it, >> > you loose some information. Doing real rotate in file is not possible >> > without reencoding. >> > The problem is, not all software can handle EXIF rotate right. But GIMP >> > can, it asks on opening, whether to rotate the image or not (since it >> > has to reencode it anyway). >> >> Apparently this isn't so. jpegtran (in package libjpeg-progs in >> Ubuntu/Debian) has a lossless rotator (plus a few other functions). >> >> From the man page. >> >> ? ? ? ?jpegtran ?works ?by rearranging the compressed data (DCT coefficients), >> ? ? ? ?without ever fully decoding the image. ?Therefore, its ?transformations >> ? ? ? ?are ?lossless: there is no image degradation at all, which would not be >> ? ? ? ?true if you used djpeg followed by cjpeg to accomplish the same conver? >> ? ? ? ?sion. ? But by the same token, jpegtran cannot perform lossy operations >> ? ? ? ?such as changing the image quality. >> >> More information should be at http://jpegclub.org/ >> I believe not every JPEG can be rotated in this fasion, but a good >> number can be. >> >> Personally, I prefer if the camera ether rotates it, or the final >> viewing software rotates it. But maybe an option at import time to >> rotate images would be good? My old camera import script would run all >> my photos through exiftran which does the same lossless rotations as >> jpegtran but also updates the exif information to reflect the rotation >> (and got the rotation direction from the exif). >> http://linux.bytesex.org/fbida/ for exiftran >> >> Tim >> > Thank you for clarification. I really didn't know about jpegtran. Would > you file a feature request for this? Such an option on importing from > camera sounds reasonable (this would also need removing the EXIF > rotation information). I hope developers agree :) > > Mattias > > -- Timothy White - Somewhere in Australia From simonspa at kth.se Tue Sep 14 09:07:40 2010 From: simonspa at kth.se (Simon Spannagel) Date: Tue, 14 Sep 2010 11:07:40 +0200 Subject: [Shotwell] Exporting tags Message-ID: <4C8F3B5C.9010507@kth.se> Hej everybody, I want to propose another feature: I realized, that the actual export functionality of shotwell automatically exports all tags, ratings (and titles?) to the created files. I think this should be only an option and not the standard procedure - perhaps I could have some private tags which I don't want to share with others. What do you think about this? kind regards, Simon From take at nerd.fi Tue Sep 14 11:03:57 2010 From: take at nerd.fi (Take) Date: Tue, 14 Sep 2010 14:03:57 +0300 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <20100906192822.GA5731@talktalkplc.com> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> <20100906192822.GA5731@talktalkplc.com> Message-ID: <4C8F569D.8060105@nerd.fi> On 09/06/2010 10:28 PM, Brian Candler wrote: > That's one usage model. In my case I like to sync files to my laptop using > "unison" - I have fast off-line access to them, and it acts as a backup. Well, this could be taken care of with the 'root folder' -setting I mentioned in previous post. This way you could sync images to $anywhere and set that rootdir properly and, since information in database would be related to that rootdir, you could access your files in the same way regardless of the machine. Of course you need to maintain sync for database, but with sqlite that's fairly simple and with proper API I suppose it could be easy(ish) to handle even with shotwell itself. > Unfortunately, whatever you do isn't going to please everyone :-( This is true, there's atleast as many usage models as there are users. Anyways, support for multiple computers, regardless of the storage model etc, is an key feature for shotwell. -- Take From adam at yorba.org Tue Sep 14 14:41:32 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 14 Sep 2010 07:41:32 -0700 Subject: [Shotwell] Exporting tags In-Reply-To: <4C8F3B5C.9010507@kth.se> References: <4C8F3B5C.9010507@kth.se> Message-ID: <4C8F899C.9010301@yorba.org> Simon, we could consider something like this, but how would this work exactly? I suppose the export dialog could have a checkbox called "Export metadata", checked by default. If this checkbox is cleared, then Shotwell would not export tags, ratings or titles. But now suppose that a photo imported into Shotwell has tags, ratings and titles which came from the original JPEG file, and that the user then added one more tag in Shotwell. If the user chooses not to export metadata, then would Shotwell export only the tags that were present in the original photo, or none at all? adam On 09/14/2010 02:07 AM, Simon Spannagel wrote: > Hej everybody, > > I want to propose another feature: > I realized, that the actual export functionality of shotwell > automatically exports all tags, ratings (and titles?) to the created files. > > I think this should be only an option and not the standard procedure - > perhaps I could have some private tags which I don't want to share with > others. > > What do you think about this? > > kind regards, > Simon > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From florian at manach.fr Tue Sep 14 15:19:12 2010 From: florian at manach.fr (=?utf-8?B?RmxvcmlhbiBNYW5hY2g=?=) Date: Tue, 14 Sep 2010 17:19:12 +0200 Subject: [Shotwell] =?utf-8?q?Re_=3A__Exporting_tags?= Message-ID: <20100914151820.42497225142@relay2-d.mail.gandi.net> IMHO an option called "export metadata" should not export any metadata at all if it is unchecked. -- Cordialement, Florian Manach ----- Reply message ----- De : "Adam Dingle" Date : mar., sept. 14, 2010 16:41 Objet : [Shotwell] Exporting tags Pour?: Simon, we could consider something like this, but how would this work exactly? I suppose the export dialog could have a checkbox called "Export metadata", checked by default. If this checkbox is cleared, then Shotwell would not export tags, ratings or titles. But now suppose that a photo imported into Shotwell has tags, ratings and titles which came from the original JPEG file, and that the user then added one more tag in Shotwell. If the user chooses not to export metadata, then would Shotwell export only the tags that were present in the original photo, or none at all? adam On 09/14/2010 02:07 AM, Simon Spannagel wrote: > Hej everybody, > > I want to propose another feature: > I realized, that the actual export functionality of shotwell > automatically exports all tags, ratings (and titles?) to the created files. > > I think this should be only an option and not the standard procedure - > perhaps I could have some private tags which I don't want to share with > others. > > What do you think about this? > > kind regards, > Simon > _______________________________________________ > 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 gpopac at gmail.com Tue Sep 14 16:15:04 2010 From: gpopac at gmail.com (Milos Popovic) Date: Tue, 14 Sep 2010 18:15:04 +0200 Subject: [Shotwell] Standardize some keyboard shortcuts Message-ID: <1284480904.3231.2.camel@mobil-gentoo> In other software Key 1 zooms to 100% Key 2 zooms to 200% If it is implemented in Shotwell, ratings can be managed with Ctrl +[1,2,3,4,5] What do you think about this? Best regards, Milo? Popovi? From adam at yorba.org Tue Sep 14 16:30:57 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 14 Sep 2010 09:30:57 -0700 Subject: [Shotwell] Standardize some keyboard shortcuts In-Reply-To: <1284480904.3231.2.camel@mobil-gentoo> References: <1284480904.3231.2.camel@mobil-gentoo> Message-ID: <4C8FA341.2040400@yorba.org> Milos, I think we'll keep the current shortcuts for two reasons: 1) We want Shotwell's shortcuts to be consistent with other GNOME applications. The GNOME interface guidelines recommend that Ctrl+0 restore the zoom level to normal size (see http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#standard-shortcuts ). Given this, it makes sense to use Ctrl+1 and Ctrl+2 to zoom to different levels. 2) Many users who rate photos will probably want to apply ratings using the keyboard much more often then they will want to zoom to specific levels. For this reason, it makes sense for the keyboard rating shortcuts to be as easy to type as possible. adam On 09/14/2010 09:15 AM, Milos Popovic wrote: > In other software > Key 1 zooms to 100% > Key 2 zooms to 200% > > If it is implemented in Shotwell, ratings can be managed with Ctrl > +[1,2,3,4,5] > > What do you think about this? > > > Best regards, > Milo? Popovi? > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From simonspa at kth.se Tue Sep 14 16:57:15 2010 From: simonspa at kth.se (Simon Spannagel) Date: Tue, 14 Sep 2010 18:57:15 +0200 Subject: [Shotwell] Exporting tags In-Reply-To: <4C8F899C.9010301@yorba.org> References: <4C8F3B5C.9010507@kth.se> <4C8F899C.9010301@yorba.org> Message-ID: <4C8FA96B.5040808@kth.se> Hej Adam, hej Florian and list, I think - like Florian does - then Shotwell shouldn't export any metadata at all. I assume that in most cases there is no need for restoring the original imported metadata (and how would you separate that data from added ones if we get in-file-tags with the next version?) for exporting a file. To keep things simple, the user has just to decide whether he wants to export the whole metadata or nothing at all. I think this would be enough. Further I agree with Vincent that this should not be the default, but the checkbox you proposed seems to be a very good (and quick'n'easy) option for solving this issue... greetings from Sverige, Simon Am 14.09.2010 16:41, schrieb Adam Dingle: > Simon, > > we could consider something like this, but how would this work exactly? > I suppose the export dialog could have a checkbox called "Export > metadata", checked by default. If this checkbox is cleared, then > Shotwell would not export tags, ratings or titles. But now suppose that > a photo imported into Shotwell has tags, ratings and titles which came > from the original JPEG file, and that the user then added one more tag > in Shotwell. If the user chooses not to export metadata, then would > Shotwell export only the tags that were present in the original photo, > or none at all? > > adam > > On 09/14/2010 02:07 AM, Simon Spannagel wrote: > >> Hej everybody, >> >> I want to propose another feature: >> I realized, that the actual export functionality of shotwell >> automatically exports all tags, ratings (and titles?) to the created files. >> >> I think this should be only an option and not the standard procedure - >> perhaps I could have some private tags which I don't want to share with >> others. >> >> What do you think about this? >> >> kind regards, >> Simon >> _______________________________________________ >> 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 adam at yorba.org Tue Sep 14 17:03:16 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 14 Sep 2010 10:03:16 -0700 Subject: [Shotwell] Exporting tags In-Reply-To: <4C8FA96B.5040808@kth.se> References: <4C8F3B5C.9010507@kth.se> <4C8F899C.9010301@yorba.org> <4C8FA96B.5040808@kth.se> Message-ID: <4C8FAAD4.7090204@yorba.org> OK, sounds good. I've ticketed this here: http://trac.yorba.org/ticket/2556 greetings from San Francisco, adam On 09/14/2010 09:57 AM, Simon Spannagel wrote: > Hej Adam, hej Florian and list, > > I think - like Florian does - then Shotwell shouldn't export any > metadata at all. I assume that in most cases there is no need for > restoring the original imported metadata (and how would you separate > that data from added ones if we get in-file-tags with the next version?) > for exporting a file. > To keep things simple, the user has just to decide whether he wants to > export the whole metadata or nothing at all. I think this would be enough. > > Further I agree with Vincent that this should not be the default, but > the checkbox you proposed seems to be a very good (and quick'n'easy) > option for solving this issue... > > greetings from Sverige, > Simon > > > > Am 14.09.2010 16:41, schrieb Adam Dingle: >> Simon, >> >> we could consider something like this, but how would this work exactly? >> I suppose the export dialog could have a checkbox called "Export >> metadata", checked by default. If this checkbox is cleared, then >> Shotwell would not export tags, ratings or titles. But now suppose that >> a photo imported into Shotwell has tags, ratings and titles which came >> from the original JPEG file, and that the user then added one more tag >> in Shotwell. If the user chooses not to export metadata, then would >> Shotwell export only the tags that were present in the original photo, >> or none at all? >> >> adam >> >> On 09/14/2010 02:07 AM, Simon Spannagel wrote: >> >>> Hej everybody, >>> >>> I want to propose another feature: >>> I realized, that the actual export functionality of shotwell >>> automatically exports all tags, ratings (and titles?) to the created files. >>> >>> I think this should be only an option and not the standard procedure - >>> perhaps I could have some private tags which I don't want to share with >>> others. >>> >>> What do you think about this? >>> >>> kind regards, >>> Simon >>> _______________________________________________ >>> 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 >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From pdo.smith at gmail.com Tue Sep 14 18:03:43 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 14 Sep 2010 20:03:43 +0200 Subject: [Shotwell] Standardize some keyboard shortcuts In-Reply-To: <4C8FA341.2040400@yorba.org> References: <1284480904.3231.2.camel@mobil-gentoo> <4C8FA341.2040400@yorba.org> Message-ID: Yes, I think that makes a lot of sense. I agree that the we want a simple shortcut key to apply ratings. On Tue, Sep 14, 2010 at 6:30 PM, Adam Dingle wrote: > Milos, > > I think we'll keep the current shortcuts for two reasons: > > 1) We want Shotwell's shortcuts to be consistent with other GNOME > applications. The GNOME interface guidelines recommend that Ctrl+0 > restore the zoom level to normal size (see > > http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#standard-shortcuts > ). Given this, it makes sense to use Ctrl+1 and Ctrl+2 to zoom to > different levels. > > 2) Many users who rate photos will probably want to apply ratings using > the keyboard much more often then they will want to zoom to specific > levels. For this reason, it makes sense for the keyboard rating > shortcuts to be as easy to type as possible. > > adam > > On 09/14/2010 09:15 AM, Milos Popovic wrote: > > In other software > > Key 1 zooms to 100% > > Key 2 zooms to 200% > > > > If it is implemented in Shotwell, ratings can be managed with Ctrl > > +[1,2,3,4,5] > > > > What do you think about this? > > > > > > Best regards, > > Milo? Popovi? > > > > _______________________________________________ > > 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 B.Candler at pobox.com Tue Sep 14 18:23:40 2010 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 14 Sep 2010 19:23:40 +0100 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C8F569D.8060105@nerd.fi> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> <20100906192822.GA5731@talktalkplc.com> <4C8F569D.8060105@nerd.fi> Message-ID: <20100914182340.GA5816@talktalkplc.com> On Tue, Sep 14, 2010 at 02:03:57PM +0300, Take wrote: > > That's one usage model. In my case I like to sync files to my laptop using > > "unison" - I have fast off-line access to them, and it acts as a backup. > > Well, this could be taken care of with the 'root folder' -setting I > mentioned in previous post. This way you could sync images to $anywhere > and set that rootdir properly and, since information in database would > be related to that rootdir, you could access your files in the same way > regardless of the machine. > > Of course you need to maintain sync for database, but with sqlite that's > fairly simple It is? How?? I could 'unison' the underlying sqlite3 db file - but a single conflicting change made at both sides would cause all subsequent replication to fail, until I decided which side wins (which would lose all changes made at the other side). Otherwise, I can't see how you could do it without writing a Shotwell-specific replicator, and adding further columns or tables into the database schema to support conflict resolution (e.g. history of changes) In any case, coming from a Unix background, of small tools and open data, I'm uncomfortable with the database approach. Sure, it's fast to access, but it's (a) monolithic, (b) fragile, and (c) closed (in as much as you need to reverse engineer to get at your work) If metadata is stored in separate XMP files, or within the JPEGs (I don't mind which), then loss or corruption of an individual file is not catastrophic. But if a single-file sqlite3 database becomes corrupt, and I don't happen to have an up-to-date backup, then everything is lost. Hmm, I guess I'm talking myself into using gthumb again. It's a shame, as there's a lot of things I like about shotwell's UI, such as being able to browse events with a representative title photo on each one. Regards, Brian. From oystwa at gmail.com Tue Sep 14 18:46:27 2010 From: oystwa at gmail.com (=?UTF-8?Q?=C3=98ystein_Walle?=) Date: Tue, 14 Sep 2010 20:46:27 +0200 Subject: [Shotwell] Standardize some keyboard shortcuts In-Reply-To: References: <1284480904.3231.2.camel@mobil-gentoo> <4C8FA341.2040400@yorba.org> Message-ID: Hi everyone, my first mail to the mailing list :) Using numbers in combo with Ctrl is fine IMHO and I agree with Peter; I find that I rate photos more often than I inspect them at 100% zoom. There are large inconsistencies with the Shotwell photo viewer, however. It still uses only "1" for 100% zoom. It appears that also Ctrl+0 (but not only 0) does this, instead of fitting to window. But 2/Ctrl+2 does not produce 200% zoom. Regards, ?ystein Walle From Sebastian at SSpaeth.de Tue Sep 14 19:00:40 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Tue, 14 Sep 2010 21:00:40 +0200 Subject: [Shotwell] Standardize some keyboard shortcuts In-Reply-To: References: <1284480904.3231.2.camel@mobil-gentoo> <4C8FA341.2040400@yorba.org> Message-ID: <874odstajr.fsf@SSpaeth.de> On 2010-09-14, Peter DO Smith wrote: > Yes, I think that makes a lot of sense. I agree that the we want a simple > shortcut key to apply ratings. +1 From adam at yorba.org Tue Sep 14 19:14:27 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 14 Sep 2010 12:14:27 -0700 Subject: [Shotwell] Standardize some keyboard shortcuts In-Reply-To: References: <1284480904.3231.2.camel@mobil-gentoo> <4C8FA341.2040400@yorba.org> Message-ID: <4C8FC993.8080508@yorba.org> On 09/14/2010 11:46 AM, ?ystein Walle wrote: > Hi everyone, my first mail to the mailing list :) Welcome! :) > Using numbers in combo with Ctrl is fine IMHO and I agree with Peter; I find > that I rate photos more often than I inspect them at 100% zoom. > > There are large inconsistencies with the Shotwell photo viewer, however. It > still uses only "1" for 100% zoom. It appears that also Ctrl+0 (but not only > 0) does this, instead of fitting to window. But 2/Ctrl+2 does not produce > 200% zoom. > Good point - somehow this escaped our notice until now. I've created a ticket here: http://trac.yorba.org/ticket/2558 We'll certainly fix this for 0.8. adam From take at nerd.fi Wed Sep 15 06:18:34 2010 From: take at nerd.fi (Take) Date: Wed, 15 Sep 2010 09:18:34 +0300 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <20100914182340.GA5816@talktalkplc.com> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> <20100906192822.GA5731@talktalkplc.com> <4C8F569D.8060105@nerd.fi> <20100914182340.GA5816@talktalkplc.com> Message-ID: <4C90653A.4080802@nerd.fi> On 09/14/2010 09:23 PM, Brian Candler wrote: > I could 'unison' the underlying sqlite3 db file - but a single conflicting > change made at both sides would cause all subsequent replication to fail, > until I decided which side wins (which would lose all changes made at the > other side). Sorry, my bad, I just tought of the file sync, not the content, so, you're right, it's not simpe with sqlite. With i.e. MySQL that's whole another matter since it's possible to store binlog and sync changes step-by-step, but that's not really simple to set up. > Otherwise, I can't see how you could do it without writing a > Shotwell-specific replicator, and adding further columns or tables into the > database schema to support conflict resolution (e.g. history of changes) How about an a bit different approach. Use separate XMP-files and run some small(ish) version control (ie. RCS) with them. Then one could (possibly) sync metadata via that version control and diff-patch(-ish) -procedure. Actual photos would sync as plain files, so rsync or derivatives can take care of that. Separate metadata files however raise more questions, like how to index them for faster search. > but it's (a) monolithic, (b) fragile, and (c) closed (in as much as you need > to reverse engineer to get at your work) I don't want to store my photos into database either, just the metadata. There's absolutely no sense to push actual files into database for obvious reasons (I like to access my files with file browser, not with database "browser"). > If metadata is stored in separate XMP files, or within the JPEGs (I don't > mind which), then loss or corruption of an individual file is not If metadata is stored to images, it'll require an image format which supports it. Even if there's a wide range of formats it's not supported in every format, so my "vote" goes to separate files with this approach. With separate XMP files it might even be possible to migrate changes on conflict situations. -- Take From pdo.smith at gmail.com Wed Sep 15 11:18:33 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Wed, 15 Sep 2010 13:18:33 +0200 Subject: [Shotwell] Slow start up Message-ID: My installation of Shotwell is suffering from slow start up again, but under very specific circumstances. It took 34 minutes to start up. During this time Shotwell was greyed out and unresponsive. CPU usage varied from 40% to 99% I downloaded and compiled the latest version from trunk yesterday morning. I maintain two identical installations of my photo library in Ubuntu Linux (10.04), one at Home and one in my Office. The Shotwell data folder is kept in the Pictures folder (to make backup simpler) and I invoke Shotwell as follows shotwell -d /home/peter/Pictures/shotwell My Home installation is my primary installation where I load photos. Then I use Unison to synchronise my Pictures folder to a USB drive. The Pictures folder is then restored from the USB drive to my Office machine, once again using Unison. This strategy has worked well until now. Since yesterday, when I start up Shotwell on my Office machine after restoring from my USB drive, I find that Shotwell is greyed out and unresponsive for more than 30 minutes. If I then close down Shotwell and restart it starts up quickly, as it did before. I used Unison to see if the folders had changed. This showed me that Shotwell had rebuilt 7904 thumbnails (both 128 and 360 bit) but that the primary photos were still identical. I have 9668 photos in my library. Both sets of folders are identical in every other respect, except, as expected, the database had been updated As far as I can tell Unison does does an excellent job maintaining identical, synchronised folders. Why would Shotwell rebuild the thumbnails? (many but not all) Could the rebuild process not run in a separate thread at lower priority to avoid this extended unresponsive period? Thanks for including the No Events folder. That is a real life saver when I am scanning film. Peter From humphreybc at gmail.com Wed Sep 15 12:52:45 2010 From: humphreybc at gmail.com (Benjamin Humphrey) Date: Thu, 16 Sep 2010 00:52:45 +1200 Subject: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2 Message-ID: Hi guys, I noticed in the main menu of Shotwell, a lot of menu items are disabled or "greyed out," such as: In the 'File' menu: Export Print Publish Set as desktop background Show in file manager Events > New Event Almost everything in the Photos and Tags menus I was trying to figure out why this might be. I do shoot in RAW, but this happens with JPG images as well. I am using the indicator-appmenu (global menu type thing in Ubuntu), but I don't think this is the problem as other options seem to work fine. I would screenshot but I suffer from this bug: https://bugs.launchpad.net/indicator-appmenu/+bug/603482 It's interesting that the Export option is greyed out in the File menu, but if I drag and drop a photo to a folder or the desktop, it exports fine. I also don't seem to have an option to upload to Flickr, Facebook etc. I thought that feature was in Shotwell? Thanks, -- Benjamin Humphrey interesting.co.nz ohso.co From linuzzz at yahoo.it Wed Sep 15 12:59:14 2010 From: linuzzz at yahoo.it (linuzzz) Date: Wed, 15 Sep 2010 05:59:14 -0700 (PDT) Subject: [Shotwell] photo duplicate...how does it work? Message-ID: <1284555554076-22496.post@talk.nabble.com> Hi, i'm using shotwell 0.7.2 on fedora 13 and I have some strange result when importing photo: to setup a test I made a clean database, then imported only two photo (the ones that failed in previous imports) and shotwell told me that one was a duplicate so imported just one. But the two photo are very different in name, size, exif data...let me show: [linuzzz at f13 jpeg3]$ jhead * File name : IMG_5207.jpg File size : 5788694 bytes File date : 2010:07:31 09:03:36 Camera make : Canon Camera model : Canon EOS 1000D Date/Time : 2010:07:31 09:03:36 Resolution : 3906 x 2602 Flash used : No Focal length : 50.0mm (35mm equivalent: -2147483648mm) Exposure time: 0.0003 s (1/3200) Aperture : f/1.8 ISO equiv. : 100 Whitebalance : Auto Metering Mode: pattern Exposure : aperture priority (semi-auto) File name : IMG_5234.jpg File size : 5059257 bytes File date : 2010:07:31 09:28:37 Camera make : Canon Camera model : Canon EOS 1000D Date/Time : 2010:07:31 09:28:37 Resolution : 3906 x 1644 Flash used : No Focal length : 50.0mm (35mm equivalent: -2147483648mm) Exposure time: 0.0063 s (1/160) Aperture : f/3.5 ISO equiv. : 100 Exposure bias: 0.67 Whitebalance : Auto Metering Mode: pattern Exposure : program (auto) thanks for Your support and for the amazing sw you're developing :-) linuzzz -- View this message in context: http://shotwell.3510.www.nabble.com/photo-duplicate-how-does-it-work-tp22496p22496.html Sent from the Shotwell mailing list archive at Nabble.com. From mahfiaz at gmail.com Wed Sep 15 13:20:51 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 15 Sep 2010 16:20:51 +0300 Subject: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2 In-Reply-To: References: Message-ID: <1284556851.17221.2932.camel@antiloop> ?hel kenal p?eval, N, 2010-09-16 kell 00:52, kirjutas Benjamin Humphrey: > Hi guys, > > I noticed in the main menu of Shotwell, a lot of menu items are disabled or > "greyed out," such as: > > In the 'File' menu: > > Export > Print > Publish > Set as desktop background > Show in file manager > > Events > New Event > > Almost everything in the Photos and Tags menus > > I was trying to figure out why this might be. I do shoot in RAW, but this > happens with JPG images as well. I am using the indicator-appmenu (global > menu type thing in Ubuntu), but I don't think this is the problem as other > options seem to work fine. > > I would screenshot but I suffer from this bug: > https://bugs.launchpad.net/indicator-appmenu/+bug/603482 > > It's interesting that the Export option is greyed out in the File menu, but > if I drag and drop a photo to a folder or the desktop, it exports fine. > > I also don't seem to have an option to upload to Flickr, Facebook etc. I > thought that feature was in Shotwell? > > Thanks, > Select at least one picture and check the menus again. Mattias From humphreybc at gmail.com Wed Sep 15 13:22:08 2010 From: humphreybc at gmail.com (Benjamin Humphrey) Date: Thu, 16 Sep 2010 01:22:08 +1200 Subject: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2 In-Reply-To: <1284556851.17221.2932.camel@antiloop> References: <1284556851.17221.2932.camel@antiloop> Message-ID: Still missing. On Thu, Sep 16, 2010 at 1:20 AM, Mattias P?ldaru wrote: > ?hel kenal p?eval, N, 2010-09-16 kell 00:52, kirjutas Benjamin Humphrey: > > Hi guys, > > > > I noticed in the main menu of Shotwell, a lot of menu items are disabled > or > > "greyed out," such as: > > > > In the 'File' menu: > > > > Export > > Print > > Publish > > Set as desktop background > > Show in file manager > > > > Events > New Event > > > > Almost everything in the Photos and Tags menus > > > > I was trying to figure out why this might be. I do shoot in RAW, but this > > happens with JPG images as well. I am using the indicator-appmenu (global > > menu type thing in Ubuntu), but I don't think this is the problem as > other > > options seem to work fine. > > > > I would screenshot but I suffer from this bug: > > https://bugs.launchpad.net/indicator-appmenu/+bug/603482 > > > > It's interesting that the Export option is greyed out in the File menu, > but > > if I drag and drop a photo to a folder or the desktop, it exports fine. > > > > I also don't seem to have an option to upload to Flickr, Facebook etc. I > > thought that feature was in Shotwell? > > > > Thanks, > > > > Select at least one picture and check the menus again. > > Mattias > > > -- Benjamin Humphrey interesting.co.nz ohso.co From adam at yorba.org Wed Sep 15 13:52:59 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 15 Sep 2010 06:52:59 -0700 Subject: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2 In-Reply-To: References: Message-ID: Benjamin, thanks for the bug report. This problem is known and is due to the indicator-appmenu. See: http://trac.yorba.org/ticket/2553 https://bugs.launchpad.net/unity/+bug/637692 adam On Wed, Sep 15, 2010 at 5:52 AM, Benjamin Humphrey wrote: > Hi guys, > > I noticed in the main menu of Shotwell, a lot of menu items are disabled or > "greyed out," such as: > > In the 'File' menu: > > Export > Print > Publish > Set as desktop background > Show in file manager > > Events > New Event > > Almost everything in the Photos and Tags menus > > I was trying to figure out why this might be. I do shoot in RAW, but this > happens with JPG images as well. I am using the indicator-appmenu (global > menu type thing in Ubuntu), but I don't think this is the problem as other > options seem to work fine. > > I would screenshot but I suffer from this bug: > https://bugs.launchpad.net/indicator-appmenu/+bug/603482 > > It's interesting that the Export option is greyed out in the File menu, but > if I drag and drop a photo to a folder or the desktop, it exports fine. > > I also don't seem to have an option to upload to Flickr, Facebook etc. I > thought that feature was in Shotwell? > > Thanks, > > -- > Benjamin Humphrey > > interesting.co.nz > ohso.co > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From humphreybc at gmail.com Wed Sep 15 13:57:50 2010 From: humphreybc at gmail.com (Benjamin Humphrey) Date: Thu, 16 Sep 2010 01:57:50 +1200 Subject: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2 In-Reply-To: References: Message-ID: Oh nice, it's assigned to Neil. Hopefully he'll get it fixed soon :) On Thu, Sep 16, 2010 at 1:52 AM, Adam Dingle wrote: > Benjamin, > > thanks for the bug report. This problem is known and is due to the > indicator-appmenu. See: > > http://trac.yorba.org/ticket/2553 > > https://bugs.launchpad.net/unity/+bug/637692 > > adam > > On Wed, Sep 15, 2010 at 5:52 AM, Benjamin Humphrey wrote: > >> Hi guys, >> >> I noticed in the main menu of Shotwell, a lot of menu items are disabled >> or >> "greyed out," such as: >> >> In the 'File' menu: >> >> Export >> Print >> Publish >> Set as desktop background >> Show in file manager >> >> Events > New Event >> >> Almost everything in the Photos and Tags menus >> >> I was trying to figure out why this might be. I do shoot in RAW, but this >> happens with JPG images as well. I am using the indicator-appmenu (global >> menu type thing in Ubuntu), but I don't think this is the problem as other >> options seem to work fine. >> >> I would screenshot but I suffer from this bug: >> https://bugs.launchpad.net/indicator-appmenu/+bug/603482 >> >> It's interesting that the Export option is greyed out in the File menu, >> but >> if I drag and drop a photo to a folder or the desktop, it exports fine. >> >> I also don't seem to have an option to upload to Flickr, Facebook etc. I >> thought that feature was in Shotwell? >> >> Thanks, >> >> -- >> Benjamin Humphrey >> >> interesting.co.nz >> ohso.co >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > -- Benjamin Humphrey interesting.co.nz ohso.co From jim at yorba.org Wed Sep 15 16:35:34 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 Sep 2010 09:35:34 -0700 Subject: [Shotwell] photo duplicate...how does it work? In-Reply-To: <1284555554076-22496.post@talk.nabble.com> References: <1284555554076-22496.post@talk.nabble.com> Message-ID: Odd! Can you send me these two photos? (Don't send to the mailing list, they will be rejected.) Thanks, -- Jim On Wed, Sep 15, 2010 at 5:59 AM, linuzzz wrote: > > Hi, > > i'm using shotwell 0.7.2 on fedora 13 and I have some strange result when > importing photo: > to setup a test I made a clean database, then imported only two photo (the > ones that failed in previous imports) > and shotwell told me that one was a duplicate so imported just one. > But the two photo are very different in name, size, exif data...let me > show: > > [linuzzz at f13 jpeg3]$ jhead * > > File name : IMG_5207.jpg > File size : 5788694 bytes > File date : 2010:07:31 09:03:36 > Camera make : Canon > Camera model : Canon EOS 1000D > Date/Time : 2010:07:31 09:03:36 > Resolution : 3906 x 2602 > Flash used : No > Focal length : 50.0mm (35mm equivalent: -2147483648mm) > Exposure time: 0.0003 s (1/3200) > Aperture : f/1.8 > ISO equiv. : 100 > Whitebalance : Auto > Metering Mode: pattern > Exposure : aperture priority (semi-auto) > > > File name : IMG_5234.jpg > File size : 5059257 bytes > File date : 2010:07:31 09:28:37 > Camera make : Canon > Camera model : Canon EOS 1000D > Date/Time : 2010:07:31 09:28:37 > Resolution : 3906 x 1644 > Flash used : No > Focal length : 50.0mm (35mm equivalent: -2147483648mm) > Exposure time: 0.0063 s (1/160) > Aperture : f/3.5 > ISO equiv. : 100 > Exposure bias: 0.67 > Whitebalance : Auto > Metering Mode: pattern > Exposure : program (auto) > > thanks for Your support and for the amazing sw you're developing :-) > > linuzzz > -- > View this message in context: > http://shotwell.3510.www.nabble.com/photo-duplicate-how-does-it-work-tp22496p22496.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 jim at yorba.org Wed Sep 15 16:52:39 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 Sep 2010 09:52:39 -0700 Subject: [Shotwell] Slow start up In-Reply-To: References: Message-ID: We recently introduced in trunk a new feature for Shotwell: during the startup scan, if it detects a change to the file, it's reimported (on the assumption that it was edited or manipulated by an external program). This is a feature request we've had for some time. The ticket for it is here: http://trac.yorba.org/ticket/2476 Note that reimporting also means regenerating thumbnails, as they need to reflect the content of the image file. First, Shotwell should never take this long to start, and should never hang the UI. I added this change some time back but didn't get a chance to performance test it, as we've been busy dealing with getting 0.7.1 and 0.7.2 out the door (among other fire drills). I suspect what's happening is that Unison is causing your entire library to appear changed to Shotwell, which then dutifully schedules all of them to be reimported. This is obviously undesirable. If Unison changes merely the file timestamp (i.e. it touched the file), this will trigger a reimport. I thought I'd taken this possibility into account; looking at the code, I missed this. My bad. I've ticketed this here: http://trac.yorba.org/ticket/2563 I'll try and get to this soon. -- Jim On Wed, Sep 15, 2010 at 4:18 AM, Peter DO Smith wrote: > My installation of Shotwell is suffering from slow start up again, but > under > very specific circumstances. > It took 34 minutes to start up. During this time Shotwell was greyed out > and > unresponsive. > CPU usage varied from 40% to 99% > > I downloaded and compiled the latest version from trunk yesterday morning. > I maintain two identical installations of my photo library in Ubuntu Linux > (10.04), one at Home and one in my Office. > The Shotwell data folder is kept in the Pictures folder (to make backup > simpler) and I invoke Shotwell as follows > shotwell -d /home/peter/Pictures/shotwell > > My Home installation is my primary installation where I load photos. > Then I use Unison to synchronise my Pictures folder to a USB drive. > The Pictures folder is then restored from the USB drive to my Office > machine, once again using Unison. > > This strategy has worked well until now. > Since yesterday, when I start up Shotwell on my Office machine after > restoring from my USB drive, I find that Shotwell is greyed out and > unresponsive for more than 30 minutes. > If I then close down Shotwell and restart it starts up quickly, as it did > before. > > I used Unison to see if the folders had changed. This showed me that > Shotwell had rebuilt 7904 thumbnails (both 128 and 360 bit) but that the > primary photos were still identical. I have 9668 photos in my library. Both > sets of folders are identical in every other respect, except, as expected, > the database had been updated > As far as I can tell Unison does does an excellent job maintaining > identical, synchronised folders. > > Why would Shotwell rebuild the thumbnails? (many but not all) > Could the rebuild process not run in a separate thread at lower priority to > avoid this extended unresponsive period? > > Thanks for including the No Events folder. That is a real life saver when I > am scanning film. > > Peter > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Sep 15 17:02:09 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 Sep 2010 10:02:09 -0700 Subject: [Shotwell] Slow start up In-Reply-To: References: Message-ID: It was a simple patch. If you pull from trunk, this should be fixed. However, I'm still concerned about the problem of reimporting a large number of files. That ticket is here: http://trac.yorba.org/ticket/2564 -- Jim On Wed, Sep 15, 2010 at 9:52 AM, Jim Nelson wrote: > We recently introduced in trunk a new feature for Shotwell: during the > startup scan, if it detects a change to the file, it's reimported (on the > assumption that it was edited or manipulated by an external program). This > is a feature request we've had for some time. The ticket for it is here: > http://trac.yorba.org/ticket/2476 > > Note that reimporting also means regenerating thumbnails, as they need to > reflect the content of the image file. > > First, Shotwell should never take this long to start, and should never hang > the UI. I added this change some time back but didn't get a chance to > performance test it, as we've been busy dealing with getting 0.7.1 and 0.7.2 > out the door (among other fire drills). > > I suspect what's happening is that Unison is causing your entire library to > appear changed to Shotwell, which then dutifully schedules all of them to be > reimported. This is obviously undesirable. > > If Unison changes merely the file timestamp (i.e. it touched the file), > this will trigger a reimport. I thought I'd taken this possibility into > account; looking at the code, I missed this. My bad. > > I've ticketed this here: http://trac.yorba.org/ticket/2563 > > I'll try and get to this soon. > > -- Jim > > > On Wed, Sep 15, 2010 at 4:18 AM, Peter DO Smith wrote: > >> My installation of Shotwell is suffering from slow start up again, but >> under >> very specific circumstances. >> It took 34 minutes to start up. During this time Shotwell was greyed out >> and >> unresponsive. >> CPU usage varied from 40% to 99% >> >> I downloaded and compiled the latest version from trunk yesterday morning. >> I maintain two identical installations of my photo library in Ubuntu Linux >> (10.04), one at Home and one in my Office. >> The Shotwell data folder is kept in the Pictures folder (to make backup >> simpler) and I invoke Shotwell as follows >> shotwell -d /home/peter/Pictures/shotwell >> >> My Home installation is my primary installation where I load photos. >> Then I use Unison to synchronise my Pictures folder to a USB drive. >> The Pictures folder is then restored from the USB drive to my Office >> machine, once again using Unison. >> >> This strategy has worked well until now. >> Since yesterday, when I start up Shotwell on my Office machine after >> restoring from my USB drive, I find that Shotwell is greyed out and >> unresponsive for more than 30 minutes. >> If I then close down Shotwell and restart it starts up quickly, as it did >> before. >> >> I used Unison to see if the folders had changed. This showed me that >> Shotwell had rebuilt 7904 thumbnails (both 128 and 360 bit) but that the >> primary photos were still identical. I have 9668 photos in my library. >> Both >> sets of folders are identical in every other respect, except, as expected, >> the database had been updated >> As far as I can tell Unison does does an excellent job maintaining >> identical, synchronised folders. >> >> Why would Shotwell rebuild the thumbnails? (many but not all) >> Could the rebuild process not run in a separate thread at lower priority >> to >> avoid this extended unresponsive period? >> >> Thanks for including the No Events folder. That is a real life saver when >> I >> am scanning film. >> >> Peter >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > From fvzwieten at gmail.com Wed Sep 15 17:58:35 2010 From: fvzwieten at gmail.com (Fred van Zwieten) Date: Wed, 15 Sep 2010 19:58:35 +0200 Subject: [Shotwell] Collage functionality Message-ID: Hi all, I'm not sure this is the right place for this, but I could find a better place for it. The only thing keeping me from converting my family PC from Windows to Ubuntu is Picasa (I know it runs in Wine, but I like native apps). My wife uses the collage feature of Picasa a lot. Shotwell is a really nice photo manager but it seems to be missing this particular functionality. It just so happens I want to get my hands dirty in development on Linux _and_ now I have an itch to scratch (collage functionality in Shotwell). So my questions are: 1. Is there already collage functionality underway? (can't find it in the feature enhancement requests) 2. If 1=no, is it OK if I take this on me? 3. If 2=yes, is it OK that it will take some time because I must get my hands dirty with vala and gobject. As for the design, i'm thinking along these lines: 1. Create a new collage from menu 2. As an alternative, select foto's and in the RMB menu you can create a new collage with the selected photo's. 3. A new window appears with the selected photo's (or empty when started from menu) 4. You can drag-n-drop photo's from ShotWell main interface into the collage window. 5. Within collage window ou have this functionality: 5a. Arrage photo's (layer management (move up/down, send up/down)) 5b. Rotate/grow/shrink 5c. Add nice borders to photo's 5d. Add tekst in typical scrapbook style to canvas 5e. Choose backgrounds (solif, photo, any grahpics file) 5f. Auto arrange photo's according to different scheme's. 6. One can save the collage as a new photo. Within Shotwell these collage photo's can be tagged or inserted into an event folder. Could be there is plugin functionality in the works. Then this would also fit in such a framework. Please let me know is it's OK to go forward with this (so I have something to do during the winter :-) ) I will then add this as an enhancement request. Thank you, Fred From B.Candler at pobox.com Wed Sep 15 18:56:00 2010 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 15 Sep 2010 19:56:00 +0100 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C90653A.4080802@nerd.fi> References: <4C80A4DA.4020305@nerd.fi> <4C812ACC.2020100@yorba.org> <1283610626.1783.22.camel@nuuk> <4C84A958.8060602@nerd.fi> <20100906192822.GA5731@talktalkplc.com> <4C8F569D.8060105@nerd.fi> <20100914182340.GA5816@talktalkplc.com> <4C90653A.4080802@nerd.fi> Message-ID: <20100915185600.GA5880@talktalkplc.com> On Wed, Sep 15, 2010 at 09:18:34AM +0300, Take wrote: > How about an a bit different approach. Use separate XMP-files and run > some small(ish) version control (ie. RCS) with them. Then one could > (possibly) sync metadata via that version control and diff-patch(-ish) > -procedure. Actual photos would sync as plain files, so rsync or > derivatives can take care of that. That would be perfect. > Separate metadata files however raise more questions, like how to index > them for faster search. Well, I heard talk of monitoring the library directory to notice new photos. The same could apply to new or modified XMP files (perhaps noting timestamps of files and their enclosing directories, to optimise detection of modifications). The modified files could be re-read into the database, which would just be an indexed cache. > With separate XMP files it might even be possible to migrate changes on > conflict situations. Yes, although to do it properly you need history (like RCS as you suggested, or a git repo). Regards, Brian. From jim at yorba.org Wed Sep 15 22:42:46 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 15 Sep 2010 15:42:46 -0700 Subject: [Shotwell] Collage functionality In-Reply-To: References: Message-ID: > I'm not sure this is the right place for this, but I could find a better > place for it. > > The mailing list is a good place for these kinds of discussion. > 1. Is there already collage functionality underway? (can't find it in the > feature enhancement requests) > No, but I've created a ticket for it: http://trac.yorba.org/ticket/2565 > 2. If 1=no, is it OK if I take this on me? > Absolutely! > 3. If 2=yes, is it OK that it will take some time because I must get my > hands dirty with vala and gobject. > That's no problem. If we bump up the priority of this feature, we'll let you know and ask if you want to share the work you've done to date with us. > > As for the design, i'm thinking along these lines: > > I think your list is a good start, but it's a lot of things to do at once. I would first suggest creating a simple implementation of a single collage type. For example, on the page I linked to in the ticket ( http://www.computorcompanion.com/LPMArticle.asp?ID=227) they have some fancy collages and a lot of options. The picture grid or contact sheet are much simpler. It would probably be best to start there. The Yorba philosophy is incremental improvements rather than large changes all dumped into trunk at once. Hence, we'd prefer to see something small and simple than all the features implemented in a single patch. > Could be there is plugin functionality in the works. Then this would also > fit in such a framework. > > We definitely want to adopt a plug-in scheme at some point. Until we've got our bearings on this, let's have this first pass at the feature be hardcoded in. -- Jim From fvzwieten at gmail.com Thu Sep 16 05:36:00 2010 From: fvzwieten at gmail.com (Fred van Zwieten) Date: Thu, 16 Sep 2010 07:36:00 +0200 Subject: [Shotwell] Collage functionality In-Reply-To: References: Message-ID: Hi Jim, Thank you for youre positive feedback. I agree with all of youre points. Of course I will follow open source philosophy to release early and release often. The design I wrote down is the point on the horizon. I will start with the relatively simple things. Thank you for creating the ticket. I will post further progress in this ticket. Fred On Thu, Sep 16, 2010 at 12:42 AM, Jim Nelson wrote: > > I'm not sure this is the right place for this, but I could find a better >> place for it. >> >> > The mailing list is a good place for these kinds of discussion. > > >> 1. Is there already collage functionality underway? (can't find it in the >> feature enhancement requests) >> > > No, but I've created a ticket for it: http://trac.yorba.org/ticket/2565 > > >> 2. If 1=no, is it OK if I take this on me? >> > > Absolutely! > > >> 3. If 2=yes, is it OK that it will take some time because I must get my >> hands dirty with vala and gobject. >> > > That's no problem. If we bump up the priority of this feature, we'll let > you know and ask if you want to share the work you've done to date with us. > > >> >> As for the design, i'm thinking along these lines: >> >> > I think your list is a good start, but it's a lot of things to do at once. > I would first suggest creating a simple implementation of a single collage > type. For example, on the page I linked to in the ticket ( > http://www.computorcompanion.com/LPMArticle.asp?ID=227) they have some > fancy collages and a lot of options. The picture grid or contact sheet are > much simpler. It would probably be best to start there. > > The Yorba philosophy is incremental improvements rather than large changes > all dumped into trunk at once. Hence, we'd prefer to see something small > and simple than all the features implemented in a single patch. > > >> Could be there is plugin functionality in the works. Then this would also >> fit in such a framework. >> >> > We definitely want to adopt a plug-in scheme at some point. Until we've > got our bearings on this, let's have this first pass at the feature be > hardcoded in. > > > -- Jim > From ktenney at gmail.com Sun Sep 19 15:46:58 2010 From: ktenney at gmail.com (Kent Tenney) Date: Sun, 19 Sep 2010 10:46:58 -0500 Subject: [Shotwell] Building trunk Message-ID: on Ubuntu 10.04. [ ktenney: /usr/fetching/shotwell ]$ ./configure Configured. Type 'make' to build, 'make install' to install. [ ktenney: /usr/fetching/shotwell ]$ make Package gee-1.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gee-1.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gee-1.0' found Package gexiv2 was not found in the pkg-config search path. Perhaps you should add the directory containing `gexiv2.pc' to the PKG_CONFIG_PATH environment variable No package 'gexiv2' found make: *** [src/.stamp] Error 1 The ppa binary knows about those libraries: [ ktenney: /usr/fetching/shotwell ]$ ldd `which shotwell` linux-vdso.so.1 => (0x00007fff3c188000) libgee.so.2 => /usr/lib/libgee.so.2 (0x00007ffdd3638000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007ffdd33ab000) libexiv2.so.6 => /usr/lib/libexiv2.so.6 (0x00007ffdd2fd9000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007ffdd2d9c000) libuuid.so.1 => /lib/libuuid.so.1 (0x00007ffdc50dc000) [ ktenney: /usr/fetching/shotwell ]$ How to proceed? Thanks, Kent From me at chrisfleming.org Sun Sep 19 16:05:50 2010 From: me at chrisfleming.org (Chris Fleming) Date: Sun, 19 Sep 2010 17:05:50 +0100 Subject: [Shotwell] Building trunk In-Reply-To: References: Message-ID: <4C9634DE.3080906@chrisfleming.org> I did this yesterday, but failed to keep notes of all the additional stuff I had to do in order to get things working. Try installing the libgee-dev and libexiv2-0-dev packages? Cheers Chris On 19/09/10 16:46, Kent Tenney wrote: > on Ubuntu 10.04. > > [ ktenney: /usr/fetching/shotwell ]$ ./configure > Configured. Type 'make' to build, 'make install' to install. > [ ktenney: /usr/fetching/shotwell ]$ make > Package gee-1.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `gee-1.0.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gee-1.0' found > Package gexiv2 was not found in the pkg-config search path. > Perhaps you should add the directory containing `gexiv2.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gexiv2' found > make: *** [src/.stamp] Error 1 > > The ppa binary knows about those libraries: > > [ ktenney: /usr/fetching/shotwell ]$ ldd `which shotwell` > linux-vdso.so.1 => (0x00007fff3c188000) > libgee.so.2 => /usr/lib/libgee.so.2 (0x00007ffdd3638000) > libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007ffdd33ab000) > libexiv2.so.6 => /usr/lib/libexiv2.so.6 (0x00007ffdd2fd9000) > libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007ffdd2d9c000) > > libuuid.so.1 => /lib/libuuid.so.1 (0x00007ffdc50dc000) > [ ktenney: /usr/fetching/shotwell ]$ > > How to proceed? > > Thanks, > Kent > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -- e: me at chrisfleming.org w: www.chrisfleming.org From rob at yorba.org Sun Sep 19 16:06:07 2010 From: rob at yorba.org (Rob Powell) Date: Sun, 19 Sep 2010 09:06:07 -0700 Subject: [Shotwell] Building trunk In-Reply-To: References: Message-ID: Hi Kent, You'll need to build gexiv2. You'll see that dependency on the shotwell install page. I think build instructions for gexiv2 are at trac.yorba.org/wiki/gexiv2. I'm currently out and about, so sorry if that link is wrong. If it is wrong, look for the link on the shotwell dependency section. The pc (package configuration) files are different than the so (shared library) Hope that helps Rob Sent from my iPhone On Sep 19, 2010, at 8:46 AM, Kent Tenney wrote: > on Ubuntu 10.04. > > [ ktenney: /usr/fetching/shotwell ]$ ./configure > Configured. Type 'make' to build, 'make install' to install. > [ ktenney: /usr/fetching/shotwell ]$ make > Package gee-1.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `gee-1.0.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gee-1.0' found > Package gexiv2 was not found in the pkg-config search path. > Perhaps you should add the directory containing `gexiv2.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gexiv2' found > make: *** [src/.stamp] Error 1 > > The ppa binary knows about those libraries: > > [ ktenney: /usr/fetching/shotwell ]$ ldd `which shotwell` > linux-vdso.so.1 => (0x00007fff3c188000) > libgee.so.2 => /usr/lib/libgee.so.2 (0x00007ffdd3638000) > libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007ffdd33ab000) > libexiv2.so.6 => /usr/lib/libexiv2.so.6 (0x00007ffdd2fd9000) > libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007ffdd2d9c000) > > libuuid.so.1 => /lib/libuuid.so.1 (0x00007ffdc50dc000) > [ ktenney: /usr/fetching/shotwell ]$ > > How to proceed? > > Thanks, > Kent > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From ktenney at gmail.com Sun Sep 19 16:23:54 2010 From: ktenney at gmail.com (Kent Tenney) Date: Sun, 19 Sep 2010 11:23:54 -0500 Subject: [Shotwell] Building trunk In-Reply-To: <4C9634DE.3080906@chrisfleming.org> References: <4C9634DE.3080906@chrisfleming.org> Message-ID: On Sun, Sep 19, 2010 at 11:05 AM, Chris Fleming wrote: > > I did this yesterday, but failed to keep notes of all the additional stuff I > had to do in order to get things working. > > Try installing the libgee-dev and libexiv2-0-dev packages? $ sudo aptitude install libgee-dev libgexiv2-dev $make off we go Thanks, Kent > > Cheers > Chris > > > > > > On 19/09/10 16:46, Kent Tenney wrote: >> >> on Ubuntu 10.04. >> >> [ ktenney: /usr/fetching/shotwell ]$ ./configure >> Configured. ?Type 'make' to build, 'make install' to install. >> [ ktenney: /usr/fetching/shotwell ]$ make >> Package gee-1.0 was not found in the pkg-config search path. >> Perhaps you should add the directory containing `gee-1.0.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'gee-1.0' found >> Package gexiv2 was not found in the pkg-config search path. >> Perhaps you should add the directory containing `gexiv2.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'gexiv2' found >> make: *** [src/.stamp] Error 1 >> >> The ppa binary knows about those libraries: >> >> [ ktenney: /usr/fetching/shotwell ]$ ldd `which shotwell` >> ? ? ? ?linux-vdso.so.1 => ? (0x00007fff3c188000) >> ? ? ? ?libgee.so.2 => ?/usr/lib/libgee.so.2 (0x00007ffdd3638000) >> ? ? ? ?libsqlite3.so.0 => ?/usr/lib/libsqlite3.so.0 (0x00007ffdd33ab000) >> ? ? ? ?libexiv2.so.6 => ?/usr/lib/libexiv2.so.6 (0x00007ffdd2fd9000) >> ? ? ? ?libgconf-2.so.4 => ?/usr/lib/libgconf-2.so.4 (0x00007ffdd2d9c000) >> ? ? >> ? ? ? ?libuuid.so.1 => ?/lib/libuuid.so.1 (0x00007ffdc50dc000) >> [ ktenney: /usr/fetching/shotwell ]$ >> >> How to proceed? >> >> Thanks, >> Kent >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > -- > e: me at chrisfleming.org > w: www.chrisfleming.org > > From ktenney at gmail.com Mon Sep 20 13:58:58 2010 From: ktenney at gmail.com (Kent Tenney) Date: Mon, 20 Sep 2010 08:58:58 -0500 Subject: [Shotwell] Shotwell questions Message-ID: Howdy, I've been looking for a home for my image collection. I have metadata in a .csv exported from a app I used a few years ago, I will need to populate the new db with info on ~60,000 files from the .csv Looking at photo.db, I was surprised that each tag listed the photos, I would expect each photo to list it's tags. Does this scale well? Is it expected that the photo_id_list column will contain tens of thousands of entries? Thanks, Kent From me at chrisfleming.org Mon Sep 20 15:30:53 2010 From: me at chrisfleming.org (Chris Fleming) Date: Mon, 20 Sep 2010 16:30:53 +0100 Subject: [Shotwell] Shotwell questions In-Reply-To: References: Message-ID: <4C977E2D.3030903@chrisfleming.org> On 20/09/10 14:58, Kent Tenney wrote: > Howdy, > > I've been looking for a home for my image collection. > > I have metadata in a .csv exported from a app I used a few > years ago, I will need to populate the new db with info on > ~60,000 files from the .csv > > Looking at photo.db, I was surprised that each tag listed the > photos, I would expect each photo to list it's tags. > > Does this scale well? > Is it expected that the photo_id_list column will contain > tens of thousands of entries? The way they have implemented this does make sense to me. I guess that you will be wanting to regularly search by tags. By organising each tag to have the associated list of photo id's this will be much quicker than having to go through each photo and find out if it matches your tag. My current dataset is 29 000 photos, I'm currently running into trouble importing it (bug report on the way once I get something tangible to report), but am looking forward to seeing how it performs especially compared to f-spot which I'm finding very slugish. Cheers Chris From ktenney at gmail.com Wed Sep 22 19:32:25 2010 From: ktenney at gmail.com (Kent Tenney) Date: Wed, 22 Sep 2010 14:32:25 -0500 Subject: [Shotwell] Where is the "Library?" Message-ID: Howdy, When I do File -> Import from Folder I get the choice: "Shotwell can copy the photos into your library or it can link to the photos without duplicating them." Where is the Library which contains links or copies? Thanks, Kent From adam at yorba.org Wed Sep 22 19:39:01 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 22 Sep 2010 12:39:01 -0700 Subject: [Shotwell] Where is the "Library?" In-Reply-To: References: Message-ID: <4C9A5B55.3060308@yorba.org> Kent, the library is the directory you set in the Edit->Preferences dialog as "Import photos to:". By default it's the XDG_PICTURES_DIR directory, which is probably ~/Pictures on your machine. For more information, see the Importing Photos section in the Shotwell user guide: http://trac.yorba.org/wiki/UsingShotwell0.7 adam On 09/22/2010 12:32 PM, Kent Tenney wrote: > Howdy, > > When I do File -> Import from Folder > > I get the choice: > "Shotwell can copy the photos into your library or it > can link to the photos without duplicating them." > > Where is the Library which contains links or copies? > > Thanks, > Kent > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From ktenney at gmail.com Wed Sep 22 19:54:04 2010 From: ktenney at gmail.com (Kent Tenney) Date: Wed, 22 Sep 2010 14:54:04 -0500 Subject: [Shotwell] Where is the "Library?" In-Reply-To: <4C9A5B55.3060308@yorba.org> References: <4C9A5B55.3060308@yorba.org> Message-ID: On Wed, Sep 22, 2010 at 2:39 PM, Adam Dingle wrote: > ?Kent, > > the library is the directory you set in the Edit->Preferences dialog as > "Import photos to:". ?By default it's the XDG_PICTURES_DIR directory, which > is probably ~/Pictures on your machine. Ah, ok. I expected "can link to" to create links, but if "copy" is not chosen, no files are created in the Library ... ?For more information, see the > Importing Photos section in the Shotwell user guide: > > http://trac.yorba.org/wiki/UsingShotwell0.7 > > adam > > On 09/22/2010 12:32 PM, Kent Tenney wrote: >> >> Howdy, >> >> When I do File -> ?Import from Folder >> >> I get the choice: >> "Shotwell can copy the photos into your library or it >> can link to the photos without duplicating them." >> >> Where is the Library which contains links or copies? >> >> Thanks, >> Kent >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From adam at yorba.org Wed Sep 22 19:57:18 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 22 Sep 2010 12:57:18 -0700 Subject: [Shotwell] Where is the "Library?" In-Reply-To: References: <4C9A5B55.3060308@yorba.org> Message-ID: <4C9A5F9E.2070207@yorba.org> Kent, On 09/22/2010 12:54 PM, Kent Tenney wrote: > On Wed, Sep 22, 2010 at 2:39 PM, Adam Dingle wrote: >> Kent, >> >> the library is the directory you set in the Edit->Preferences dialog as >> "Import photos to:". By default it's the XDG_PICTURES_DIR directory, which >> is probably ~/Pictures on your machine. > Ah, ok. > > I expected "can link to" to create links, but > if "copy" is not chosen, no files are created in the Library ... Aha - do you mean you expected Shotwell to create symbolic links to your photos? It doesn't do that - if you choose "Create Links" then Shotwell merely uses the photos in place without copying. Yes, we know this terminology is confusing, and we have a ticket open to address this: http://trac.yorba.org/ticket/2489 adam From ktenney at gmail.com Wed Sep 22 20:02:13 2010 From: ktenney at gmail.com (Kent Tenney) Date: Wed, 22 Sep 2010 15:02:13 -0500 Subject: [Shotwell] Where is the "Library?" In-Reply-To: <4C9A5F9E.2070207@yorba.org> References: <4C9A5B55.3060308@yorba.org> <4C9A5F9E.2070207@yorba.org> Message-ID: On Wed, Sep 22, 2010 at 2:57 PM, Adam Dingle wrote: > ?Kent, > > On 09/22/2010 12:54 PM, Kent Tenney wrote: >> >> On Wed, Sep 22, 2010 at 2:39 PM, Adam Dingle ?wrote: >>> >>> ?Kent, >>> >>> the library is the directory you set in the Edit->Preferences dialog as >>> "Import photos to:". ?By default it's the XDG_PICTURES_DIR directory, >>> which >>> is probably ~/Pictures on your machine. >> >> Ah, ok. >> >> I expected "can link to" to create links, but >> if "copy" is not chosen, no files are created in the Library ... > > Aha - do you mean you expected Shotwell to create symbolic links to your > photos? Right. I was kind of hoping for the symlinks, seems like that might be useful, though I can't think why just now. :-] ?It doesn't do that - if you choose "Create Links" then Shotwell > merely uses the photos in place without copying. ?Yes, we know this > terminology is confusing, and we have a ticket open to address this: > > http://trac.yorba.org/ticket/2489 > > adam > > From ktenney at gmail.com Thu Sep 23 21:08:58 2010 From: ktenney at gmail.com (Kent Tenney) Date: Thu, 23 Sep 2010 16:08:58 -0500 Subject: [Shotwell] Importing Message-ID: I'm trying to figure out Shotwell's world view. If I choose "copy" when importing, the path of the original is lost and replaced with a path based on date. I won't be copying, the path structure has meaning and I don't want it discarded. If Shotwell detects a duplicate file it is ignored. I can see this makes sense if copying, not so much if linking. I would prefer if Shotwell didn't have an opinion on what files to ignore, and photo.db represented an accurate representation of my collection. Some of my duplicates are mistakes and I'd like Shotwell to help me weed, other dupes are for a reason. Does this sound reasonable? Thanks, Kent From contact at webfarmer.ch Sun Sep 26 07:25:45 2010 From: contact at webfarmer.ch (Aram Loosman) Date: Sun, 26 Sep 2010 09:25:45 +0200 Subject: [Shotwell] Phototray for event-spanning photo selection Message-ID: <1285485945.3822.33.camel@steppinrazor> Usecase: I use Shotwell for all the photos from our family. From time to time i want to send some of these images to relatives or print them out. It is however difficult to achieve this, when the photos are not in the same event. I've got to search through the events and export the selected photos from the event separate. What I can do alternatively is to create a temporary tag to select all the photos I want and export them afterwards all together. I find this solution however too complicated. Picasa has the possibility to "hold" any photo in a photo tray to perform actions like export / send by mail etc. I think this approach is basically the same as the one with the tag, but it would be much easier to use. If you're interested I could also draw/design a mockup how the feature could be integrated into Shotwell. (To be honest, I really need this feature because I want to force my wife to use Shotwell ;) and I cannot do this if it is not as "easy" as Picasa, which she currently uses) Hope you like the idea :) Aram From pdo.smith at gmail.com Mon Sep 27 07:14:58 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 27 Sep 2010 09:14:58 +0200 Subject: [Shotwell] Slow start up In-Reply-To: References: Message-ID: Thanks Jim, the patch worked nicely. Sorry about the long delay in replying. On Wed, Sep 15, 2010 at 7:02 PM, Jim Nelson wrote: > It was a simple patch. If you pull from trunk, this should be fixed. > > However, I'm still concerned about the problem of reimporting a large > number of files. That ticket is here: http://trac.yorba.org/ticket/2564 > > -- Jim > > > On Wed, Sep 15, 2010 at 9:52 AM, Jim Nelson wrote: > >> We recently introduced in trunk a new feature for Shotwell: during the >> startup scan, if it detects a change to the file, it's reimported (on the >> assumption that it was edited or manipulated by an external program). This >> is a feature request we've had for some time. The ticket for it is here: >> http://trac.yorba.org/ticket/2476 >> >> Note that reimporting also means regenerating thumbnails, as they need to >> reflect the content of the image file. >> >> First, Shotwell should never take this long to start, and should never >> hang the UI. I added this change some time back but didn't get a chance to >> performance test it, as we've been busy dealing with getting 0.7.1 and 0.7.2 >> out the door (among other fire drills). >> >> I suspect what's happening is that Unison is causing your entire library >> to appear changed to Shotwell, which then dutifully schedules all of them to >> be reimported. This is obviously undesirable. >> >> If Unison changes merely the file timestamp (i.e. it touched the file), >> this will trigger a reimport. I thought I'd taken this possibility into >> account; looking at the code, I missed this. My bad. >> >> I've ticketed this here: http://trac.yorba.org/ticket/2563 >> >> I'll try and get to this soon. >> >> -- Jim >> >> >> On Wed, Sep 15, 2010 at 4:18 AM, Peter DO Smith wrote: >> >>> My installation of Shotwell is suffering from slow start up again, but >>> under >>> very specific circumstances. >>> It took 34 minutes to start up. During this time Shotwell was greyed out >>> and >>> unresponsive. >>> CPU usage varied from 40% to 99% >>> >>> I downloaded and compiled the latest version from trunk yesterday >>> morning. >>> I maintain two identical installations of my photo library in Ubuntu >>> Linux >>> (10.04), one at Home and one in my Office. >>> The Shotwell data folder is kept in the Pictures folder (to make backup >>> simpler) and I invoke Shotwell as follows >>> shotwell -d /home/peter/Pictures/shotwell >>> >>> My Home installation is my primary installation where I load photos. >>> Then I use Unison to synchronise my Pictures folder to a USB drive. >>> The Pictures folder is then restored from the USB drive to my Office >>> machine, once again using Unison. >>> >>> This strategy has worked well until now. >>> Since yesterday, when I start up Shotwell on my Office machine after >>> restoring from my USB drive, I find that Shotwell is greyed out and >>> unresponsive for more than 30 minutes. >>> If I then close down Shotwell and restart it starts up quickly, as it did >>> before. >>> >>> I used Unison to see if the folders had changed. This showed me that >>> Shotwell had rebuilt 7904 thumbnails (both 128 and 360 bit) but that the >>> primary photos were still identical. I have 9668 photos in my library. >>> Both >>> sets of folders are identical in every other respect, except, as >>> expected, >>> the database had been updated >>> As far as I can tell Unison does does an excellent job maintaining >>> identical, synchronised folders. >>> >>> Why would Shotwell rebuild the thumbnails? (many but not all) >>> Could the rebuild process not run in a separate thread at lower priority >>> to >>> avoid this extended unresponsive period? >>> >>> Thanks for including the No Events folder. That is a real life saver when >>> I >>> am scanning film. >>> >>> Peter >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> >> > From take at nerd.fi Mon Sep 27 08:04:56 2010 From: take at nerd.fi (Take) Date: Mon, 27 Sep 2010 11:04:56 +0300 Subject: [Shotwell] Shotwell removed some photos Message-ID: <4CA05028.7080304@nerd.fi> Hello I ran into an behaviour, which is really unacceptable. The setup is that I have shotwell storage on NFS-mount (to access files from various computers), /media/Photo. I have an symlink ~/.shotwell -> /media/Photo/.shotwell (on every machine, including workstation which acts as an NFS-server) First, there is an speed issue with shotwell when used like this from remote machine, but that's a whole another matter and not actually the problem at hand. I imported ~100 photos from laptop to shotwell (which access data over WLAN-link and NFS) and, here's the strange part: I started shotwell on my workstation and saw those pictures for a while, but then "something" happened and those photos disappeared. Perhaps shotwell did some kind of reindex/whatever, I don't know. Anyways, the result is, that those photos are missing. There's no files whatsoever on /media/Photo/2010/08. On the laptop, even if the import process took ages, shotwell responded "~100 photos imported succesfully, nn duplicates not imported" (can't remember exact words, but you get the idea). Is this some kind of feature, that shotwell removes actual files if they're not in database or what? In any ways, this kind of automated removal of files is quite dangerous and I'd like to know what happened in the first place and how to prevent that from happening again. -- Take From take at nerd.fi Mon Sep 27 08:49:41 2010 From: take at nerd.fi (Take) Date: Mon, 27 Sep 2010 11:49:41 +0300 Subject: [Shotwell] Shotwell removed some photos In-Reply-To: <4CA05028.7080304@nerd.fi> References: <4CA05028.7080304@nerd.fi> Message-ID: <4CA05AA5.7070801@nerd.fi> On 09/27/2010 11:04 AM, Take wrote: > Is this some kind of feature, that shotwell removes actual files if > they're not in database or what? In any ways, this kind of automated Some additional details: - shotwell is 0.7.2-1~lucid1 - NFS-mount has all_squash -option set to prevent problems with different UIDs/GIDs and permission problems via that And, when I browsed trough the "Missing files" I can see the thumbnails there, but the files itself are missing. AFAIK NFS itself shouldn't cause missing files like this. However this kind of explains why thoses pictures were visible for a while on workstation, since they were moved to missing files. Unfortunately I've already formatted the SD-card, photorec found most of the pictures, but few are still missing and I can't locate them anywhere. -- Take From take at nerd.fi Mon Sep 27 15:40:09 2010 From: take at nerd.fi (Take) Date: Mon, 27 Sep 2010 18:40:09 +0300 Subject: [Shotwell] Enhancements to tags Message-ID: I added a lots of tags to my photos, which raised few improvements I'd like to see in shotwell. 1) Select multiple tags I added tags to photos about who's on the photo and where they're taken. It'd be great if I could select multiple tags, so that I could ie. show up images which are taken at home and which include myself. This way it'd be simpler and faster to browse trough spesific photos on the collection. 2) Grouping of tags With tags "who" and "where" there'll be a lots of tags on the collection. It would be great if those could be grouped, so that I could have branches under tags, like "Locations" and "People". 3) Remove tag from multiple photos Couple of times I accidently added an tag to lots of pictures which was incorrect. I had to go trough them individually and remove that tag from each photo. 4) Drag tags to photos When browsing trough photos and tagging them it'd be great if I could drag tag to photos from sidebar. I know I can do this by dragging photos to tags, but it'd be IMO more usable if I could also drag tags to photos. I didn't create tickets about these just yet, since some feedback would be nice before doing that. -- Take From andrew-lists at odaeus.co.uk Mon Sep 27 15:59:53 2010 From: andrew-lists at odaeus.co.uk (Andrew France) Date: Mon, 27 Sep 2010 16:59:53 +0100 Subject: [Shotwell] IDE and Flickr feature Message-ID: <4CA0BF79.7000401@odaeus.co.uk> Hi, I discovered Shotwell in the Ubuntu 10.10 beta and it's exactly what I've been looking for to manage the various streams my photos go to, thank you! I usually upload my Flickr photos at a larger size so I got the source (SVN?! I've mirrored it on Github at http://github.com/Odaeus/shotwell) and started adding a custom option on the drop-down list along with a text-box to enter the dimension. This is the first time I've used the Vala language (it's quite nice), I've been using Vim, but is there another IDE you primarily use for development? Sorry if this has been asked before but I couldn't find the mailing list search? I got to the point where it works at a basic level for my big Flickr uploads but any feedback on best practice for how the custom-size feature should be implemented would be great. I assume it's a desirable feature! Making the Export Dialog code/interface reusable would be nice but I think it's beyond me. Regards, Andrew France From caccolangrifata at gmail.com Mon Sep 27 16:00:31 2010 From: caccolangrifata at gmail.com (caccolangrifata) Date: Mon, 27 Sep 2010 18:00:31 +0200 Subject: [Shotwell] Enhancements to tags In-Reply-To: References: Message-ID: <1285603231.2684.13.camel@mind> Il giorno lun, 27/09/2010 alle 18.40 +0300, Take ha scritto: > I added a lots of tags to my photos, which raised few improvements I'd > like to see in shotwell. > > 1) Select multiple tags > I added tags to photos about who's on the photo and where they're taken. > It'd be great if I could select multiple tags, so that I could ie. show up > images which are taken at home and which include myself. This way it'd be > simpler and faster to browse trough spesific photos on the collection. +1 > > 2) Grouping of tags > With tags "who" and "where" there'll be a lots of tags on the collection. > It would be great if those could be grouped, so that I could have branches > under tags, like "Locations" and "People". http://trac.yorba.org/ticket/1401 ? > > 3) Remove tag from multiple photos > Couple of times I accidently added an tag to lots of pictures which was > incorrect. I had to go trough them individually and remove that tag from > each photo. I think adding "undo" for every action in Shotwell will resolve this kind of problem but I think it's already implemented. > > 4) Drag tags to photos > When browsing trough photos and tagging them it'd be great if I could drag > tag to photos from sidebar. I know I can do this by dragging photos to > tags, but it'd be IMO more usable if I could also drag tags to photos. Maybe is more intuitive and productive drag photo on tag for some reason: 1. tagging multiple photo at once 2. ... ehm memory lapse ?_? 3. suggest? > > > I didn't create tickets about these just yet, since some feedback would be > nice before doing that. > This is my feedback ;D Cheers! -- Emanuele Grande OpenPGP key: 1024D/BF9328A7 | j.mp/cJTR3C 9F22 91FE F054 185D 3376 910E 62B3 85D6 BF93 28A7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From pdo.smith at gmail.com Mon Sep 27 16:10:23 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 27 Sep 2010 18:10:23 +0200 Subject: [Shotwell] IDE and Flickr feature In-Reply-To: <4CA0BF79.7000401@odaeus.co.uk> References: <4CA0BF79.7000401@odaeus.co.uk> Message-ID: The Valencia add on for gedit works very nicely http://yorba.org/valencia/ On Mon, Sep 27, 2010 at 5:59 PM, Andrew France wrote: > Hi, > > I discovered Shotwell in the Ubuntu 10.10 beta and it's exactly what > I've been looking for to manage the various streams my photos go to, > thank you! > > I usually upload my Flickr photos at a larger size so I got the source > (SVN?! I've mirrored it on Github at http://github.com/Odaeus/shotwell) > and started adding a custom option on the drop-down list along with a > text-box to enter the dimension. > > This is the first time I've used the Vala language (it's quite nice), > I've been using Vim, but is there another IDE you primarily use for > development? Sorry if this has been asked before but I couldn't find the > mailing list search? > > I got to the point where it works at a basic level for my big Flickr > uploads but any feedback on best practice for how the custom-size > feature should be implemented would be great. I assume it's a desirable > feature! Making the Export Dialog code/interface reusable would be nice > but I think it's beyond me. > > Regards, > Andrew France > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Mon Sep 27 16:42:13 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 27 Sep 2010 09:42:13 -0700 Subject: [Shotwell] IDE and Flickr feature In-Reply-To: <4CA0BF79.7000401@odaeus.co.uk> References: <4CA0BF79.7000401@odaeus.co.uk> Message-ID: <4CA0C965.9000107@yorba.org> Andrew, On 09/27/2010 08:59 AM, Andrew France wrote: > Hi, > > I discovered Shotwell in the Ubuntu 10.10 beta and it's exactly what > I've been looking for to manage the various streams my photos go to, > thank you! I'm glad you like Shotwell! > I usually upload my Flickr photos at a larger size so I got the source > (SVN?! I've mirrored it on Github at http://github.com/Odaeus/shotwell) > and started adding a custom option on the drop-down list along with a > text-box to enter the dimension. > > This is the first time I've used the Vala language (it's quite nice), > I've been using Vim, but is there another IDE you primarily use for > development? Sorry if this has been asked before but I couldn't find the > mailing list search? Here at Yorba we also wanted a Vala IDE, so we wrote Valencia, a plugin that turns gedit into an IDE for Vala. This is what we use for our own Shotwell development. Check it out: http://yorba.org/valencia/ Unfortunately our mailing lists are not yet searchable - we hope to fix this at some point (see http://trac.yorba.org/ticket/2181 ). As a workaround, you can search all the lists at once using Google by including the term 'site:lists.yorba.org'. > I got to the point where it works at a basic level for my big Flickr > uploads but any feedback on best practice for how the custom-size > feature should be implemented would be great. I assume it's a desirable > feature! Making the Export Dialog code/interface reusable would be nice > but I think it's beyond me. Yes, I think this is a reasonable idea. I might suggest having two text boxes (one for width, one for height) that are normally hidden, but appear when the user chooses the custom size option in the dropdown. This would work just like Shotwell's crop tool, which also offers a predefined list of dimensions but lets you enter custom dimensions as well. cheers adam From adam at yorba.org Mon Sep 27 16:53:01 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 27 Sep 2010 09:53:01 -0700 Subject: [Shotwell] Enhancements to tags In-Reply-To: References: Message-ID: <4CA0CBED.2000903@yorba.org> Take, thanks for your tagging suggestions. On 09/27/2010 08:40 AM, Take wrote: > I added a lots of tags to my photos, which raised few improvements I'd > like to see in shotwell. > > 1) Select multiple tags > I added tags to photos about who's on the photo and where they're taken. > It'd be great if I could select multiple tags, so that I could ie. show up > images which are taken at home and which include myself. This way it'd be > simpler and faster to browse trough spesific photos on the collection. Yes - this is a frequently requested feature: http://trac.yorba.org/ticket/2275 > 2) Grouping of tags > With tags "who" and "where" there'll be a lots of tags on the collection. > It would be great if those could be grouped, so that I could have branches > under tags, like "Locations" and "People". > Right. Lots of users want this as well: http://trac.yorba.org/ticket/1401 > 3) Remove tag from multiple photos > Couple of times I accidently added an tag to lots of pictures which was > incorrect. I had to go trough them individually and remove that tag from > each photo. There's no need to remove these individually - you can remove them all at once. See the Tags section in the Shotwell user guide (http://trac.yorba.org/wiki/UsingShotwell0.7#Tags): 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 choose Tags ? Remove Tag "[name]" from Photos... > 4) Drag tags to photos > When browsing trough photos and tagging them it'd be great if I could drag > tag to photos from sidebar. I know I can do this by dragging photos to > tags, but it'd be IMO more usable if I could also drag tags to photos. Seems like a reasonable idea. I've added a ticket at http://trac.yorba.org/ticket/2601 adam From simonspa at kth.se Mon Sep 27 17:05:53 2010 From: simonspa at kth.se (Simon Spannagel) Date: Mon, 27 Sep 2010 19:05:53 +0200 Subject: [Shotwell] some papercuts Message-ID: <4CA0CEF1.8050508@kth.se> Hej, after using Shotwell very intensively in the last days, I put together a small list of "papercuts", which annoyed me a lot after a while. Further I have some suggestions, some of them might have been already discussed... Du you want me to open tickets for all these papercuts? :-) I wanted to wait for a possible discussion... * After deleting/renaming an event/tag, the sidebar jumps to the beginning and you have to scroll down again. * it is impossible to mark mutliple pictures with "ctrl"+"arrow keys" and "space" like in the most common file managers. * the tags are shown nowhere in the single-picture-view. * Sometimes there is an issue with scrolling - unfortunately I can't really say in which situations you can reproduce that behaviour - but it is very annoying. If you marked a picture and then scroll down, sometimes it just jumps back to the marked picture or a bit below. * on adding tags to a picture, the suggestion of existing tags doesn't work for non-standard characters like "?" * shotwell sometimes freezes without any reason for about 30sec, after that normal work is possible. Some as above: I have no idea how to reproduce that. Suggestions how I could see what is happening in this moment? * Maybe generating bigger thumbnails for the "event-picture", the resolution seems to be not enough, in some of the event pictures I can see pixels. * Deleting pictures out of the trash seems not to work on NTFS-partitons, only the trash is emptied, so the user assumes, that the files are gone - but they are still stored in their original place. Suggestions: * After now using more than a hundred different tags for now 5500 imported pictures it's getting really crowded in the sidebar. So I suggest to put up some categories for tags, just easy ones like "persons", "places" and so on. But we had that already, as I see in this moment...) * It is impossible to adjust, which EXIF-data is shown in the lower left corner. This could be an option, so no "easy user" will be disturbed but still the "power user" has the posibility... * An option for showing only photos with a special rating (for "rejected" as an example...) or even "** or below". In some cases this might be very useful... Greetings, Simon From jim at yorba.org Mon Sep 27 18:41:57 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 27 Sep 2010 11:41:57 -0700 Subject: [Shotwell] Phototray for event-spanning photo selection In-Reply-To: <1285485945.3822.33.camel@steppinrazor> References: <1285485945.3822.33.camel@steppinrazor> Message-ID: This seems like a good idea and one useful to certain workflows. I've ticketed it here: http://trac.yorba.org/ticket/2604 If you'd like to add mockups or ideas to the ticket, please do! Thanks, -- Jim On Sun, Sep 26, 2010 at 12:25 AM, Aram Loosman wrote: > Usecase: I use Shotwell for all the photos from our family. From time to > time i want to send some of these images to relatives or print them out. > It is however difficult to achieve this, when the photos are not in the > same event. I've got to search through the events and export the > selected photos from the event separate. > > What I can do alternatively is to create a temporary tag to select all > the photos I want and export them afterwards all together. > I find this solution however too complicated. > > Picasa has the possibility to "hold" any photo in a photo tray to > perform actions like export / send by mail etc. > I think this approach is basically the same as the one with the tag, but > it would be much easier to use. > > If you're interested I could also draw/design a mockup how the feature > could be integrated into Shotwell. > > (To be honest, I really need this feature because I want to force my > wife to use Shotwell ;) and I cannot do this if it is not as "easy" as > Picasa, which she currently uses) > > Hope you like the idea :) > Aram > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Mon Sep 27 19:03:42 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 27 Sep 2010 12:03:42 -0700 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: Hi Kent, Importing has some caveats, as you're noticing. On Thu, Sep 23, 2010 at 2:08 PM, Kent Tenney wrote: > I'm trying to figure out Shotwell's world view. > > If I choose "copy" when importing, the path of the original is > lost and replaced with a path based on date. > It's not really lost, it's just that it's exactly what it sounds like: Shotwell makes a copy of the file in your XDG Pictures directory (probably ~/Pictures) and imports that into its library. > > I won't be copying, the path structure has meaning and I > don't want it discarded. > > Then you want to link rather than copy. > If Shotwell detects a duplicate file it is ignored. > > That's correct. > I can see this makes sense if copying, not so much if linking. > > It depends; I think what you're suggesting is that duplicate detection should only be used to prevent a file copy. There are other import scenarios, particularly importing from a camera or an SD card. > I would prefer if Shotwell didn't have an opinion on what files to > ignore, and photo.db represented an accurate representation > of my collection. Some of my duplicates are mistakes and I'd > like Shotwell to help me weed, other dupes are for a reason. > > Does this sound reasonable? > It does, but I think I'd like to get a clearer picture of when Shotwell should use duplicate detection and when it shouldn't (in your view, at least), and how it's presented to the user. For example, how would Shotwell help you weed them out (beyond just showing you the same photo twice or more in your collection). -- Jim From jim at yorba.org Mon Sep 27 19:14:52 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 27 Sep 2010 12:14:52 -0700 Subject: [Shotwell] Shotwell removed some photos In-Reply-To: <4CA05AA5.7070801@nerd.fi> References: <4CA05028.7080304@nerd.fi> <4CA05AA5.7070801@nerd.fi> Message-ID: Hi Take, First, Shotwell will never delete a master/original file without the user's consent. Even then, Shotwell will move the master to the desktop trash can. I do have one concern here; I'm not sure what the GVFS call to "trash" a file does on an NFS-mounted system. The documentation suggests it will fail (i.e. not delete the file) if the filesystem doesn't support trashing. Still, Shotwell won't do this without asking the user first. So, unless there's some other step here, I don't believe Shotwell has deleted the file. If you're seeing those files in the "Missing Files" folder, than means that during Shotwell's startup scan it detected that the master file for those photos was inaccessible. (That's probably what you saw when they "disappeared"; the scan happens in the background, and can take a moment, especially over the wire.) If you turn on View -> Extended Information you can see the full path that Shotwell expects those photos to be at. If they're not available via Nautilus, then Shotwell can't see them either. Note that if you (or an underlying transport layer) re-establishes connection to your server, you'll need to close and restart Shotwell to get it to recognize those files and put them back in the main library. Another concern I have from your setup is that you you have the .shotwell directory on your server. Are you sharing that directory with multiple instances of Shotwell? That could be a big problem, especially if those multiple instances are running at the same time. The Shotwell private directory wasn't designed for this kind of usage. -- Jim On Mon, Sep 27, 2010 at 1:49 AM, Take wrote: > On 09/27/2010 11:04 AM, Take wrote: > > Is this some kind of feature, that shotwell removes actual files if > > they're not in database or what? In any ways, this kind of automated > > Some additional details: > - shotwell is 0.7.2-1~lucid1 > - NFS-mount has all_squash -option set to prevent problems with > different UIDs/GIDs and permission problems via that > > And, when I browsed trough the "Missing files" I can see the thumbnails > there, but the files itself are missing. AFAIK NFS itself shouldn't > cause missing files like this. However this kind of explains why thoses > pictures were visible for a while on workstation, since they were moved > to missing files. > > Unfortunately I've already formatted the SD-card, photorec found most of > the pictures, but few are still missing and I can't locate them anywhere. > > -- > Take > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From ktenney at gmail.com Mon Sep 27 20:32:14 2010 From: ktenney at gmail.com (Kent Tenney) Date: Mon, 27 Sep 2010 15:32:14 -0500 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: On Mon, Sep 27, 2010 at 2:03 PM, Jim Nelson wrote: > Hi Kent, > > Importing has some caveats, as you're noticing. > > On Thu, Sep 23, 2010 at 2:08 PM, Kent Tenney wrote: >> >> I'm trying to figure out Shotwell's world view. >> >> If I choose "copy" when importing, the path of the original is >> lost and replaced with a path based on date. > > It's not really lost, it's just that it's exactly what it sounds like: > Shotwell makes a copy of the file in your XDG Pictures directory (probably > ~/Pictures) and imports that into its library. Right, but the _path_ of the original seems lost, the files location in the hfs. > >> >> I won't be copying, the path structure has meaning and I >> don't want it discarded. >> > > Then you want to link rather than copy. > >> >> If Shotwell detects a duplicate file it is ignored. >> > > That's correct. > >> >> I can see this makes sense if copying, not so much if linking. >> > > It depends; I think what you're suggesting is that duplicate detection > should only be used to prevent a file copy.? There are other import > scenarios, particularly importing from a camera or an SD card. Right, my wife's collection is a nightmare of duplication, however her workflow would prefer copying, and dupe ignoring would be great. > >> >> I would prefer if Shotwell didn't have an opinion on what files to >> ignore, and photo.db represented an accurate representation >> of my collection. Some of my duplicates are mistakes and I'd >> like Shotwell to help me weed, other dupes are for a reason. >> >> Does this sound reasonable? > > It does, but I think I'd like to get a clearer picture of when Shotwell > should use duplicate detection and when it shouldn't I'd rephrase "dupe detection" to "ignore dupes" I guess it would consist of a preference: ignore duplicates when linking: yes/no I would choose "no" I have dupes in my collection which are not mistakes, they are the same file, but live in different contexts. (in your view, at > least), and how it's presented to the user.? For example, how would Shotwell > help you weed them out (beyond just showing you the same photo twice or more > in your collection). If I was looking at one of the collection views which included a file which existed in multiple locations, I might expect to see: - multiple stars under the thumb, one for each copy found - a link which would bring up a listbox with absolute filenames - some distinguishing feature, maybe just a different border color If dupes were allowed, a view named "Duplicates" would show thumbs of all files which live in more than one directory. I am very interested in Shotwell's photo.db file. My plan is to scratch some of my particular itches with Python, drawing on the data in photo.db, so I want it to accurately reflect my directory structure. Thanks, Kent > > -- Jim > From iluetkeb at techfak.uni-bielefeld.de Tue Sep 28 09:33:56 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Tue, 28 Sep 2010 11:33:56 +0200 Subject: [Shotwell] Shotwell removed some photos In-Reply-To: References: <4CA05028.7080304@nerd.fi> <4CA05AA5.7070801@nerd.fi> Message-ID: <4CA1B684.5000909@techfak.uni-bielefeld.de> Am 27.09.2010 21:14, schrieb Jim Nelson: > can. I do have one concern here; I'm not sure what the GVFS call to "trash" > a file does on an NFS-mounted system. It works fine, and puts items in a trash directory -- to GVFS, NFS looks like any other file-system. I've been running Shotwell on photos in an NFS dir for quite a while now, without any problems. Ingo From adam at yorba.org Tue Sep 28 17:09:35 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 28 Sep 2010 10:09:35 -0700 Subject: [Shotwell] some papercuts In-Reply-To: <4CA0CEF1.8050508@kth.se> References: <4CA0CEF1.8050508@kth.se> Message-ID: <4CA2214F.6060604@yorba.org> Simon, On 09/27/2010 10:05 AM, Simon Spannagel wrote: > Hej, > > after using Shotwell very intensively in the last days, I put together a > small list of "papercuts", which annoyed me a lot after a while. Further > I have some suggestions, some of them might have been already discussed... Thanks for your suggestions. We're also interested in fixing paper cuts since we want Shotwell to be polished and usable. > Du you want me to open tickets for all these papercuts? :-) > I wanted to wait for a possible discussion... No need; I've already opened tickets for these as appropriate. See my comments below. > * After deleting/renaming an event/tag, the sidebar jumps to the > beginning and you have to scroll down again. I can reproduce this only after deleting an event/tag, not after renaming. I've filed a ticket at http://trac.yorba.org/ticket/2611 . > * it is impossible to mark mutliple pictures with "ctrl"+"arrow > keys" and "space" like in the most common file managers. Right: that's http://trac.yorba.org/ticket/2320 . I've upped this ticket priority to high since a few people have noticed this now. > * the tags are shown nowhere in the single-picture-view. Right. This is http://trac.yorba.org/ticket/2238 . > * Sometimes there is an issue with scrolling - unfortunately I can't > really say in which situations you can reproduce that behaviour - > but it is very annoying. If you marked a picture and then scroll > down, sometimes it just jumps back to the marked picture or a bit > below. Sorry to hear it. If you can come up with a reproducible case we'd certainly like to hear about it. > * on adding tags to a picture, the suggestion of existing tags > doesn't work for non-standard characters like "?" Good catch. I've filed a ticket at http://trac.yorba.org/ticket/2612 . > * shotwell sometimes freezes without any reason for about 30sec, > after that normal work is possible. Some as above: I have no idea > how to reproduce that. Suggestions how I could see what is > happening in this moment? 1. Do you have lots of RAW photos? Are you using any sort of network filesystem? 2. If you run the GNOME System Monitor, does it show Shotwell at 100% CPU during the 30 seconds? 3. You could try running Shotwell under gdb from a console window. When the 30-second freeze occurs, type Ctrl+C in the console window to break into gdb, then type 'where' to get a backtrace. We'd be interested to see this. > * Maybe generating bigger thumbnails for the "event-picture", the > resolution seems to be not enough, in some of the event pictures I > can see pixels. Great catch - we hadn't noticed this before. I've filed a ticket at http://trac.yorba.org/ticket/2613 . > * Deleting pictures out of the trash seems not to work on > NTFS-partitons, only the trash is emptied, so the user assumes, > that the files are gone - but they are still stored in their > original place. 1. When you delete a picture out of the trash, does Shotwell display a dialog asking whether you want to only remove the file or to move the file to the desktop trash? 2. Assuming that the answer to (1) is yes, are you saying that even if you choose "Trash file", the file remains on the NTFS partition? 3. Are you sure that you have write access to the NTFS partition? > Suggestions: > > * After now using more than a hundred different tags for now 5500 > imported pictures it's getting really crowded in the sidebar. So I > suggest to put up some categories for tags, just easy ones like > "persons", "places" and so on. But we had that already, as I see > in this moment...) Right: this is http://trac.yorba.org/ticket/1401 , one of our most-requested feature ideas. > * It is impossible to adjust, which EXIF-data is shown in the lower > left corner. This could be an option, so no "easy user" will be > disturbed but still the "power user" has the posibility... This is a reasonable idea. I've added a comment with your suggestion to the existing ticket http://trac.yorba.org/ticket/2401 . > * An option for showing only photos with a special rating (for > "rejected" as an example...) or even "** or below". In some cases > this might be very useful... Yes. This capability will arrive one we implement complex boolean searches (http://trac.yorba.org/ticket/1587). Thanks again for all your suggestions! adam From scolex at centrum.cz Tue Sep 28 13:43:11 2010 From: scolex at centrum.cz (Stanislav Nowak) Date: Tue, 28 Sep 2010 15:43:11 +0200 Subject: [Shotwell] Some thought about Shotwell Message-ID: <4CA1F0EF.4020400@centrum.cz> First of all I would like to thanks you for creating this application. I was very excited when I firstly launch it. Gnome was missing feature rich photo manager for long time and I must admit that I never liked f-spot. I have some remark about source code. Although Vala's syntax is very similar to Java or C# I think that sourcefile organization should not follow Java or C# way as I felt it in your project. In my opinion when you run valac over Vala project the result should look like as gnome module written purely in c. What does it mean for Shotwell? Please separate library and application (UI) code to individual directories. For example like in Rhythmbox, they have shell directory for UI, rhytmdb for data, widgets, sources and so on. Leave one class per file. Follow gnome sourcefile name convention. This is very often in format "directory-classname". In sourcefiles use "namespace" keyword - it should save your work. For example file: \shotwelldb shotwelldb-import.vala will include: namespace Shotwelldb { class Import : ... //some code } I like the way that is used by Cannonical in their Unity project: http://bazaar.launchpad.net/~unity-team/unity/trunk/files I know it's lot of boring labor. But I think I will help shotwell to fit more in gnome environment and it should be more convenient for gnome developer. Maybe its an good idea to try push project to gnome git - at will gain more love and care :) There are only humble recommendations that I believe will help the project to grow. For me is very difficult to orient in shotwells code organization, mostly because library and application functions are mixed. I have some ideas about GUI and usability I will try to write them latter. Yours, Stanislav Nowak From mahfiaz at gmail.com Tue Sep 28 19:45:13 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Tue, 28 Sep 2010 22:45:13 +0300 Subject: [Shotwell] some papercuts In-Reply-To: <4CA2214F.6060604@yorba.org> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> Message-ID: <1285703113.6405.22.camel@antiloop> ?hel kenal p?eval, T, 2010-09-28 kell 10:09, kirjutas Adam Dingle: > > > * Sometimes there is an issue with scrolling - unfortunately I > can't > > really say in which situations you can reproduce that > behaviour - > > but it is very annoying. If you marked a picture and then > scroll > > down, sometimes it just jumps back to the marked picture or a > bit > > below. > > Sorry to hear it. If you can come up with a reproducible case we'd > certainly like to hear about it. > I can confirm it. On my computer it is easily reproducible. 1. Open an event with images enought to scroll, the thumbnail size does not matter 2. Select an image 3. Start scrolling not too fast, so you could see how the selected image jumps to the middle (vertically) one, often two times, as you keep scrolling This does not start happening every time, but if it does start, it happens with almost every try. It may be related to the mad scrolling I sometimes do with my thinkpad's touchstick middlebutton scroll. But after this starts, it happens even after closing and reopening shotwell. Regards Mattias From adam at yorba.org Tue Sep 28 20:33:43 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 28 Sep 2010 13:33:43 -0700 Subject: [Shotwell] some papercuts In-Reply-To: <1285703113.6405.22.camel@antiloop> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> <1285703113.6405.22.camel@antiloop> Message-ID: <4CA25127.3030502@yorba.org> On 09/28/2010 12:45 PM, Mattias P?ldaru wrote: > > I can confirm it. On my computer it is easily reproducible. > > 1. Open an event with images enought to scroll, the thumbnail size does > not matter > 2. Select an image > 3. Start scrolling not too fast, so you could see how the selected image > jumps to the middle (vertically) one, often two times, as you keep > scrolling > > This does not start happening every time, but if it does start, it > happens with almost every try. It may be related to the mad scrolling I > sometimes do with my thinkpad's touchstick middlebutton scroll. But > after this starts, it happens even after closing and reopening shotwell. > > > Regards > Mattias Mattias, I'm unable to reproduce this in the Shotwell trunk on Ubuntu 10.10. What version of Shotwell do you have? It sounds like the problem happens when you scroll with the touchstick middle button. Does it also happen when you scroll using Page Up/Page Down, or when you use the scrollbar on the right side of the window? adam From jim at yorba.org Tue Sep 28 21:06:24 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 28 Sep 2010 14:06:24 -0700 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: > I guess it would consist of a preference: > ignore duplicates when linking: yes/no > > I would choose "no" > > I have dupes in my collection which are not mistakes, they are > the same file, but live in different contexts. > > This seems like an interesting idea. I've ticketed it here: http://trac.yorba.org/ticket/2614 > If I was looking at one of the collection views which included a file which > existed in multiple locations, I might expect to see: > > - multiple stars under the thumb, one for each copy found > - a link which would bring up a listbox with absolute filenames > - some distinguishing feature, maybe just a different border color > > If dupes were allowed, a view named "Duplicates" would show thumbs > of all files which live in more than one directory. > > This I've ticketed here: http://trac.yorba.org/ticket/2615 Both are a shift in thinking with Shotwell's library, but not beyond consideration. -- Jim From mahfiaz at gmail.com Tue Sep 28 21:47:57 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 00:47:57 +0300 Subject: [Shotwell] some papercuts In-Reply-To: <4CA25127.3030502@yorba.org> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> <1285703113.6405.22.camel@antiloop> <4CA25127.3030502@yorba.org> Message-ID: <1285710477.6405.121.camel@antiloop> > Mattias, > > I'm unable to reproduce this in the Shotwell trunk on Ubuntu 10.10. > What version of Shotwell do you have? It sounds like the problem > happens when you scroll with the touchstick middle button. Does it also > happen when you scroll using Page Up/Page Down, or when you use the > scrollbar on the right side of the window? > > adam > I compiled the trunk today to check this out, and yes, it is present in trunk on Ubuntu 10.10. It happens with touchpad scrolling too, actually this makes no difference, as these both generate the exact same events as mouse wheel does. It also happens when using the scrollbar, although because of the speed it is harder to see it happening, but it still does. I haven't seen it with Page Down, this is all different beast. Flickering also happens when dragging the scrollbar down through large set of images, therefore: My theory is that it is caused by preloading of unvisible images. This happens only when there are enough images in the set, so that the last ones are not loaded. When you scroll down to these, images are loaded and during that time the view jumps back a little. This may be a gtk bug as well. Mattias From ktenney at gmail.com Wed Sep 29 00:38:27 2010 From: ktenney at gmail.com (Kent Tenney) Date: Tue, 28 Sep 2010 19:38:27 -0500 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: On Tue, Sep 28, 2010 at 4:06 PM, Jim Nelson wrote: > >> I guess it would consist of a preference: >> ignore duplicates when linking: yes/no >> >> I would choose "no" >> >> I have dupes in my collection which are not mistakes, they are >> the same file, but live in different contexts. >> > > This seems like an interesting idea. Oh goody. ? I've ticketed it here: > http://trac.yorba.org/ticket/2614 > >> >> If I was looking at one of the collection views which included a file >> which >> existed in multiple locations, I might expect to see: >> >> - multiple stars under the thumb, one for each copy found >> - a link which would bring up a listbox with absolute filenames >> - some distinguishing feature, maybe just a different border color >> >> If dupes were allowed, a view named "Duplicates" would show thumbs >> of all files which live in more than one directory. >> > > This I've ticketed here: http://trac.yorba.org/ticket/2615 > > Both are a shift in thinking with Shotwell's library, but not beyond > consideration. Goody again. I realized that the difference in my thinking can be exposed via differences in terminology. My _collection_ is the set of image files on my storage devices. photo.db contains the metadata associated with my collection. The Shotwell program is a tool to view and manipulate metadata, and a convenience for accessing my collection. This means that Shotwell, and photo.db in particular are ripe for all kind of mashups. Some quick tests reveal that adding a table, adding a column to PhotoTable (a blob column, putting a 300k file in it) ... all this abuse doesn't phase Shotwell, it seems very tolerant. This is good. I'm not going to code in Vala, but I look forward to lots of Python which accesses the data in photo.db. Sqlite is pretty near data franca these days. Lots of hooks for us at the fringe to work with. It seems this capability doesn't need to compromise Shotwell's prime directive, to provide a wise opinion on best practices for most users. Thanks, Kent > > -- Jim > From hendry.michael at gmail.com Wed Sep 29 09:09:35 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 10:09:35 +0100 Subject: [Shotwell] What happens when I reorganise my hard disc? Message-ID: <1285751375.1698.30.camel@Linley6> Apologies if this has been dealt with already - I've browsed the archive for similar queries, but found none. I have my images organised in various directories and subdirectories, but moved most of these directories into a single "Pictures" folder before importing them to Shotwell recently. Many files need to stay in their original directories, because the directory name indicates which 35mm film the scanned images came from, and the filenames are IMG001.jpg, IMG002.jpg to indicate the negative numbers, but I also have a lot of files imported from my Nikon D70 which are uniquely names, but which have been imported by Nikon software into a new subdirectory for each upload. These could all be moved into a single D70 directory. As well as simple housekeeping like this, there will come a time when I outgrow the USB drive I currently use, or when it needs replacement. If I understand the setup correctly, if I move any file from the directory it was in when imported by Shotwell, that I will lose all the tagging information attached to it by Shotwell, and that the file would have to be re-imported and tagged again. The mass movement of the directory structure to a new hard disc could presumably be covered by a relative simple database operation, but simpler housekeeping using this method is likely to be tedious and error-prone. I'd favour putting Shotwell in charge of the management of this sort of housekeeping on the directory structure which contains the images - is this feasible? Michael From hendry.michael at gmail.com Wed Sep 29 09:17:02 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 10:17:02 +0100 Subject: [Shotwell] Why does Export enforce file conversion? Message-ID: <1285751822.1698.38.camel@Linley6> I'd welcome the ability to export a bunch of files to a working directory for further processing, leaving the originals in place. Obviously, it's helpful to be able to reduce the size of images for transmission elsewhere, but why has it been made mandatory? Michael From goeland_86 at yahoo.fr Wed Sep 29 09:24:43 2010 From: goeland_86 at yahoo.fr (Jonathan Charnas) Date: Wed, 29 Sep 2010 11:24:43 +0200 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285751822.1698.38.camel@Linley6> References: <1285751822.1698.38.camel@Linley6> Message-ID: <4CA305DB.7030503@yahoo.fr> Seconded! Add to that the ability to perhaps filter which files are imported into the Shotwell library? My workflow uses an external program to edit my .RW2 files into jpeg. The output jpeg is in the same directory as the original raw file, but I only want the jpegs imported in shotwell. It's great to be able to use Shotwell for basic editing of RAW, but I'd much prefer if I could keep my workflow and use Shotwell at the end of it without having to manually remove the links to the original raw files that I want to conserve but not display. Thanks! Jon On 09/29/2010 11:17 AM, Michael Hendry wrote: > I'd welcome the ability to export a bunch of files to a working > directory for further processing, leaving the originals in place. > > Obviously, it's helpful to be able to reduce the size of images for > transmission elsewhere, but why has it been made mandatory? > > Michael > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From mahfiaz at gmail.com Wed Sep 29 09:24:43 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 12:24:43 +0300 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285751822.1698.38.camel@Linley6> References: <1285751822.1698.38.camel@Linley6> Message-ID: <1285752283.16003.2.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 10:17, kirjutas Michael Hendry: > I'd welcome the ability to export a bunch of files to a working > directory for further processing, leaving the originals in place. > > Obviously, it's helpful to be able to reduce the size of images for > transmission elsewhere, but why has it been made mandatory? > > Michael > 1. Select some files 2. choose File ? Export 3. set "Scaling constraint" to "Original size" 4. You get original images, no mandatory scaling Best regards Mattias From hendry.michael at gmail.com Wed Sep 29 09:27:07 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 10:27:07 +0100 Subject: [Shotwell] Writing tags to original files Message-ID: <1285752427.1698.48.camel@Linley6> There appears to be no facility for writing the tags attached to all (or a selection of) files back to the original files. This would be a very time-consuming task, I realise, but could be offered as an option when Shotwell is closed down at the end of a session on an incremental basis. This would ease my concerns about the potential loss of many hours of work in classifying and tagging images, and allow (heaven forbid!) a change to an alternative photo-management tool. Michael From goeland_86 at yahoo.fr Wed Sep 29 09:27:16 2010 From: goeland_86 at yahoo.fr (Jonathan Charnas) Date: Wed, 29 Sep 2010 11:27:16 +0200 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285752283.16003.2.camel@antiloop> References: <1285751822.1698.38.camel@Linley6> <1285752283.16003.2.camel@antiloop> Message-ID: <4CA30674.80105@yahoo.fr> I think that wasn't the question - the question was to export a number of files to a directory outside the library while keeping the original files intact. Think of it as versioning for your edits, so you can always revert to a previous version by looking at a different file, I'm guessing for the edits done from within Shotwell. Jon On 09/29/2010 11:24 AM, Mattias P?ldaru wrote: > ?hel kenal p?eval, K, 2010-09-29 kell 10:17, kirjutas Michael Hendry: >> I'd welcome the ability to export a bunch of files to a working >> directory for further processing, leaving the originals in place. >> >> Obviously, it's helpful to be able to reduce the size of images for >> transmission elsewhere, but why has it been made mandatory? >> >> Michael >> > > 1. Select some files > 2. choose File ? Export > 3. set "Scaling constraint" to "Original size" > 4. You get original images, no mandatory scaling > > > Best regards > Mattias > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -- Use Thunderbird with Enigmail for convenient and safe emails! www.getthunderbird.com From mahfiaz at gmail.com Wed Sep 29 09:39:06 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 12:39:06 +0300 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <4CA30674.80105@yahoo.fr> References: <1285751822.1698.38.camel@Linley6> <1285752283.16003.2.camel@antiloop> <4CA30674.80105@yahoo.fr> Message-ID: <1285753146.16003.7.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 11:27, kirjutas Jonathan Charnas: > I think that wasn't the question - the question was to export a number > of files to a directory outside the library while keeping the original > files intact. > > Think of it as versioning for your edits, so you can always revert to a > previous version by looking at a different file, I'm guessing for the > edits done from within Shotwell. > > Jon 1. Right click on a photo, choose "Open With External Editor" 2. As you see, the file opens as FILENAME_modified.jpg 3. Edit your file as you wish, save it and close editor. 4. Wait a second and see how Shotwell updates the thumbnail of your image. 5. If you want your original image back, right click on the image and pick "Revert to Original". Regards Mattias From mahfiaz at gmail.com Wed Sep 29 09:43:17 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 12:43:17 +0300 Subject: [Shotwell] Writing tags to original files In-Reply-To: <1285752427.1698.48.camel@Linley6> References: <1285752427.1698.48.camel@Linley6> Message-ID: <1285753397.16003.8.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 10:27, kirjutas Michael Hendry: > There appears to be no facility for writing the tags attached to all (or > a selection of) files back to the original files. > > This would be a very time-consuming task, I realise, but could be > offered as an option when Shotwell is closed down at the end of a > session on an incremental basis. > > This would ease my concerns about the potential loss of many hours of > work in classifying and tagging images, and allow (heaven forbid!) a > change to an alternative photo-management tool. > > Michael See http://trac.yorba.org/ticket/1290 , this was implemented 11 hours ago. Cudos to jim and yorba team! Mattias From mahfiaz at gmail.com Wed Sep 29 09:52:28 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 12:52:28 +0300 Subject: [Shotwell] Writing tags to original files In-Reply-To: <1285752427.1698.48.camel@Linley6> References: <1285752427.1698.48.camel@Linley6> Message-ID: <1285753948.16003.9.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 10:27, kirjutas Michael Hendry: > There appears to be no facility for writing the tags attached to all (or > a selection of) files back to the original files. > > This would be a very time-consuming task, I realise, but could be > offered as an option when Shotwell is closed down at the end of a > session on an incremental basis. > > This would ease my concerns about the potential loss of many hours of > work in classifying and tagging images, and allow (heaven forbid!) a > change to an alternative photo-management tool. > > Michael See also this ticket about sidecar files: http://trac.yorba.org/ticket/1879 Mattias From mahfiaz at gmail.com Wed Sep 29 09:55:52 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 12:55:52 +0300 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <4CA305DB.7030503@yahoo.fr> References: <1285751822.1698.38.camel@Linley6> <4CA305DB.7030503@yahoo.fr> Message-ID: <1285754152.16003.13.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 11:24, kirjutas Jonathan Charnas: > My workflow uses an external program to edit my .RW2 files into jpeg. > The output jpeg is in the same directory as the original raw file, but I > only want the jpegs imported in shotwell. > > It's great to be able to use Shotwell for basic editing of RAW, but I'd > much prefer if I could keep my workflow and use Shotwell at the end of > it without having to manually remove the links to the original raw files > that I want to conserve but not display. > > Thanks! > Jon Not exactly an answer to your question, but see Adam's post from April: http://lists.yorba.org/pipermail/shotwell/2010-April/000282.html Mattias From mahfiaz at gmail.com Wed Sep 29 10:01:09 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Wed, 29 Sep 2010 13:01:09 +0300 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285752644.1698.50.camel@Linley6> References: <1285751822.1698.38.camel@Linley6> <1285752283.16003.2.camel@antiloop> <1285752644.1698.50.camel@Linley6> Message-ID: <1285754469.16003.18.camel@antiloop> ?hel kenal p?eval, K, 2010-09-29 kell 10:30, kirjutas Michael Hendry: > On Wed, 2010-09-29 at 12:24 +0300, Mattias P?ldaru wrote: > > ?hel kenal p?eval, K, 2010-09-29 kell 10:17, kirjutas Michael Hendry: > > > I'd welcome the ability to export a bunch of files to a working > > > directory for further processing, leaving the originals in place. > > > > > > Obviously, it's helpful to be able to reduce the size of images for > > > transmission elsewhere, but why has it been made mandatory? > > > > > > Michael > > > > > > But if my original file was a NEF file, I have to have it converted to a > JPG or PNG file. > > Michael > Please use Reply all button, so your answers will go to the list. I think this is worth adding a ticket. I never had NEF files, but I think at moment this applies to RAW or whatever other files as well. http://trac.yorba.org/newticket Mattias From hendry.michael at gmail.com Wed Sep 29 10:07:31 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 11:07:31 +0100 Subject: [Shotwell] Writing tags to original files In-Reply-To: <1285753397.16003.8.camel@antiloop> References: <1285752427.1698.48.camel@Linley6> <1285753397.16003.8.camel@antiloop> Message-ID: <1285754851.1698.55.camel@Linley6> On Wed, 2010-09-29 at 12:43 +0300, Mattias P?ldaru wrote: > ?hel kenal p?eval, K, 2010-09-29 kell 10:27, kirjutas Michael Hendry: > > There appears to be no facility for writing the tags attached to all (or > > a selection of) files back to the original files. > > > > This would be a very time-consuming task, I realise, but could be > > offered as an option when Shotwell is closed down at the end of a > > session on an incremental basis. > > > > This would ease my concerns about the potential loss of many hours of > > work in classifying and tagging images, and allow (heaven forbid!) a > > change to an alternative photo-management tool. > > > > Michael > > See http://trac.yorba.org/ticket/1290 , this was implemented 11 hours > ago. Cudos to jim and yorba team! > > > Mattias > > > Brilliant! I haven't yet got round to downloading source files and compiling locally, but I can afford to wait for a stable release. Michael From hendry.michael at gmail.com Wed Sep 29 10:09:40 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 11:09:40 +0100 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285753146.16003.7.camel@antiloop> References: <1285751822.1698.38.camel@Linley6> <1285752283.16003.2.camel@antiloop> <4CA30674.80105@yahoo.fr> <1285753146.16003.7.camel@antiloop> Message-ID: <1285754980.1698.56.camel@Linley6> On Wed, 2010-09-29 at 12:39 +0300, Mattias P?ldaru wrote: > ?hel kenal p?eval, K, 2010-09-29 kell 11:27, kirjutas Jonathan Charnas: > > I think that wasn't the question - the question was to export a number > > of files to a directory outside the library while keeping the original > > files intact. > > > > Think of it as versioning for your edits, so you can always revert to a > > previous version by looking at a different file, I'm guessing for the > > edits done from within Shotwell. > > > > Jon > > 1. Right click on a photo, choose "Open With External Editor" > 2. As you see, the file opens as FILENAME_modified.jpg > 3. Edit your file as you wish, save it and close editor. > 4. Wait a second and see how Shotwell updates the thumbnail of your > image. > 5. If you want your original image back, right click on the image and > pick "Revert to Original". > > > > Regards > Mattias But if my original file was a NEF file, I have to have it converted to a JPG or PNG file. Michael From goeland_86 at yahoo.fr Wed Sep 29 10:20:36 2010 From: goeland_86 at yahoo.fr (Jonathan Charnas) Date: Wed, 29 Sep 2010 12:20:36 +0200 Subject: [Shotwell] Why does Export enforce file conversion? Message-ID: <4CA312F4.4080407@yahoo.fr> Aha. Well that's great, but the output jpeg has an added extension. Say if I edit P10001.RW2, the jpeg will be saved as P10001_lzn.jpg If I'm reading Adam's post properly, I'd be better off saving it as P10001.jpg and just re-import the directory? Personally I'd much prefer just importing the final result - LightZone stores the action history and links between RW2 and jpg in a db similar to shotwell's, but it pertains only to the editing done. Thus having an option to force shotwell to just ignore the RAW files entirely. Alternatively you could also show images imported and filter by filetype also - that would make me just as happy. Cheers, Jon On 09/29/2010 11:55 AM, Mattias P?ldaru wrote: > ?hel kenal p?eval, K, 2010-09-29 kell 11:24, kirjutas Jonathan Charnas: >> My workflow uses an external program to edit my .RW2 files into jpeg. >> The output jpeg is in the same directory as the original raw file, but I >> only want the jpegs imported in shotwell. >> >> It's great to be able to use Shotwell for basic editing of RAW, but I'd >> much prefer if I could keep my workflow and use Shotwell at the end of >> it without having to manually remove the links to the original raw files >> that I want to conserve but not display. >> >> Thanks! >> Jon > Not exactly an answer to your question, but see Adam's post from April: > http://lists.yorba.org/pipermail/shotwell/2010-April/000282.html > > Mattias > > From jim at yorba.org Wed Sep 29 18:05:45 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 29 Sep 2010 11:05:45 -0700 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: > This means that Shotwell, and photo.db in particular are ripe for all kind > of mashups. Some quick tests reveal that adding a table, adding a column > to PhotoTable (a blob column, putting a 300k file in it) ... all this > abuse doesn't > phase Shotwell, it seems very tolerant. This is good. > > I'm not going to code in Vala, but I look forward to lots of Python > which accesses > the data in photo.db. Sqlite is pretty near data franca these days. Lots of > hooks for us at the fringe to work with. > I would mention that we treat photo.db as a private data store, in the sense that we might change the schema at any time or the semantics of the database (i.e. how some of the data is interpreted). Also, Shotwell does not access the database in a transactional manner. If you modify the database while Shotwell is running, bad things can happen, including lost data. More information is on our wiki: http://trac.yorba.org/wiki/ShotwellArchDatabase -- Jim From jim at yorba.org Wed Sep 29 18:25:45 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 29 Sep 2010 11:25:45 -0700 Subject: [Shotwell] What happens when I reorganise my hard disc? In-Reply-To: <1285751375.1698.30.camel@Linley6> References: <1285751375.1698.30.camel@Linley6> Message-ID: With the current release of Shotwell (0.7.2), you are correct -- the organizational data you've associated with the photos (as well as any transformations you've made) would be lost. When you run Shotwell, all the photos you've moved will appear in the "Missing Files" page. In Shotwell 0.8, we're implementing additional features to deal with how your photos are stored on disk. It will attempt to find files that have been moved (to a different directory and/or renamed) and re-associate that file with the photo in the database -- no information lost. If Shotwell detects that the photo has been altered (i.e. by an outside image editor), Shotwell will do an in-place reimport; you won't lose tags or events, but you will lose image edits (i.e. enhance, crop) because those transformations were made against a different image. Neither of these quite solves your problem because Shotwell 0.8 currently only does these things in your library directory (i.e. ~/Pictures, or whatever you've got set in your Shotwell Preferences dialog). If you move the photos outside of the library directory, then Shotwell will treat them as Missing Files. I think what you're asking for is one of two things. One would be to allow Shotwell to expand it's scope of what a library directory can be -- multiple directories, perhaps, or allowing you to place a symbolic link in your Pictures directory that Shotwell honors. The other thing I think you're suggesting (in your last paragraph) is that Shotwell does the file moving for you. Is this what you're asking for? I'm trying to work out exactly what use-case you're envisioning here. -- Jim On Wed, Sep 29, 2010 at 2:09 AM, Michael Hendry wrote: > Apologies if this has been dealt with already - I've browsed the archive > for similar queries, but found none. > > I have my images organised in various directories and subdirectories, > but moved most of these directories into a single "Pictures" folder > before importing them to Shotwell recently. > > Many files need to stay in their original directories, because the > directory name indicates which 35mm film the scanned images came from, > and the filenames are IMG001.jpg, IMG002.jpg to indicate the negative > numbers, but I also have a lot of files imported from my Nikon D70 which > are uniquely names, but which have been imported by Nikon software into > a new subdirectory for each upload. These could all be moved into a > single D70 directory. > > As well as simple housekeeping like this, there will come a time when I > outgrow the USB drive I currently use, or when it needs replacement. > > If I understand the setup correctly, if I move any file from the > directory it was in when imported by Shotwell, that I will lose all the > tagging information attached to it by Shotwell, and that the file would > have to be re-imported and tagged again. > > The mass movement of the directory structure to a new hard disc could > presumably be covered by a relative simple database operation, but > simpler housekeeping using this method is likely to be tedious and > error-prone. > > I'd favour putting Shotwell in charge of the management of this sort of > housekeeping on the directory structure which contains the images - is > this feasible? > > Michael > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Sep 29 18:31:00 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 29 Sep 2010 11:31:00 -0700 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <4CA312F4.4080407@yahoo.fr> References: <4CA312F4.4080407@yahoo.fr> Message-ID: I feel like a few things are being batted around here in this thread, but I'm still not sure what's being asked for. When you say you want Shotwell to export so files can be edited separately from their originals, do you mean by Shotwell or a different editor? First, Shotwell is a non-destructive editor; we don't write our changes to the master file, so it's easy to try edits without losing data. Second, as mentioned, Shotwell does have an "Edit with External Editor" (and "Edit with External RAW Editor") which allows the files to be monitored and managed by Shotwell, but edited (destructively) elsewhere. Shotwell makes a full-sized copy (and converts RAW files to JPEG, if using the first option) so your master is safe. Third, no one has mentioned the Edit -> Duplicate option. This creates a duplicate of the photo (including a new copy of the file) in your library. This might be what some people are asking for. -- Jim On Wed, Sep 29, 2010 at 3:20 AM, Jonathan Charnas wrote: > Aha. Well that's great, but the output jpeg has an added extension. > Say if I edit P10001.RW2, the jpeg will be saved as P10001_lzn.jpg > If I'm reading Adam's post properly, I'd be better off saving it as > P10001.jpg and just re-import the directory? > > Personally I'd much prefer just importing the final result - LightZone > stores the action history and links between RW2 and jpg in a db similar > to shotwell's, but it pertains only to the editing done. Thus having an > option to force shotwell to just ignore the RAW files entirely. > > Alternatively you could also show images imported and filter by filetype > also - that would make me just as happy. > > Cheers, > Jon > > > On 09/29/2010 11:55 AM, Mattias P?ldaru wrote: > > ?hel kenal p?eval, K, 2010-09-29 kell 11:24, kirjutas Jonathan Charnas: > >> My workflow uses an external program to edit my .RW2 files into jpeg. > >> The output jpeg is in the same directory as the original raw file, but I > >> only want the jpegs imported in shotwell. > >> > >> It's great to be able to use Shotwell for basic editing of RAW, but I'd > >> much prefer if I could keep my workflow and use Shotwell at the end of > >> it without having to manually remove the links to the original raw files > >> that I want to conserve but not display. > >> > >> Thanks! > >> Jon > > Not exactly an answer to your question, but see Adam's post from April: > > http://lists.yorba.org/pipermail/shotwell/2010-April/000282.html > > > > Mattias > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From ktenney at gmail.com Wed Sep 29 19:18:27 2010 From: ktenney at gmail.com (Kent Tenney) Date: Wed, 29 Sep 2010 14:18:27 -0500 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: On Wed, Sep 29, 2010 at 1:05 PM, Jim Nelson wrote: > >> This means that Shotwell, and photo.db in particular are ripe for all kind >> of mashups. Some quick tests reveal that adding a table, adding a column >> to PhotoTable (a blob column, putting a 300k file in it) ... all this >> abuse doesn't >> phase Shotwell, it seems very tolerant. This is good. >> >> I'm not going to code in Vala, but I look forward to lots of Python >> which accesses >> the data in photo.db. Sqlite is pretty near data franca these days. Lots >> of >> hooks for us at the fringe to work with. > > I would mention that we treat photo.db as a private data store, in the sense > that we might change the schema at any time or the semantics of the database > (i.e. how some of the data is interpreted). Right, code which went right to photo.db would expect to adapt to your schema, and know enough not to change the data Shotwell depends on. Good news is that Shotwell seems to tolerate extra stuff it doesn't know about. > > Also, Shotwell does not access the database in a transactional manner.? If > you modify the database while Shotwell is running, bad things can happen, > including lost data. Right, anyone fool enough to do what I'm proposing would understand that if they break it they get to keep all the pieces. ? More information is on our wiki: > http://trac.yorba.org/wiki/ShotwellArchDatabase Is it possible to enable a persistent transaction journal for photo.db? Thanks, Kent > > -- Jim > From hendry.michael at gmail.com Wed Sep 29 21:32:29 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 22:32:29 +0100 Subject: [Shotwell] What happens when I reorganise my hard disc? In-Reply-To: References: <1285751375.1698.30.camel@Linley6> Message-ID: <1285795949.1698.100.camel@Linley6> On Wed, 2010-09-29 at 11:25 -0700, Jim Nelson wrote: > With the current release of Shotwell (0.7.2), you are correct -- the > organizational data you've associated with the photos (as well as any > transformations you've made) would be lost. When you run Shotwell, > all the photos you've moved will appear in the "Missing Files" page. > > In Shotwell 0.8, we're implementing additional features to deal with > how your photos are stored on disk. It will attempt to find files > that have been moved (to a different directory and/or renamed) and > re-associate that file with the photo in the database -- no > information lost. If Shotwell detects that the photo has been altered > (i.e. by an outside image editor), Shotwell will do an in-place > reimport; you won't lose tags or events, but you will lose image edits > (i.e. enhance, crop) because those transformations were made against a > different image. Thanks for your patient attention to my queries, Jim. In general, I tend not to overwrite the original files, but save successive versions as IMG000 draft01.jpg, IMG000 draf02.jpg etc. (Overcautious, perhaps, but I'm hopeful that my skills at improving images will themselves improve, and I may come back to an original image later and do a better job of it). I understand that Shotwell won't notice these edited versions unless I re-import the directory they're contained in, although this would be a helpful feature. > > Neither of these quite solves your problem because Shotwell 0.8 > currently only does these things in your library directory (i.e. > ~/Pictures, or whatever you've got set in your Shotwell Preferences > dialog). If you move the photos outside of the library directory, > then Shotwell will treat them as Missing Files. I haven't imported any files into this directory so far, because of familiarity with the existing structure of my image file directories. > > I think what you're asking for is one of two things. One would be to > allow Shotwell to expand it's scope of what a library directory can be > -- multiple directories, perhaps, or allowing you to place a symbolic > link in your Pictures directory that Shotwell honors. I'm only a couple of months into my migration to Ubuntu from Windows, so my knowledge of symbolic links is negligible. If I understand the idea correctly, it's possible in linux to have the same file apparently stored in more than one directory, but actually have only one copy of the file stored on disc, with entries in all but the "true" directory simply pointing to the single copy. I'd imagine that the operating system itself would handle the links appropriately if the file they're pointing to is moved. If this is the case, keeping symbolic links in ~/pictures would work well, provided linux is invoked to move the files about. I'm thinking, for example, of moving all the images taken by a particular camera with unique filenames into a single directory from the individual directories they were original imported into from the camera, either by dragging and dropping or using a shell script. > The other thing I think you're suggesting (in your last paragraph) is > that Shotwell does the file moving for you. > > Is this what you're asking for? I'm trying to work out exactly what > use-case you're envisioning here. This would be a way of keeping Shotwell in the driving seat when files are being moved around - using some kind of internal file manager whose activities would be monitored and appropriate adjustments then made to the Shotwell database. I'm thinking of two different scenarios: 1. Tidying up and consolidation of the directory tree of image files. 2. Moving files around to cope with hard discs filling up or needing replacement. >From a logical point of view these are the same activity - only the scale is different. Michael > > -- Jim > > On Wed, Sep 29, 2010 at 2:09 AM, Michael Hendry > wrote: > Apologies if this has been dealt with already - I've browsed > the archive > for similar queries, but found none. > > I have my images organised in various directories and > subdirectories, > but moved most of these directories into a single "Pictures" > folder > before importing them to Shotwell recently. > > Many files need to stay in their original directories, because > the > directory name indicates which 35mm film the scanned images > came from, > and the filenames are IMG001.jpg, IMG002.jpg to indicate the > negative > numbers, but I also have a lot of files imported from my Nikon > D70 which > are uniquely names, but which have been imported by Nikon > software into > a new subdirectory for each upload. These could all be moved > into a > single D70 directory. > > As well as simple housekeeping like this, there will come a > time when I > outgrow the USB drive I currently use, or when it needs > replacement. > > If I understand the setup correctly, if I move any file from > the > directory it was in when imported by Shotwell, that I will > lose all the > tagging information attached to it by Shotwell, and that the > file would > have to be re-imported and tagged again. > > The mass movement of the directory structure to a new hard > disc could > presumably be covered by a relative simple database operation, > but > simpler housekeeping using this method is likely to be tedious > and > error-prone. > > I'd favour putting Shotwell in charge of the management of > this sort of > housekeeping on the directory structure which contains the > images - is > this feasible? > > Michael > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From simonspa at kth.se Wed Sep 29 21:47:28 2010 From: simonspa at kth.se (Simon Spannagel) Date: Wed, 29 Sep 2010 23:47:28 +0200 Subject: [Shotwell] some papercuts In-Reply-To: <4CA2214F.6060604@yorba.org> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> Message-ID: <4CA3B3F0.5040504@kth.se> Am 28.09.2010 19:09, schrieb Adam Dingle: > 1. Do you have lots of RAW photos? Are you using any sort of network > filesystem? "no" twice - only 3 RAWs so far, everything on a local ext4 on a SSD (yeah, nice, I know...) > 2. If you run the GNOME System Monitor, does it show Shotwell at 100% > CPU during the 30 seconds? Yes. > 3. You could try running Shotwell under gdb from a console window. > When the 30-second freeze occurs, type Ctrl+C in the console window to > break into gdb, then type 'where' to get a backtrace. We'd be > interested to see this. I'll do that the next time it occurs... NTFS: > > 1. When you delete a picture out of the trash, does Shotwell display a > dialog asking whether you want to only remove the file or to move the > file to the desktop trash? Yes. It looks exactly like from a "normal" ext3/4-filesystem and I can choose whether I want to keep the pictures or not. > 2. Assuming that the answer to (1) is yes, are you saying that even if > you choose "Trash file", the file remains on the NTFS partition? Exactly. Maybe this is due to the fact that GNOME can't create/use trash folders on NTFS partitions at all. > 3. Are you sure that you have write access to the NTFS partition? Yes. Of course. Greetings, SImon From hendry.michael at gmail.com Wed Sep 29 22:00:15 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 29 Sep 2010 23:00:15 +0100 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: References: <4CA312F4.4080407@yahoo.fr> Message-ID: <1285797615.1698.125.camel@Linley6> On Wed, 2010-09-29 at 11:31 -0700, Jim Nelson wrote: > I feel like a few things are being batted around here in this thread, but > I'm still not sure what's being asked for. When you say you want Shotwell > to export so files can be edited separately from their originals, do you > mean by Shotwell or a different editor? I expected Export to allow me to select a group of image files - perhaps all the files with a particular tag in common - and make unchanged copies of them somewhere else. It seems odd to me that a file conversion (to jpg or png) would be forced on me, albeit with an option on filesize. Obviously, I could use the File Manager to make copies of these files one by one, but I'd have to identify each one of the tabbed files separately, open the relevant directory, and copy the file to the destination directory. > > First, Shotwell is a non-destructive editor; we don't write our changes to > the master file, so it's easy to try edits without losing data. But I might want to export a group of files which share the same tag to a USB stick, e.g. for a colleague to work on. I would want him to have the original NEF files to work on (e.g. to adjust exposure settings) rather than a JPG. > > Second, as mentioned, Shotwell does have an "Edit with External Editor" (and > "Edit with External RAW Editor") which allows the files to be monitored and > managed by Shotwell, but edited (destructively) elsewhere. Shotwell makes a > full-sized copy (and converts RAW files to JPEG, if using the first option) > so your master is safe. Forgive me for having some anxieties about this process, and my ability to manage it correctly. > > Third, no one has mentioned the Edit -> Duplicate option. This creates a > duplicate of the photo (including a new copy of the file) in your library. > This might be what some people are asking for. Presumably the copy is in the same folder as the original file, so I'd have to chase through various directories to find the files I wanted to edit, and which had been duplicated to protect the originals? Michael > > -- Jim > > On Wed, Sep 29, 2010 at 3:20 AM, Jonathan Charnas wrote: > > > Aha. Well that's great, but the output jpeg has an added extension. > > Say if I edit P10001.RW2, the jpeg will be saved as P10001_lzn.jpg > > If I'm reading Adam's post properly, I'd be better off saving it as > > P10001.jpg and just re-import the directory? > > > > Personally I'd much prefer just importing the final result - LightZone > > stores the action history and links between RW2 and jpg in a db similar > > to shotwell's, but it pertains only to the editing done. Thus having an > > option to force shotwell to just ignore the RAW files entirely. > > > > Alternatively you could also show images imported and filter by filetype > > also - that would make me just as happy. > > > > Cheers, > > Jon > > > > > > On 09/29/2010 11:55 AM, Mattias P?ldaru wrote: > > > ?hel kenal p?eval, K, 2010-09-29 kell 11:24, kirjutas Jonathan Charnas: > > >> My workflow uses an external program to edit my .RW2 files into jpeg. > > >> The output jpeg is in the same directory as the original raw file, but I > > >> only want the jpegs imported in shotwell. > > >> > > >> It's great to be able to use Shotwell for basic editing of RAW, but I'd > > >> much prefer if I could keep my workflow and use Shotwell at the end of > > >> it without having to manually remove the links to the original raw files > > >> that I want to conserve but not display. > > >> > > >> Thanks! > > >> Jon > > > Not exactly an answer to your question, but see Adam's post from April: > > > http://lists.yorba.org/pipermail/shotwell/2010-April/000282.html > > > > > > Mattias > > > > > > > > _______________________________________________ > > 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 jim at yorba.org Thu Sep 30 00:58:07 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 29 Sep 2010 17:58:07 -0700 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: > Is it possible to enable a persistent transaction journal for photo.db? > I'm not sure what you mean. Are you referring to persistent journaling in the SQLite engine itself, or journaling photo edits? If the former, how would that help with what you're working on? -- Jim From jim at yorba.org Thu Sep 30 01:05:02 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 29 Sep 2010 18:05:02 -0700 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: <1285797615.1698.125.camel@Linley6> References: <4CA312F4.4080407@yahoo.fr> <1285797615.1698.125.camel@Linley6> Message-ID: On Wed, Sep 29, 2010 at 3:00 PM, Michael Hendry wrote: > > I expected Export to allow me to select a group of image files - perhaps > all the files with a particular tag in common - and make unchanged > copies of them somewhere else. It seems odd to me that a file conversion > (to jpg or png) would be forced on me, albeit with an option on > filesize. > Ok -- I see now what you're asking for. Yes, this makes more than enough sense. I've ticketed it here: http://trac.yorba.org/ticket/2621 As I mentioned in the ticket, this would mean that no edits you've made in Shotwell (enhance, crop) would be reflected in the RAW files. We currently do not support writing metadata to RAW files either, so tags (for example) would not be written out (until this ticket is completed: http://trac.yorba.org/ticket/2622) -- Jim From hendry.michael at gmail.com Thu Sep 30 07:06:27 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Thu, 30 Sep 2010 08:06:27 +0100 Subject: [Shotwell] Why does Export enforce file conversion? In-Reply-To: References: <4CA312F4.4080407@yahoo.fr> <1285797615.1698.125.camel@Linley6> Message-ID: <1285830387.1733.53.camel@Linley6> On Wed, 2010-09-29 at 18:05 -0700, Jim Nelson wrote: > > On Wed, Sep 29, 2010 at 3:00 PM, Michael Hendry > wrote: > > > I expected Export to allow me to select a group of image files > - perhaps > all the files with a particular tag in common - and make > unchanged > copies of them somewhere else. It seems odd to me that a file > conversion > (to jpg or png) would be forced on me, albeit with an option > on > filesize. > > Ok -- I see now what you're asking for. Yes, this makes more than > enough sense. I've ticketed it here: > http://trac.yorba.org/ticket/2621 > > As I mentioned in the ticket, this would mean that no edits you've > made in Shotwell (enhance, crop) would be reflected in the RAW files. > We currently do not support writing metadata to RAW files either, so > tags (for example) would not be written out (until this ticket is > completed: http://trac.yorba.org/ticket/2622) > > -- Jim I wouldn't necessarily want to roll back all changes made within Shotwell since the file was originally imported, more a WYSIWYG exercise - if the file is unmodified, it should go out as it was when it came in. Now I think about it, there should probably be several options: 1. Export files in their original forms. 2. Export as original if not already modified by Shotwell, in which case a compression option is required for the latter. 3. Export all in a compressed form (as at present). I would use option 1 for photographic print competition candidates - doing the selection within Shotwell, but going back to the original files and re-editing to get the best possible quality for a big print. Option 2 would be similar, but for presentation purposes - I'd accept the edits already done within Shotwell as a time-saver. Option 3 would be for circulation by e-mail, Flickr etc., where no further editing is required, but compression is necessary for speed of transmission. Sorry my powers of communication are insufficient to get my ideas through first time round, but these ideas are themselves in a state of flux as I get used to using Shotwell! Reflecting on the above before pressing the Send button, I can see that I could achieve the same results as options 1 and 2 by creating duplicates of the original files, and invoking GIMP (or whatever) on the duplicates, with distinct lines of descendant images for different purposes. I obviously have to change a mind-set here - keeping track of competition candidates by using File Manager to copy them into a working directory becomes unnecessary when I can skim through the whole collection with Shotwell and tag the candidates as I go. Michael From ktenney at gmail.com Thu Sep 30 13:16:49 2010 From: ktenney at gmail.com (Kent Tenney) Date: Thu, 30 Sep 2010 08:16:49 -0500 Subject: [Shotwell] Importing In-Reply-To: References: Message-ID: On Wed, Sep 29, 2010 at 7:58 PM, Jim Nelson wrote: > >> Is it possible to enable a persistent transaction journal for photo.db? > > I'm not sure what you mean.? Are you referring to persistent journaling in > the SQLite engine itself Yes , or journaling photo edits?? If the former, how > would that help with what you're working on? A journal file might provide a safety net if I managed to really bork stuff. And my hoarding instincts tell me that some day I'll want, for some reason, the data in the journal. No big deal, but if it was simple for you to create a config option, I would choose to create and persist journals. Thanks, Kent > > -- Jim > From adam at yorba.org Thu Sep 30 16:08:03 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 30 Sep 2010 09:08:03 -0700 Subject: [Shotwell] some papercuts In-Reply-To: <4CA3B3F0.5040504@kth.se> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> <4CA3B3F0.5040504@kth.se> Message-ID: <4CA4B5E3.9020907@yorba.org> On 09/29/2010 02:47 PM, Simon Spannagel wrote: >> 3. You could try running Shotwell under gdb from a console window. >> When the 30-second freeze occurs, type Ctrl+C in the console window to >> break into gdb, then type 'where' to get a backtrace. We'd be >> interested to see this. > I'll do that the next time it occurs... > That would be great, and might help us understand what's going on here. Regarding the NTFS deletion problem, I've filed a ticket at http://trac.yorba.org/ticket/2624 adam From raivo.kask at zerone.se Thu Sep 30 07:38:25 2010 From: raivo.kask at zerone.se (Raivo Kask) Date: Thu, 30 Sep 2010 09:38:25 +0200 Subject: [Shotwell] Debian Message-ID: <4CA43E71.8060906@zerone.se> I have Debian Squeeze and Shotwell 0.6.1 How can I get Shotwell 0.7.2 via PPA ? From jim at yorba.org Thu Sep 30 18:39:22 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 30 Sep 2010 11:39:22 -0700 Subject: [Shotwell] some papercuts In-Reply-To: <4CA3B3F0.5040504@kth.se> References: <4CA0CEF1.8050508@kth.se> <4CA2214F.6060604@yorba.org> <4CA3B3F0.5040504@kth.se> Message-ID: On Wed, Sep 29, 2010 at 2:47 PM, Simon Spannagel wrote: > > Exactly. Maybe this is due to the fact that GNOME can't create/use trash > folders on NTFS partitions at all. > Could you do the following? Run Shotwell from the command prompt like this: $ SHOTWELL_LOG=1 shotwell Attempt to delete a photo as you've mentioned, telling Shotwell to move it into the desktop trash. Exit Shotwell and verify the file is still on disk. Then send me (or attach to this ticket: http://trac.yorba.org/ticket/2624) this file: ~/.cache/shotwell/shotwell.log Thanks! -- Jim From jim at yorba.org Thu Sep 30 18:42:56 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 30 Sep 2010 11:42:56 -0700 Subject: [Shotwell] Debian In-Reply-To: <4CA43E71.8060906@zerone.se> References: <4CA43E71.8060906@zerone.se> Message-ID: Shotwell (and two libraries it relies on) are available at the Yorba Launchpad PPA: https://launchpad.net/~yorba/+archive/ppa I doubt this works with Squeeze, but I'm throwing it out there. I'm unaware of any Debian-specific PPA for Shotwell. If you do find one, we'd love to know. -- Jim On Thu, Sep 30, 2010 at 12:38 AM, Raivo Kask wrote: > I have Debian Squeeze and Shotwell 0.6.1 > How can I get Shotwell 0.7.2 via PPA ? > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Thu Sep 30 22:32:10 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 30 Sep 2010 15:32:10 -0700 Subject: [Shotwell] Some thought about Shotwell In-Reply-To: <4CA1F0EF.4020400@centrum.cz> References: <4CA1F0EF.4020400@centrum.cz> Message-ID: Hello Stanislav, I've been thinking quite a bit about reorganizing the Shotwell code base, mostly because (a) the number of files in a single directory is growing to an unmanageable number, even for someone (like me) who knows the code base in and out, and (b) to make it more approachable for outside contributors. I think you're bringing up some other points that are also worth considering. To take them apart as separate questions: 1. Directory organization (which is what I've been thinking about) 2. Source file naming conventions 3. Class-per-file question (implied by #2) 4. Namespaces (which I've been thinking about as well) To address each of these: 1. We're in agreement here, and looking over Rhythmbox's code, I see parallels in what I've been pondering and how they sort things. This is something I would definitely like to do with Shotwell's code base. 2. I'm seeing some variations on source file names depending on the project: * Rhythmbox uses a variant of the mechanism you're speaking of (i.e. metadata/rb-metadata-common.c) * The Vala compiler uses another (ccode/valaccodecomment.vala). * Rygel uses Rhythmbox-style naming (ui/rygel-preferences-dialog.vala) * F-Spot uses the C#/Java naming style (Imaging/JpegFile.cs) * pitivi uses something similar, although not CamelCased (ui/propertyeditor.py) Note that none of these strictly follow the GTK naming convention (gtk/gtkbutton.c). What the above list tells me is that the jury is still out on an "official" naming convention, especially in terms of non-C languages, with the one exception that the filenames should be all lowercase (unless it's Mono/C#/Java). You say that when valac runs it should look like a GNOME module written in pure C. I'm not sure I agree with that. When you run valac in its default mode, it deletes the .c files after compiling and linking. In a larger project, yes, we keep them around to speed up compilation time (as well as to examine them for debugging/performance reasons), but they are not useful as "source" code -- no one should be editing them, and patching them downstream would be dangerous territory. If we're going to rethink our source naming convention, I feel it should be, above all else, consistent and intuitive for Vala coders. I don't feel our naming should be a slave to the .c files produced. If I was using Vala to produce a GObject library, then yes, that's more compelling. (When we produce header files for plug-ins, that would be a place we think about it -- I'm just not sure we want to let our yet-to-be coded plug-in architecture dictate filenames everywhere else.) 3. One thing that is true for GTK, Rhythmbox, Vala, and Rygel is a strict one-class-per-file organization. There are hundreds of classes in Shotwell, and I don't think putting each and every one in a separate file is doing a service to developers. (For example, we have 34 Command subclasses for the undo/redo system. Some are 13 lines long.) I do think many of our files have grown too large and should be broken up to keep the chunks small. We've done a good job keeping UI code away from implementation code, it's just a matter of separating the files appropriately in directories. Breaking up the files into smaller chunks makes a lot of sense too. 4. Namespaces are something else I'm considering -- making each subdirectory a namespace makes logical sense to me, and means the code reflects the logical organization of the source files. Plus, there's a cool Vala feature -- the "internal" keyword -- that we can start taking advantage of with well-thought-out namespacing. These are my thoughts today. Things are still jelling. If you (or anyone) would like to jump in with comments or suggestions, by all means. -- Jim On Tue, Sep 28, 2010 at 6:43 AM, Stanislav Nowak wrote: > First of all I would like to thanks you for creating this application. I > was very excited when I firstly launch it. Gnome was missing feature > rich photo manager for long time and I must admit that I never liked > f-spot. > > I have some remark about source code. > Although Vala's syntax is very similar to Java or C# I think that > sourcefile organization should not follow Java or C# way as I felt it in > your project. In my opinion when you run valac over Vala project the > result should look like as gnome module written purely in c. > What does it mean for Shotwell? Please separate library and application > (UI) code to individual directories. For example like in Rhythmbox, they > have shell directory for UI, rhytmdb for data, widgets, sources and so > on. Leave one class per file. Follow gnome sourcefile name convention. > This is very often in format "directory-classname". In sourcefiles use > "namespace" keyword - it should save your work. For example file: > > \shotwelldb > shotwelldb-import.vala > > will include: > namespace Shotwelldb { > class Import : ... > //some code > } > > > I like the way that is used by Cannonical in their Unity project: > http://bazaar.launchpad.net/~unity-team/unity/trunk/files > > > I know it's lot of boring labor. But I think I will help shotwell to fit > more in gnome environment and it should be more convenient for gnome > developer. Maybe its an good idea to try push project to gnome git - at > will gain more love and care :) > > There are only humble recommendations that I believe will help the > project to grow. For me is very difficult to orient in shotwells code > organization, mostly because library and application functions are mixed. > > I have some ideas about GUI and usability I will try to write them latter. > > Yours, > Stanislav Nowak > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From ndimby.andriantsoavina at auf.org Mon Sep 27 20:19:08 2010 From: ndimby.andriantsoavina at auf.org (Ndimby Andriantsoavina) Date: Mon, 27 Sep 2010 20:19:08 +0000 Subject: [Shotwell] IDE and Flickr feature In-Reply-To: <4CA0C965.9000107@yorba.org> References: <4CA0BF79.7000401@odaeus.co.uk> <4CA0C965.9000107@yorba.org> Message-ID: <4CA0FC3C.5050704@auf.org> Hi all, I'm not a coder and the english is not my mother tongue but I recently came across shotwell. And I really appreciate the work you have done guys. I used to uploads my photo on flickr with postr (http://projects.gnome.org/postr/). And I'm wondering if it's possible to add some features: - add to set: which upload photo directly in existing set - send to group: so the organising part is done before the upload. Cheers, -- - Ndimby Andriantsoavina