From luka at bubi.si Tue Jun 1 12:31:24 2010 From: luka at bubi.si (Luka Oman) Date: Tue, 1 Jun 2010 14:31:24 +0200 Subject: [Shotwell] Sharpness, BW control, sephia, glow Message-ID: Hi! Recently I upgraded to Fedora 13 and with it came Shotwell. Before I used Picasa 3 (beta?) and was disappointed the development stopped. I give Shotwell a try and was impressed with the responsiveness, ease of use and quality of the software. However I lack some of the automation the Picasa has, like sephia and glow filters, BW control and mostly sharpness. I noticed in trac you have an entry for sharpness control, but it hasn't been updated for months. Are there any plans for this feature, that I missed the most? As said great app, looking forward to see it grow. Keep it powerful and light :) Regards; Luka From jim at yorba.org Tue Jun 1 18:38:41 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 1 Jun 2010 11:38:41 -0700 Subject: [Shotwell] Open with Raw Editor and Importing images... In-Reply-To: References: Message-ID: Hello, On Mon, May 31, 2010 at 9:03 AM, Chris Lindsay wrote: > I have been testing out some of the recent enhancements to Shotwell > 0.5.90+trunk and have a few thoughts on how certain aspects have been > implements. Great! > ? ? - When you click on the menu item with a raw file selected, GIMP > is used to open the raw file using the UFRaw plugin. My preference > here would to have UFRaw opened directly as not everyone will want to > open the edited raw file in GIMP and as it stands the only way to save > the file is to finally open the file in GIMP and then export it. Adding this features to Shotwell (using an external editor) was enough of a code change that we broke it into two tickets: one to do the actual work of launching the external editor and another to allow the user to select their editors. In order to break this up, we hardcoded GIMP to complete the first ticket. The first is completed and ready in 0.5.90. The second is under development and should be ready for 0.6: http://trac.yorba.org/ticket/1974 > ? ?- When I insert my SD card I get an error message "Unable to > unmount camera at this time." The Card has been mounted, I just need > to navigate to Cameras on left-hand-side to open the memory card and > import your images. This looks like a gPhoto issue. Essentially, if your SD card is mounted on Nautilus, Shotwell can't access it directly via gPhoto. Shotwell will offer to unmount it, and if it can't, you won't be able to access the SD reader directly from Shotwell. First, I'm curious why Shotwell couldn't unmount the card reader. If you run Shotwell from the command-line with this command: SHOTWELL_LOG=1 shotwell debug information will appear in the console window while you use Shotwell. Could you attempt to unmount the reader and then copy-paste the debug output here (or directly to me)? In the meantime, if the card is mounted under Nautilus, you can import your photos by drag-and-dropping them from a Nautilus window into Shotwell. > ? ?- Another thought when importing images, the option to hide > already imported images could be improved by still showing images > already in your library, but overlaying them with an "X" (as in > Picasa) or by fading them? this way you can still see the images you > already have, but are still clearly differentiated from your new > images. That's an interesting idea. The reason we hide the photos outright is so you can simply Edit -> Select All (or Import All) and import all the images you've not already selected. I've ticketed your idea, however: http://trac.yorba.org/ticket/1996 > ? - Finally; I'm not sure if this is the case, but once the hide > duplicates box is ticked,does this stop these 'hidden' images from > being imported? Yes. Only photos which have been selected will be imported. Even if you select a duplicate photo and attempt to import it, Shotwell will detect it's a duplicate and not add it to the library. -- Jim From jim at yorba.org Tue Jun 1 18:55:24 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 1 Jun 2010 11:55:24 -0700 Subject: [Shotwell] Can't import from Camera in Shotwell trunk In-Reply-To: <1275222352.1542.36.camel@nuuk> References: <1275222352.1542.36.camel@nuuk> Message-ID: That's really odd. Shotwell should in the least display the camera in the sidebar. We should see every camera gPhoto sees, which, from Nautilus, is available. If you connect the camera and launch Shotwell after it appears in Nautilus, do you still not see it? If you launch Shotwell from the command-line like this: SHOTWELL_LOG=1 shotwell debug information will appear in the console. Could you run Shotwell, attach the camera, and then copy-and-paste the log information here (or directly to me)? Thanks. -- Jim On Sun, May 30, 2010 at 5:25 AM, Bruno Girin wrote: > Hi all, > > I just compiled and installed Shotwell from source to start trying to > contribute bug fixes. When I connect my camera (Canon EOS 5D) and select > "Open Shotwell Photo Manager", the camera doesn't appear in Shotwell and > I can't import from it. When I open the folder in Nautilus, it opens > gphoto2://[usb:001,005]/ and I can browse the camera's file system. > > Is there any setting I should use when compiling Shotwell to make this > work or is it a bug? > > Thanks > > Bruno > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue Jun 1 19:07:11 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 1 Jun 2010 12:07:11 -0700 Subject: [Shotwell] Import questions In-Reply-To: <4C003375.1090705@alumni.caltech.edu> References: <4C003375.1090705@alumni.caltech.edu> Message-ID: I think David answered most of your concerns, but I'll add two more things you that are pertinent here. The reason Shotwell didn't create ~/Pictures when it was missing is because of the behavior of the GNOME VDG user directories implementation. If you delete ~/Pictures, the GNOME desktop will internally reset its default pictures location to ~. Shotwell is simply using the value GNOME is reporting to us -- we can't tell if this has happened because you deleted the folder or you intentionally set it to ~. I agree this isn't the best behavior possible; some of this is addressed in the ticket David mentioned (#1075). The question of moving photos and having Shotwell track them is something we're considering for 0.7: http://trac.yorba.org/ticket/374 Although this is listed as auto-import, what we're actually envisioning is Shotwell monitoring the local filesystem and reflecting all changes. -- Jim On Fri, May 28, 2010 at 2:19 PM, Jon Hamkins wrote: > Hi, I'm a long time RH and Fedora user, and first-time shotwell user. > First, let me offer congratulations to the shotwell development team on > a great looking photo organizer -- this will be a really nice tool for > me, once I figure out a few things. > > 1. In importing from a camera card, shotwell ignored the video files on > the camera (telling me so -- good). ?This is understandable for a photo > organizer, but it does make shotwell not such a great default tool for > how I operate. ?I only attach a camera card when I want to dump all data > and erase the card. ?How do others handle this issue of video files not > getting copied to the computer? ?I was thinking of reverting to gthumb > as the default application when a camera card is attached to the > computer (which copies both images and videos), and then importing the > new hard-drive directory into shotwell to take advantage of shotwell's > superior photo organization capabilities. > > 2. ?Incidentally, when I connected a camera and let shotwell import the > pictures, it seems to have created the directory ~/2010 and put the > pictures there. ?Is this the expected behavior when no ~/Pictures/ > directory is present? ?This is, well, weird. ?Shouldn't there be an > option to specify where to copy the images? > > 3. ?Starting over (deleting ~/.shotwell, and creating ~/Pictures), I > imported a directory of pictures already on my hard drive into shotwell, > keeping the checkbox checked for copying files to my "photo library". > But, if I move/rename the original directory of images, shotwell > complains that they are missing, and the extended information indicates > that shotwell is looking for the images in their original location. ?So, > it only seems to have *linked* to the pictures, not copied them to > ~/Pictures (which remained empty). ?In fact, the import seems to behave > the same way whether or not I check the copy checkbox. > > Incidentally, I've read through the shotwell tickets, and I agree with > Adam's comment on #1602, that by default, it is the right thing to link > images already on the hard drive and copy images on a removable drive. > Maybe I'll stick to that approach, and be careful never move/rename > anything in that directory structure. > > ? ? ?----Jon > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue Jun 1 19:13:25 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 1 Jun 2010 12:13:25 -0700 Subject: [Shotwell] Sharpness, BW control, sephia, glow In-Reply-To: References: Message-ID: We also have a ticket for black-and-white control and sepia-tone here: http://trac.yorba.org/ticket/1913 Feature tickets come under review when we begin the development cycle for major releases. 0.6 should ship soon, so preparing for 0.7 would be the next time we consider it. We do want to add these features, the only question is when! Thanks, -- Jim On Tue, Jun 1, 2010 at 5:31 AM, Luka Oman wrote: > Hi! > > Recently I upgraded to Fedora 13 and with it came Shotwell. Before I > used Picasa 3 (beta?) and was disappointed the development stopped. I > give Shotwell a try and was impressed with the responsiveness, ease of > use and quality of the software. However I lack some of the automation > the Picasa has, like sephia and glow filters, BW control and mostly > sharpness. I noticed in trac you have an entry for sharpness control, > but it hasn't been updated for months. Are there any plans for this > feature, that I missed the most? > As said great app, looking forward to see it grow. Keep it powerful and light :) > > Regards; Luka > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Tue Jun 1 19:28:13 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 1 Jun 2010 12:28:13 -0700 Subject: [Shotwell] Bug fixes (Was: Shotwell - Thoughts on work-flow and extensions) In-Reply-To: <1275336193.2979.60.camel@nuuk> References: <4BFA9854.2050109@yorba.org> <1274732635.1591.239.camel@nuuk> <4BFC18E4.40906@yorba.org> <1275220964.1542.30.camel@nuuk> <1275330347.2979.12.camel@nuuk> <1275336193.2979.60.camel@nuuk> Message-ID: > This raises a new question though. If I wanted to contribute > translations (my first language is French), what is the workflow for > that? Thank you very much for volunteering to help translate Shotwell! The workflow for translators is actually very straightforward. Just point your browser to http://www.transifex.net/projects/p/shotwell/c/default/ , the address of the Shotwell project page on Transifex. From there, you can download the current PO file for any language currently supported by Shotwell (to correct or update an existing translation) or grab the most recently generated POT file (to start a new translation). After downloading the file you need, you can use whatever desktop PO editing software you prefer to edit it; POEdit and LoKalize seem to be the two most commonly used PO editing pacakges among Shotwell translators. Then, once you've finished editing and have a new or revised PO file in hand, you can submit it to us on Transifex for review and testing. Once we've reviewed and tested it, we'll commit it to our Subversion repository and your translation should appear in the next release of the Shotwell! Best regards, Lucas From david.velazquez08 at gmail.com Tue Jun 1 20:18:21 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Tue, 1 Jun 2010 16:18:21 -0400 Subject: [Shotwell] Contributing to Yorba/Shotwell In-Reply-To: References: Message-ID: As I have plans to make some progress on this in the next couple of days and would like to be organized from the start I'm wondering what would be the best method of keeping the developers and community informed of progress, and if all goes well submitting the files for inclusion in Shotwell? Also, would the work I'm doing qualify as filling this bugso that efforts are not duplicated? Finally, is it possible for a developer to chime in even if it's just to give this the go ahead. I'd hate to begin work on this if they have other plans. While I won't move fast enough to make into .6 I think it would be awesome if this could be in a .7 release down the line, depending on how far down the line that actually is. Thanks for all the help getting started! From brunogirin at gmail.com Tue Jun 1 20:43:09 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 01 Jun 2010 21:43:09 +0100 Subject: [Shotwell] Can't import from Camera in Shotwell trunk In-Reply-To: References: <1275222352.1542.36.camel@nuuk> Message-ID: <1275424989.5071.8.camel@nuuk> Jim, I attached the camera, got it to open with Nautilus then started Shotwell and here's the log I get: $ SHOTWELL_LOG=1 shotwell [MSG] main.vala:69: Verifying database ... [DBG] DatabaseTables.vala:291: Database schema version 7 created by app version 0.5.90+trunk [DBG] main.vala:172: 0.386891 seconds to Gtk.main() [DBG] CameraTable.vala:222: Detected 1/2 Canon EOS 5D (normal mode) @ usb: [DBG] CameraTable.vala:146: USB ESP: current_camera_count=2 port=usb: [DBG] CameraTable.vala:159: USB ESP: Skipping usb: [DBG] CameraTable.vala:222: Detected 2/2 Canon EOS 5D (normal mode) @ usb:001,003 [DBG] CameraTable.vala:146: USB ESP: current_camera_count=2 port=usb:001,003 [DBG] CameraTable.vala:189: USB ESP: No matching bus/device found for port=usb:001,003 Bruno On Tue, 2010-06-01 at 11:55 -0700, Jim Nelson wrote: > That's really odd. Shotwell should in the least display the camera in > the sidebar. We should see every camera gPhoto sees, which, from > Nautilus, is available. > > If you connect the camera and launch Shotwell after it appears in > Nautilus, do you still not see it? > > If you launch Shotwell from the command-line like this: > > SHOTWELL_LOG=1 shotwell > > debug information will appear in the console. Could you run Shotwell, > attach the camera, and then copy-and-paste the log information here > (or directly to me)? Thanks. > > -- Jim > > On Sun, May 30, 2010 at 5:25 AM, Bruno Girin wrote: > > Hi all, > > > > I just compiled and installed Shotwell from source to start trying to > > contribute bug fixes. When I connect my camera (Canon EOS 5D) and select > > "Open Shotwell Photo Manager", the camera doesn't appear in Shotwell and > > I can't import from it. When I open the folder in Nautilus, it opens > > gphoto2://[usb:001,005]/ and I can browse the camera's file system. > > > > Is there any setting I should use when compiling Shotwell to make this > > work or is it a bug? > > > > Thanks > > > > Bruno > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From jim at yorba.org Tue Jun 1 23:24:15 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 1 Jun 2010 16:24:15 -0700 Subject: [Shotwell] Contributing to Yorba/Shotwell In-Reply-To: References: Message-ID: Hello, Sorry for not chiming in sooner -- took a long weekend off and have been busy catching up today. First, we definitely appreciate all contributions from the community, from code to translations to design work. This is all important to us, and it's this kind of great effort that will only make Shotwell even better. We can do a better job of opening up the project to the community and making it easier for contributors to jump in. I definitely appreciate the willingness you're showing, David -- thanks! We haven't formally decided which direction we want to go with the documentation. We know it should be DocBook or Mallard but no hard decision has been made here as to which one. We'd like to discuss this matter and come to some consensus here before you go *too* deep one direction or another. We're aware that Mallard is what GNOME is pushing today, but we want to weigh all the options before declaring what system we want to roll with. That said, David, I'm excited that you're excited about this project. If you could create an account on our Trac system (http://trac.yorba.org), you can assign #1143 to yourself, to prevent duplication of effort. We all can discuss the particulars of what we're looking for in the help docs here and/or the ticket's comments. Robert Ancell's suggestions are a good start, especially for Mallard-style documentation. Something you can do while we're deciding is to look over our existing help documentation for things you like and don't like; what can be improved; what's missing; and so forth. Whatever system we go with we'll want screenshots to accompany the text. You're free to consider using the ones on our system or your own. The link to the latest docs is: http://trac.yorba.org/wiki/UsingShotwell0.5 Cheers! -- Jim On Tue, Jun 1, 2010 at 1:18 PM, David Velazquez wrote: > As I have plans to make some progress on this in the next couple of days and > would like to be organized from the start I'm wondering what would be the > best method of keeping the developers and community informed of progress, > and if all goes well submitting the files for inclusion in Shotwell? > > Also, would the work I'm doing qualify as filling this > bugso that efforts are not > duplicated? > > Finally, is it possible for a developer to chime in even if it's just to > give this the go ahead. I'd hate to begin work on this if they have other > plans. > > While I won't move fast enough to make into .6 I think it would be awesome > if this could be in a .7 release down the line, depending on how far down > the line that actually is. > > Thanks for all the help getting started! > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From david.velazquez08 at gmail.com Wed Jun 2 03:44:19 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Tue, 1 Jun 2010 23:44:19 -0400 Subject: [Shotwell] Contributing to Yorba/Shotwell In-Reply-To: References: Message-ID: Hey Jim! Hope you had an enjoyable long weekend off. I didn't mean to suggest in my last message here that you were taking too long to reply or anything even close to that. Certainly you're entitled to a few days off a year.. I guess :) I went ahead and assigned #1143 to myself and will post an update to there shortly to describe what I'll be working on in the next few days. Your idea of looking over the existing work for things to improve and that are missing is a good start to this I feel. Never hurts to have a plan. Your call on where to start the talks for the help docs. Here would probably garner a larger response, but I'm indifferent. Starting a new thread might be a good idea though before this one gets unbearably long. Looking forward to hearing your thoughts on the direction we should take. Dave On Tue, Jun 1, 2010 at 7:24 PM, Jim Nelson wrote: > Hello, > > Sorry for not chiming in sooner -- took a long weekend off and have > been busy catching up today. > > First, we definitely appreciate all contributions from the community, > from code to translations to design work. This is all important to > us, and it's this kind of great effort that will only make Shotwell > even better. We can do a better job of opening up the project to the > community and making it easier for contributors to jump in. I > definitely appreciate the willingness you're showing, David -- thanks! > > We haven't formally decided which direction we want to go with the > documentation. We know it should be DocBook or Mallard but no hard > decision has been made here as to which one. We'd like to discuss > this matter and come to some consensus here before you go *too* deep > one direction or another. We're aware that Mallard is what GNOME is > pushing today, but we want to weigh all the options before declaring > what system we want to roll with. > > That said, David, I'm excited that you're excited about this project. > If you could create an account on our Trac system > (http://trac.yorba.org), you can assign #1143 to yourself, to prevent > duplication of effort. We all can discuss the particulars of what > we're looking for in the help docs here and/or the ticket's comments. > Robert Ancell's suggestions are a good start, especially for > Mallard-style documentation. Something you can do while we're > deciding is to look over our existing help documentation for things > you like and don't like; what can be improved; what's missing; and so > forth. Whatever system we go with we'll want screenshots to accompany > the text. You're free to consider using the ones on our system or > your own. The link to the latest docs is: > http://trac.yorba.org/wiki/UsingShotwell0.5 > > Cheers! > > -- Jim > > > > > > On Tue, Jun 1, 2010 at 1:18 PM, David Velazquez > wrote: > > As I have plans to make some progress on this in the next couple of days > and > > would like to be organized from the start I'm wondering what would be the > > best method of keeping the developers and community informed of progress, > > and if all goes well submitting the files for inclusion in Shotwell? > > > > Also, would the work I'm doing qualify as filling this > > bugso that efforts are not > > duplicated? > > > > Finally, is it possible for a developer to chime in even if it's just to > > give this the go ahead. I'd hate to begin work on this if they have other > > plans. > > > > While I won't move fast enough to make into .6 I think it would be > awesome > > if this could be in a .7 release down the line, depending on how far down > > the line that actually is. > > > > Thanks for all the help getting started! > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > From luka at bubi.si Wed Jun 2 07:35:13 2010 From: luka at bubi.si (Luka Oman) Date: Wed, 2 Jun 2010 09:35:13 +0200 Subject: [Shotwell] A couple of questions: save, export Message-ID: Hello again! I read and noticed the Shotwell does not save the changed photos. Is there an easy way of save the changed photos (album, event). Through export? And save them in the same folder as originals? What would happen? I am using 0.5.2 that is shipped with Fedora 13. On export there is a Scaling constants option with pixel size. But If I change the pixel size to for example 600px then the pictures are exported, the changes are visible, but the size is the one of the original. Is this a bug or a feature? :) Although Shotwell looks promising, and I like the attitude of the developers, I still need Picasa on my system. Looking forward to version 0.6 and to see what features will be accepted for 0.7. Regards; Luka From adam at yorba.org Wed Jun 2 22:56:39 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 02 Jun 2010 15:56:39 -0700 Subject: [Shotwell] Slovenian translation for Shotwell In-Reply-To: References: Message-ID: <4C06E1A7.2040201@yorba.org> On 06/01/2010 11:13 PM, Andrej Znidarsic wrote: > I would ask a question about the .pot files, since i have a problem with > some of the strings. In slovenian language we have different plural forms > for 1 object, 2 objects, 3 or 4 objects and 5 and more objects. > > I have a problem with strings like: > One original photo could not be adjusted. / The following original photos > could not be adjusted. > > In slovenian it possible to translate this string in 3 form, but the 4th > form of plural (5 or moje objects) requires a number inside the string > otherwise it doesn't sound right and cannot be translated properly. > > So for the 4 form of plural you can translate it in 2 ways (now obviously it > sounds completely different in slovenian, but just ot show the sentance > form): > > a) The following %d original photos could not be adjusted. > b) It is not possible to adjust the following %d photos. (of course > everything > > Either way, it needs a %d. Is that possible to fix. There are about 10 > strings like that in shotwell. It would be greatly appriciated if you could > fix this for me. > I don't speak Slovenian, but is there really no way to express a plural when there is no number involved? For example, suppose that you were asked to translate this sentence: The dogs ran to the house. Would you really need to know how many dogs there were? What if you didn't? Does the sentence become untranslatable? I do speak Czech, which also uses different cases for different numbers. For example, in Czech 1 pes = 1 dog (nominative case) 2 psi = 2 dogs (nominative plural case) 3 psi = 3 dogs 4 psi = 4 dogs 5 ps? = 5 dogs (genitive plural case) But I need to translate "The dogs ran" without a number, I can simply say "Psi b??eli" using the nominative plural. And, similarly, in our Czech translation of "The following original photos could not be adjusted", the translator used the nominative plural case which is just fine. But if Slovenian is somehow different from the other Slavic languages we've seen so far and we absolutely need to include a number in each string that talks about photos, perhaps we can do that. adam From theirishkiwi at gmail.com Wed Jun 2 23:20:02 2010 From: theirishkiwi at gmail.com (Chris Lindsay) Date: Thu, 3 Jun 2010 00:20:02 +0100 Subject: [Shotwell] Bug: Certain images not being displayed in library even after importing? Message-ID: Hi, I thought this was originally only a minor issue, but I am discovering large numbers of images, both and Raw (CR2) and jpegs which although successfully imported from SD card via Shotwell (ie. are displayed when I browse to folder with Nautilus) and have been added to Shotwell's database (flags images in question as duplicates if I attempt to re-import), are not being displayed in my library of images from within Shotwell? Frustrating! : ) -- Chris From adam at yorba.org Thu Jun 3 00:07:39 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 02 Jun 2010 17:07:39 -0700 Subject: [Shotwell] Bug: Certain images not being displayed in library even after importing? In-Reply-To: References: Message-ID: <4C06F24B.9040306@yorba.org> On 06/02/2010 04:20 PM, Chris Lindsay wrote: > I thought this was originally only a minor issue, but I am discovering > large numbers of images, both and Raw (CR2) and jpegs which although > successfully imported from SD card via Shotwell (ie. are displayed > when I browse to folder with Nautilus) and have been added to > Shotwell's database (flags images in question as duplicates if I > attempt to re-import), are not being displayed in my library of images > from within Shotwell? > Chris, 1. It sounds like you're running a trunk build (since you're able to import RAW files). Are you sure you're up to date with the latest trunk? 2. Are you sure that the images are not in the Shotwell trash, and that View->Only Favorites is unchecked? 3. If the answers to 1 and 2 are yes: Try running "shotwell -d ~/.shotwell2" to run with an alternate library which will initially be empty. Now drag the pictures in question from Nautilus into Shotwell. Do the pictures show up? adam From andrej.znidarsic at gmail.com Thu Jun 3 07:27:45 2010 From: andrej.znidarsic at gmail.com (Andrej Znidarsic) Date: Thu, 3 Jun 2010 09:27:45 +0200 Subject: [Shotwell] Slovenian translation for Shotwell In-Reply-To: <4C06E1A7.2040201@yorba.org> References: <4C06E1A7.2040201@yorba.org> Message-ID: Slovenian has: 1 pes 2 psa 3 psi 4 psi 5 -100 psov 101 pes 102 psa 103 psi 104 psi 105- 200 psov 201 pes etc.. There needs to be a word only before the last form psov, others make sense without a number. However I have figured out a solution which doesn't require numbers. Instead of saying a number I can just say several: several dogs ran to the house or in slovenian : Ve? psov je ?lo v hi?o. This is not a perfect solution as the word ve? can mean both "several" and "more", but it's much much better than nothing. So it's not really necessary to add numbers. I have one question about transifex (this is the first program i am translating through their interface). Does the funcion "watch it" also notifies me of .pot changes or only if someone else updates /po/sl_SI.po ? Andrej Upanje je v na?ih odlo?itvah. 2010/6/3 Adam Dingle > On 06/01/2010 11:13 PM, Andrej Znidarsic wrote: > >> I would ask a question about the .pot files, since i have a problem with >> some of the strings. In slovenian language we have different plural forms >> for 1 object, 2 objects, 3 or 4 objects and 5 and more objects. >> >> I have a problem with strings like: >> One original photo could not be adjusted. / The following original photos >> could not be adjusted. >> >> In slovenian it possible to translate this string in 3 form, but the 4th >> form of plural (5 or moje objects) requires a number inside the string >> otherwise it doesn't sound right and cannot be translated properly. >> >> So for the 4 form of plural you can translate it in 2 ways (now obviously >> it >> sounds completely different in slovenian, but just ot show the sentance >> form): >> >> a) The following %d original photos could not be adjusted. >> b) It is not possible to adjust the following %d photos. (of course >> everything >> >> Either way, it needs a %d. Is that possible to fix. There are about 10 >> strings like that in shotwell. It would be greatly appriciated if you >> could >> fix this for me. >> >> > > I don't speak Slovenian, but is there really no way to express a plural > when there is no number involved? For example, suppose that you were asked > to translate this sentence: > > The dogs ran to the house. > > Would you really need to know how many dogs there were? What if you > didn't? Does the sentence become untranslatable? > > I do speak Czech, which also uses different cases for different numbers. > For example, in Czech > > 1 pes = 1 dog (nominative case) > 2 psi = 2 dogs (nominative plural case) > 3 psi = 3 dogs > 4 psi = 4 dogs > 5 ps? = 5 dogs (genitive plural case) > > But I need to translate "The dogs ran" without a number, I can simply say > "Psi b??eli" using the nominative plural. And, similarly, in our Czech > translation of "The following original photos could not be adjusted", the > translator used the nominative plural case which is just fine. > > But if Slovenian is somehow different from the other Slavic languages we've > seen so far and we absolutely need to include a number in each string that > talks about photos, perhaps we can do that. > > adam > > From theirishkiwi at gmail.com Thu Jun 3 10:25:07 2010 From: theirishkiwi at gmail.com (Chris Lindsay) Date: Thu, 3 Jun 2010 11:25:07 +0100 Subject: [Shotwell] Bug: Certain images not being displayed in library even after importing? Message-ID: On 06/02/2010 04:20 PM, Chris Lindsay wrote: > I thought this was originally only a minor issue, but I am discovering > large numbers of images, both and Raw (CR2) and jpegs which although > successfully imported from SD card via Shotwell (ie. are displayed > when I browse to folder with Nautilus) and have been added to > Shotwell's database (flags images in question as duplicates if I > attempt to re-import), are not being displayed in my library of images > from within Shotwell? > >Chris, >1. It sounds like you're running a trunk build (since you're able to >import RAW files). Are you sure you're up to date with the latest trunk? Yes I am running a trunk build and keep upto date with the latest builds. >2. Are you sure that the images are not in the Shotwell trash, and that >View->Only Favorites is unchecked? Yes, double checked both. >3. If the answers to 1 and 2 are yes: Try running "shotwell -d >~/.shotwell2" to run with an alternate library which will initially be >empty. Now drag the pictures in question from Nautilus into Shotwell. >Do the pictures show up? >adam Yes the pictures show up. I guess then next test to to import the rest of my library again and see if Shotwell displays all the images. Chris From adam at yorba.org Thu Jun 3 14:09:56 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 03 Jun 2010 07:09:56 -0700 Subject: [Shotwell] A couple of questions: save, export In-Reply-To: References: Message-ID: <4C07B7B4.6040003@yorba.org> On 06/02/2010 12:35 AM, Luka Oman wrote: > Hello again! > > I read and noticed the Shotwell does not save the changed photos. Is > there an easy way of save the changed photos (album, event). Through > export? And save them in the same folder as originals? What would > happen? Yes - in Shotwell today, if you want to save modified photos you need to use File->Export to export them to a different directory. You shouldn't overwrite the originals with your modified files, because Shotwell uses those originals as a starting point for applying transformations. For example, suppose that you've applied a 10% saturation boost to a photo. If you export that photo and overwrite the original, then the original will now contain a 10% saturation boost but Shotwell will still apply a 10% saturation boost whenever it displays the photo, so you'll end up with a 20% saturation increase. Some users, however, would like to be able to save changes to original files in place and have everything work correctly. This is http://trac.yorba.org/ticket/1933 . We're considering implementing this in some form for 0.7 or a following release. > I am using 0.5.2 that is shipped with Fedora 13. On export > there is a Scaling constants option with pixel size. But If I change > the pixel size to for example 600px then the pictures are exported, > the changes are visible, but the size is the one of the original. Is > this a bug or a feature? :) It sounds like you've run into bug 1817 (http://trac.yorba.org/ticket/1817), which has been fixed in the trunk. The fix will be present in the upcoming 0.6 release. > Although Shotwell looks promising, and I > like the attitude of the developers, I still need Picasa on my system. > Looking forward to version 0.6 and to see what features will be > accepted for 0.7. > Thanks! I hope we can evolve Shotwell to be a viable replacement for Picasa for you at some point. adam From adam at yorba.org Thu Jun 3 17:36:40 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 03 Jun 2010 10:36:40 -0700 Subject: [Shotwell] Import questions In-Reply-To: <4C003375.1090705@alumni.caltech.edu> References: <4C003375.1090705@alumni.caltech.edu> Message-ID: <4C07E828.3060007@yorba.org> On 05/28/2010 02:19 PM, Jon Hamkins wrote: > 2. Incidentally, when I connected a camera and let shotwell import the > pictures, it seems to have created the directory ~/2010 and put the > pictures there. Is this the expected behavior when no ~/Pictures/ > directory is present? This is, well, weird. Shouldn't there be an > option to specify where to copy the images? > > 3. Starting over (deleting ~/.shotwell, and creating ~/Pictures), I > imported a directory of pictures already on my hard drive into shotwell, > keeping the checkbox checked for copying files to my "photo library". > But, if I move/rename the original directory of images, shotwell > complains that they are missing, and the extended information indicates > that shotwell is looking for the images in their original location. So, > it only seems to have *linked* to the pictures, not copied them to > ~/Pictures (which remained empty). In fact, the import seems to behave > the same way whether or not I check the copy checkbox. > I'd like to explain a little more thoroughly what presumably happened here. As Jim explained in his previous message, if you delete ~/Pictures then the GNOME desktop may reset the XDG Pictures directory to be ~. More specifically, if you delete ~/Pictures and then log out and log back in again, then the XDG Pictures directory (which appears in ~/.config/user-dirs.dirs) will be reset to ~ (at least on Ubuntu 10.04, but probably on other distros as well). If that happens, then Shotwell will believe that the library directory is your home directory, which is not a good state to be in: as you saw it will create directories such as ~/2010. Furthermore, the checkbox for copying files to your photo library will have no effect because Shotwell will believe that all imported file are *already* in the photo library, so it will decline to copy them. It might be nice if Shotwell would warn the user if the library directory is ~ and suggest that the user set it to something else (which is now easy to do, since the trunk build lets the user specify the library directory in the Preferences dialog). I've created a ticket for this at http://trac.yorba.org/ticket/2031 . adam From adam at yorba.org Thu Jun 3 17:42:04 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 03 Jun 2010 10:42:04 -0700 Subject: [Shotwell] Bug: Certain images not being displayed in library even after importing? In-Reply-To: References: Message-ID: <4C07E96C.6020005@yorba.org> On 06/03/2010 03:25 AM, Chris Lindsay wrote: > >> 3. If the answers to 1 and 2 are yes: Try running "shotwell -d >> ~/.shotwell2" to run with an alternate library which will initially be >> empty. Now drag the pictures in question from Nautilus into Shotwell. >> Do the pictures show up? >> > Yes the pictures show up. I guess then next test to to import the rest > of my library again and see if Shotwell displays all the images. > That would make sense. If you can track this down to a reproducible case where you start with an empty library, import some images and some of them don't show up then we'd be very interested in investigating at that point. adam From david.velazquez08 at gmail.com Fri Jun 4 05:18:48 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 01:18:48 -0400 Subject: [Shotwell] Building shotwell from trunk Message-ID: I'm confident I'm doing something simple wrong, somewhere, but I can't seem to build shotwell from trunk in Lucid Right now it's saying that it can't find gexiv2 and suggesting I change the PKG_CONFIG_PATH. I understand gexiv2 needed to be built from scratch as well so I pulled it and compiled it in ~/shotwell/gexiv2 using: ./configure --prefix=/home/dave/shotwell/gexiv2 make make install The only error I get from gexiv2 occurs during make install and is this: /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied make: [install] Error 1 (ignored) I assume this is due to me not using sudo and it not being able to write to /etc/ld.so.cache Is this enough to prevent gexiv2 from building properly and therefore shotwell from using it? Shotwell itself is being built (or attempting to be built) in ~/shotwell using the command ./configure --prefix=/home/dave/shotwell The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) were installed from Ubuntu's repositories. I've tried moving the installation for gexiv2 to someplace outside of ~/shotwell to no avail. I'd appreciate any help. Dave From mahfiaz at gmail.com Fri Jun 4 05:37:12 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Fri, 04 Jun 2010 08:37:12 +0300 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: Message-ID: <1275629833.8324.9.camel@antiloop> To build you need header files, which are in *-dev packages. Install libexiv2-dev and see if this makes shotwell compile (or complain about another dependency). If you hit another dependency apt-get search exiv (or whatever it complains about) and install corresponding package. All dependencies for the version in repository can be installed with apt-get build-dep packagename http://yorba.org/shotwell/install/ Mattias ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David Velazquez: > I'm confident I'm doing something simple wrong, somewhere, but I can't seem > to build shotwell from trunk in Lucid > > Right now it's saying that it can't find gexiv2 and suggesting I change the > PKG_CONFIG_PATH. > > I understand gexiv2 needed to be built from scratch as well so I pulled it > and compiled it in ~/shotwell/gexiv2 using: > > ./configure --prefix=/home/dave/shotwell/gexiv2 > make > make install > > The only error I get from gexiv2 occurs during make install and is this: > > /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: > Permission denied > make: [install] Error 1 (ignored) > > I assume this is due to me not using sudo and it not being able to write to > /etc/ld.so.cache > Is this enough to prevent gexiv2 from building properly and therefore > shotwell from using it? > > > Shotwell itself is being built (or attempting to be built) in ~/shotwell > using the command ./configure --prefix=/home/dave/shotwell > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) were installed > from Ubuntu's repositories. > > I've tried moving the installation for gexiv2 to someplace outside of > ~/shotwell to no avail. > > I'd appreciate any help. > > Dave > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From david.velazquez08 at gmail.com Fri Jun 4 06:11:55 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 02:11:55 -0400 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275629833.8324.9.camel@antiloop> References: <1275629833.8324.9.camel@antiloop> Message-ID: Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. Try as I might I can't seem to get shotwell to complain about anything other than gexiv2 which, according to the output, should have been compiled properly. The only thing apt-get build-dep shotwell wants to install is libhal-dev which is no longer needed when building from trunk. I have libgudev which replaces it though. Thanks for the tips. On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru wrote: > To build you need header files, which are in *-dev packages. Install > libexiv2-dev and see if this makes shotwell compile (or complain about > another dependency). > If you hit another dependency apt-get search exiv (or whatever it > complains about) and install corresponding package. > > All dependencies for the version in repository can be installed with > apt-get build-dep packagename > > http://yorba.org/shotwell/install/ > > > Mattias > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David Velazquez: > > I'm confident I'm doing something simple wrong, somewhere, but I can't > seem > > to build shotwell from trunk in Lucid > > > > Right now it's saying that it can't find gexiv2 and suggesting I change > the > > PKG_CONFIG_PATH. > > > > I understand gexiv2 needed to be built from scratch as well so I pulled > it > > and compiled it in ~/shotwell/gexiv2 using: > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > make > > make install > > > > The only error I get from gexiv2 occurs during make install and is this: > > > > /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: > > Permission denied > > make: [install] Error 1 (ignored) > > > > I assume this is due to me not using sudo and it not being able to write > to > > /etc/ld.so.cache > > Is this enough to prevent gexiv2 from building properly and therefore > > shotwell from using it? > > > > > > Shotwell itself is being built (or attempting to be built) in ~/shotwell > > using the command ./configure --prefix=/home/dave/shotwell > > > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) were installed > > from Ubuntu's repositories. > > > > I've tried moving the installation for gexiv2 to someplace outside of > > ~/shotwell to no avail. > > > > I'd appreciate any help. > > > > Dave > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > From mahfiaz at gmail.com Fri Jun 4 08:44:11 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Fri, 04 Jun 2010 11:44:11 +0300 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> Message-ID: <1275641051.18379.4.camel@antiloop> Sorry, I was wrong here, as I did not read your letter thoroughly. You definitely need to run make install with sudo, since it has to install to system directories, where user cannot write to. Actually in the install instructions there is written "# make install", where # refers to a command which needs to be run as root (or with sudo), as opposed to $ which refers to a ordinary user. Mattias ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David Velazquez: > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. Try > as I might I can't seem to get shotwell to complain about anything > other than gexiv2 which, according to the output, should have been > compiled properly. > > The only thing apt-get build-dep shotwell wants to install is > libhal-dev which is no longer needed when building from trunk. I have > libgudev which replaces it though. > > Thanks for the tips. > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru > wrote: > To build you need header files, which are in *-dev packages. > Install > libexiv2-dev and see if this makes shotwell compile (or > complain about > another dependency). > If you hit another dependency apt-get search exiv (or whatever > it > complains about) and install corresponding package. > > All dependencies for the version in repository can be > installed with > apt-get build-dep packagename > > http://yorba.org/shotwell/install/ > > > Mattias > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David > Velazquez: > > > I'm confident I'm doing something simple wrong, somewhere, > but I can't seem > > to build shotwell from trunk in Lucid > > > > Right now it's saying that it can't find gexiv2 and > suggesting I change the > > PKG_CONFIG_PATH. > > > > I understand gexiv2 needed to be built from scratch as well > so I pulled it > > and compiled it in ~/shotwell/gexiv2 using: > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > make > > make install > > > > The only error I get from gexiv2 occurs during make install > and is this: > > > > /sbin/ldconfig.real: Can't create temporary cache > file /etc/ld.so.cache~: > > Permission denied > > make: [install] Error 1 (ignored) > > > > I assume this is due to me not using sudo and it not being > able to write to > > /etc/ld.so.cache > > Is this enough to prevent gexiv2 from building properly and > therefore > > shotwell from using it? > > > > > > Shotwell itself is being built (or attempting to be built) > in ~/shotwell > > using the command ./configure --prefix=/home/dave/shotwell > > > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) > were installed > > from Ubuntu's repositories. > > > > I've tried moving the installation for gexiv2 to someplace > outside of > > ~/shotwell to no avail. > > > > I'd appreciate any help. > > > > Dave > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > From brunogirin at gmail.com Fri Jun 4 11:24:24 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 04 Jun 2010 12:24:24 +0100 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275641051.18379.4.camel@antiloop> References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> Message-ID: <1275650664.1856.3.camel@nuuk> David, As Mattias pointed out, you need to be root to run make install, so on Ubuntu, you would do: $ make $ sudo make install Everything is installed in /usr/local so is completely separate from what is installed through apt-get or Synaptic. I've got it working fine on my Lucid laptop. Bruno On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > Sorry, I was wrong here, as I did not read your letter thoroughly. > > You definitely need to run make install with sudo, since it has to > install to system directories, where user cannot write to. > > Actually in the install instructions there is written "# make install", > where # refers to a command which needs to be run as root (or with > sudo), as opposed to $ which refers to a ordinary user. > > > Mattias > > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David Velazquez: > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. Try > > as I might I can't seem to get shotwell to complain about anything > > other than gexiv2 which, according to the output, should have been > > compiled properly. > > > > The only thing apt-get build-dep shotwell wants to install is > > libhal-dev which is no longer needed when building from trunk. I have > > libgudev which replaces it though. > > > > Thanks for the tips. > > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru > > wrote: > > To build you need header files, which are in *-dev packages. > > Install > > libexiv2-dev and see if this makes shotwell compile (or > > complain about > > another dependency). > > If you hit another dependency apt-get search exiv (or whatever > > it > > complains about) and install corresponding package. > > > > All dependencies for the version in repository can be > > installed with > > apt-get build-dep packagename > > > > http://yorba.org/shotwell/install/ > > > > > > Mattias > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David > > Velazquez: > > > > > I'm confident I'm doing something simple wrong, somewhere, > > but I can't seem > > > to build shotwell from trunk in Lucid > > > > > > Right now it's saying that it can't find gexiv2 and > > suggesting I change the > > > PKG_CONFIG_PATH. > > > > > > I understand gexiv2 needed to be built from scratch as well > > so I pulled it > > > and compiled it in ~/shotwell/gexiv2 using: > > > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > > make > > > make install > > > > > > The only error I get from gexiv2 occurs during make install > > and is this: > > > > > > /sbin/ldconfig.real: Can't create temporary cache > > file /etc/ld.so.cache~: > > > Permission denied > > > make: [install] Error 1 (ignored) > > > > > > I assume this is due to me not using sudo and it not being > > able to write to > > > /etc/ld.so.cache > > > Is this enough to prevent gexiv2 from building properly and > > therefore > > > shotwell from using it? > > > > > > > > > Shotwell itself is being built (or attempting to be built) > > in ~/shotwell > > > using the command ./configure --prefix=/home/dave/shotwell > > > > > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) > > were installed > > > from Ubuntu's repositories. > > > > > > I've tried moving the installation for gexiv2 to someplace > > outside of > > > ~/shotwell to no avail. > > > > > > I'd appreciate any help. > > > > > > Dave > > > > > _______________________________________________ > > > 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 bengt at thuree.com Fri Jun 4 14:32:21 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sat, 05 Jun 2010 00:32:21 +1000 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275650664.1856.3.camel@nuuk> References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> Message-ID: <1275661941.2894.0.camel@lappis> Or specify the prefix parameter and install in ~/unstable/shotwell .... On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > David, > > As Mattias pointed out, you need to be root to run make install, so on > Ubuntu, you would do: > > $ make > $ sudo make install > > Everything is installed in /usr/local so is completely separate from > what is installed through apt-get or Synaptic. I've got it working fine > on my Lucid laptop. > > Bruno > > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > Sorry, I was wrong here, as I did not read your letter thoroughly. > > > > You definitely need to run make install with sudo, since it has to > > install to system directories, where user cannot write to. > > > > Actually in the install instructions there is written "# make install", > > where # refers to a command which needs to be run as root (or with > > sudo), as opposed to $ which refers to a ordinary user. > > > > > > Mattias > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David Velazquez: > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. Try > > > as I might I can't seem to get shotwell to complain about anything > > > other than gexiv2 which, according to the output, should have been > > > compiled properly. > > > > > > The only thing apt-get build-dep shotwell wants to install is > > > libhal-dev which is no longer needed when building from trunk. I have > > > libgudev which replaces it though. > > > > > > Thanks for the tips. > > > > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru > > > wrote: > > > To build you need header files, which are in *-dev packages. > > > Install > > > libexiv2-dev and see if this makes shotwell compile (or > > > complain about > > > another dependency). > > > If you hit another dependency apt-get search exiv (or whatever > > > it > > > complains about) and install corresponding package. > > > > > > All dependencies for the version in repository can be > > > installed with > > > apt-get build-dep packagename > > > > > > http://yorba.org/shotwell/install/ > > > > > > > > > Mattias > > > > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David > > > Velazquez: > > > > > > > I'm confident I'm doing something simple wrong, somewhere, > > > but I can't seem > > > > to build shotwell from trunk in Lucid > > > > > > > > Right now it's saying that it can't find gexiv2 and > > > suggesting I change the > > > > PKG_CONFIG_PATH. > > > > > > > > I understand gexiv2 needed to be built from scratch as well > > > so I pulled it > > > > and compiled it in ~/shotwell/gexiv2 using: > > > > > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > > > make > > > > make install > > > > > > > > The only error I get from gexiv2 occurs during make install > > > and is this: > > > > > > > > /sbin/ldconfig.real: Can't create temporary cache > > > file /etc/ld.so.cache~: > > > > Permission denied > > > > make: [install] Error 1 (ignored) > > > > > > > > I assume this is due to me not using sudo and it not being > > > able to write to > > > > /etc/ld.so.cache > > > > Is this enough to prevent gexiv2 from building properly and > > > therefore > > > > shotwell from using it? > > > > > > > > > > > > Shotwell itself is being built (or attempting to be built) > > > in ~/shotwell > > > > using the command ./configure --prefix=/home/dave/shotwell > > > > > > > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) > > > were installed > > > > from Ubuntu's repositories. > > > > > > > > I've tried moving the installation for gexiv2 to someplace > > > outside of > > > > ~/shotwell to no avail. > > > > > > > > I'd appreciate any help. > > > > > > > > Dave > > > > > > > _______________________________________________ > > > > 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 david.velazquez08 at gmail.com Fri Jun 4 17:57:03 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 13:57:03 -0400 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275661941.2894.0.camel@lappis> References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: Thanks for the tips but I did not want to install shotwell to the system directories. Call it stubbornness :) Is there anyway to install it locally like Bengt suggested, in ~/unstable/shotwell I thought I had been specifying the prefix in ./configure which is why I attempted to run make install without sudo. Does make accept the prefix parameter like ./configure does? There must be a way to install without sudo here. I've done it for programs like deluge in the past which normally require root powers to install. On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree wrote: > Or specify the prefix parameter and install in ~/unstable/shotwell .... > > On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > David, > > > > As Mattias pointed out, you need to be root to run make install, so on > > Ubuntu, you would do: > > > > $ make > > $ sudo make install > > > > Everything is installed in /usr/local so is completely separate from > > what is installed through apt-get or Synaptic. I've got it working fine > > on my Lucid laptop. > > > > Bruno > > > > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > > Sorry, I was wrong here, as I did not read your letter thoroughly. > > > > > > You definitely need to run make install with sudo, since it has to > > > install to system directories, where user cannot write to. > > > > > > Actually in the install instructions there is written "# make install", > > > where # refers to a command which needs to be run as root (or with > > > sudo), as opposed to $ which refers to a ordinary user. > > > > > > > > > Mattias > > > > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David Velazquez: > > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. > Try > > > > as I might I can't seem to get shotwell to complain about anything > > > > other than gexiv2 which, according to the output, should have been > > > > compiled properly. > > > > > > > > The only thing apt-get build-dep shotwell wants to install is > > > > libhal-dev which is no longer needed when building from trunk. I have > > > > libgudev which replaces it though. > > > > > > > > Thanks for the tips. > > > > > > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru > > > > wrote: > > > > To build you need header files, which are in *-dev packages. > > > > Install > > > > libexiv2-dev and see if this makes shotwell compile (or > > > > complain about > > > > another dependency). > > > > If you hit another dependency apt-get search exiv (or > whatever > > > > it > > > > complains about) and install corresponding package. > > > > > > > > All dependencies for the version in repository can be > > > > installed with > > > > apt-get build-dep packagename > > > > > > > > http://yorba.org/shotwell/install/ > > > > > > > > > > > > Mattias > > > > > > > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David > > > > Velazquez: > > > > > > > > > I'm confident I'm doing something simple wrong, somewhere, > > > > but I can't seem > > > > > to build shotwell from trunk in Lucid > > > > > > > > > > Right now it's saying that it can't find gexiv2 and > > > > suggesting I change the > > > > > PKG_CONFIG_PATH. > > > > > > > > > > I understand gexiv2 needed to be built from scratch as well > > > > so I pulled it > > > > > and compiled it in ~/shotwell/gexiv2 using: > > > > > > > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > > > > make > > > > > make install > > > > > > > > > > The only error I get from gexiv2 occurs during make install > > > > and is this: > > > > > > > > > > /sbin/ldconfig.real: Can't create temporary cache > > > > file /etc/ld.so.cache~: > > > > > Permission denied > > > > > make: [install] Error 1 (ignored) > > > > > > > > > > I assume this is due to me not using sudo and it not being > > > > able to write to > > > > > /etc/ld.so.cache > > > > > Is this enough to prevent gexiv2 from building properly and > > > > therefore > > > > > shotwell from using it? > > > > > > > > > > > > > > > Shotwell itself is being built (or attempting to be built) > > > > in ~/shotwell > > > > > using the command ./configure --prefix=/home/dave/shotwell > > > > > > > > > > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) > > > > were installed > > > > > from Ubuntu's repositories. > > > > > > > > > > I've tried moving the installation for gexiv2 to someplace > > > > outside of > > > > > ~/shotwell to no avail. > > > > > > > > > > I'd appreciate any help. > > > > > > > > > > Dave > > > > > > > > > _______________________________________________ > > > > > 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 > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From brunogirin at gmail.com Fri Jun 4 18:42:58 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 04 Jun 2010 19:42:58 +0100 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: <1275676978.1856.84.camel@nuuk> On Fri, 2010-06-04 at 13:57 -0400, David Velazquez wrote: > Thanks for the tips but I did not want to install shotwell to the > system directories. Call it stubbornness :) Is there anyway to > install it locally like Bengt suggested, in ~/unstable/shotwell > > I thought I had been specifying the prefix in ./configure which is why > I attempted to run make install without sudo. Does make accept the > prefix parameter like ./configure does? Just do this: $ ./configure --prefix=$HOME/unstable/shotwell $ make $ make install The configure script will update the prefix used by make install and should allow you to install to the directory you want. The reason why it wouldn't fully work as expected when doing make install with gexiv2 is that it calls ldconfig at the end, which requires root permissions. It's not a major problem but you then need to tell shotwell where to find the library when compiling it, as they won't be in any standard directory recognised by ld.so. I'm not sure how you'd do that, maybe by providing a custom CFLAG variable to the shotwell configure script. Also note that if you leave the default, it will install to /usr/local, which is away from the system directories (where everything is installed in /usr). Bruno > > There must be a way to install without sudo here. I've done it for > programs like deluge in the past which normally require root powers to > install. > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree > wrote: > Or specify the prefix parameter and install in > ~/unstable/shotwell .... > > > On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > David, > > > > As Mattias pointed out, you need to be root to run make > install, so on > > Ubuntu, you would do: > > > > $ make > > $ sudo make install > > > > Everything is installed in /usr/local so is completely > separate from > > what is installed through apt-get or Synaptic. I've got it > working fine > > on my Lucid laptop. > > > > Bruno > > > > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > > Sorry, I was wrong here, as I did not read your letter > thoroughly. > > > > > > You definitely need to run make install with sudo, since > it has to > > > install to system directories, where user cannot write to. > > > > > > Actually in the install instructions there is written "# > make install", > > > where # refers to a command which needs to be run as root > (or with > > > sudo), as opposed to $ which refers to a ordinary user. > > > > > > > > > Mattias > > > > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas > David Velazquez: > > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already > installed. Try > > > > as I might I can't seem to get shotwell to complain > about anything > > > > other than gexiv2 which, according to the output, should > have been > > > > compiled properly. > > > > > > > > The only thing apt-get build-dep shotwell wants to > install is > > > > libhal-dev which is no longer needed when building from > trunk. I have > > > > libgudev which replaces it though. > > > > > > > > Thanks for the tips. > > > > > > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru > > > > > wrote: > > > > To build you need header files, which are in > *-dev packages. > > > > Install > > > > libexiv2-dev and see if this makes shotwell > compile (or > > > > complain about > > > > another dependency). > > > > If you hit another dependency apt-get search > exiv (or whatever > > > > it > > > > complains about) and install corresponding > package. > > > > > > > > All dependencies for the version in repository > can be > > > > installed with > > > > apt-get build-dep packagename > > > > > > > > http://yorba.org/shotwell/install/ > > > > > > > > > > > > Mattias > > > > > > > > > > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, > kirjutas David > > > > Velazquez: > > > > > > > > > I'm confident I'm doing something simple > wrong, somewhere, > > > > but I can't seem > > > > > to build shotwell from trunk in Lucid > > > > > > > > > > Right now it's saying that it can't find > gexiv2 and > > > > suggesting I change the > > > > > PKG_CONFIG_PATH. > > > > > > > > > > I understand gexiv2 needed to be built from > scratch as well > > > > so I pulled it > > > > > and compiled it in ~/shotwell/gexiv2 using: > > > > > > > > > > ./configure > --prefix=/home/dave/shotwell/gexiv2 > > > > > make > > > > > make install > > > > > > > > > > The only error I get from gexiv2 occurs during > make install > > > > and is this: > > > > > > > > > > /sbin/ldconfig.real: Can't create temporary > cache > > > > file /etc/ld.so.cache~: > > > > > Permission denied > > > > > make: [install] Error 1 (ignored) > > > > > > > > > > I assume this is due to me not using sudo and > it not being > > > > able to write to > > > > > /etc/ld.so.cache > > > > > Is this enough to prevent gexiv2 from building > properly and > > > > therefore > > > > > shotwell from using it? > > > > > > > > > > > > > > > Shotwell itself is being built (or attempting > to be built) > > > > in ~/shotwell > > > > > using the command ./configure > --prefix=/home/dave/shotwell > > > > > > > > > > The dependencies for gexiv2 > (exiv2,libexiv2,libexiv2-dev) > > > > were installed > > > > > from Ubuntu's repositories. > > > > > > > > > > I've tried moving the installation for gexiv2 > to someplace > > > > outside of > > > > > ~/shotwell to no avail. > > > > > > > > > > I'd appreciate any help. > > > > > > > > > > Dave > > > > > > > > > > _______________________________________________ > > > > > 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 > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From jim at yorba.org Fri Jun 4 18:46:15 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 4 Jun 2010 11:46:15 -0700 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: So, PREFIX is used to declare the base directory for a whole host of files being installed. Thus, with your prefix, the following files will be installed as follows: /home/dave/shotwell/gexiv2/lib/libgexiv2.la /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi I see two immediate problems here. First, because gexiv2.pc is stored in a non-standard location, pkg-config can't find it. Shotwell's Makefile relies on pkg-config locating gexiv2 to (a) verify gexiv2 is installed and (b) to get necessary gcc flags for building Shotwell with gexiv2. This is what the PKG_CONFIG_PATH message is telling you. Second, the VAPI file is also in a non-standard location. valac needs to be told of this additional VAPI directory. I don't know of any environment variable that can be used to direct valac to this directory, you have to specify it on the command-line with --vapidir. Shotwell's Makefile currently doesn't allow you to specify that with the configure script ... if this is important, I'll let you ticket this. You can modify Shotwell's Makefile directly in the interim. I would point out that unlike deluge, gexiv2 is a library, not a program, and therefore must be locatable for programs to build and execute. -- Jim On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez wrote: > Thanks for the tips but I did not want to install shotwell to the system > directories. Call it stubbornness :) ?Is there anyway to install it locally > like Bengt suggested, in ~/unstable/shotwell > > I thought I had been specifying the prefix in ./configure which is why I > attempted to run make install without sudo. Does make accept the prefix > parameter like ./configure does? > > There must be a way to install without sudo here. I've done it for programs > like deluge in the past which normally require root powers to install. > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree wrote: > >> Or specify the prefix parameter and install in ~/unstable/shotwell .... >> >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: >> > David, >> > >> > As Mattias pointed out, you need to be root to run make install, so on >> > Ubuntu, you would do: >> > >> > $ make >> > $ sudo make install >> > >> > Everything is installed in /usr/local so is completely separate from >> > what is installed through apt-get or Synaptic. I've got it working fine >> > on my Lucid laptop. >> > >> > Bruno >> > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: >> > > Sorry, I was wrong here, as I did not read your letter thoroughly. >> > > >> > > You definitely need to run make install with sudo, since it has to >> > > install to system directories, where user cannot write to. >> > > >> > > Actually in the install instructions there is written "# make install", >> > > where # refers to a command which needs to be run as root (or with >> > > sudo), as opposed to $ which refers to a ordinary user. >> > > >> > > >> > > Mattias >> > > >> > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David Velazquez: >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. >> Try >> > > > as I might I can't seem to get shotwell to complain about anything >> > > > other than gexiv2 which, according to the output, should have been >> > > > compiled properly. >> > > > >> > > > The only thing apt-get build-dep shotwell wants to install is >> > > > libhal-dev which is no longer needed when building from trunk. I have >> > > > libgudev which replaces it though. >> > > > >> > > > Thanks for the tips. >> > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru >> > > > wrote: >> > > > ? ? ? ? To build you need header files, which are in *-dev packages. >> > > > ? ? ? ? Install >> > > > ? ? ? ? libexiv2-dev and see if this makes shotwell compile (or >> > > > ? ? ? ? complain about >> > > > ? ? ? ? another dependency). >> > > > ? ? ? ? If you hit another dependency apt-get search exiv (or >> whatever >> > > > ? ? ? ? it >> > > > ? ? ? ? complains about) and install corresponding package. >> > > > >> > > > ? ? ? ? All dependencies for the version in repository can be >> > > > ? ? ? ? installed with >> > > > ? ? ? ? apt-get build-dep packagename >> > > > >> > > > ? ? ? ? http://yorba.org/shotwell/install/ >> > > > >> > > > >> > > > ? ? ? ? Mattias >> > > > >> > > > >> > > > ? ? ? ? ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas David >> > > > ? ? ? ? Velazquez: >> > > > >> > > > ? ? ? ? > I'm confident I'm doing something simple wrong, somewhere, >> > > > ? ? ? ? but I can't seem >> > > > ? ? ? ? > to build shotwell from trunk in Lucid >> > > > ? ? ? ? > >> > > > ? ? ? ? > Right now it's saying that it can't find gexiv2 and >> > > > ? ? ? ? suggesting I change the >> > > > ? ? ? ? > PKG_CONFIG_PATH. >> > > > ? ? ? ? > >> > > > ? ? ? ? > I understand gexiv2 needed to be built from scratch as well >> > > > ? ? ? ? so I pulled it >> > > > ? ? ? ? > and compiled it in ~/shotwell/gexiv2 using: >> > > > ? ? ? ? > >> > > > ? ? ? ? > ?./configure --prefix=/home/dave/shotwell/gexiv2 >> > > > ? ? ? ? > make >> > > > ? ? ? ? > make install >> > > > ? ? ? ? > >> > > > ? ? ? ? > The only error I get from gexiv2 occurs during make install >> > > > ? ? ? ? and is this: >> > > > ? ? ? ? > >> > > > ? ? ? ? > /sbin/ldconfig.real: Can't create temporary cache >> > > > ? ? ? ? file /etc/ld.so.cache~: >> > > > ? ? ? ? > Permission denied >> > > > ? ? ? ? > make: [install] Error 1 (ignored) >> > > > ? ? ? ? > >> > > > ? ? ? ? > I assume this is due to me not using sudo and it not being >> > > > ? ? ? ? able to write to >> > > > ? ? ? ? > /etc/ld.so.cache >> > > > ? ? ? ? > Is this enough to prevent gexiv2 from building properly and >> > > > ? ? ? ? therefore >> > > > ? ? ? ? > shotwell from using it? >> > > > ? ? ? ? > >> > > > ? ? ? ? > >> > > > ? ? ? ? > Shotwell itself is being built (or attempting to be built) >> > > > ? ? ? ? in ~/shotwell >> > > > ? ? ? ? > using the command ./configure --prefix=/home/dave/shotwell >> > > > ? ? ? ? > >> > > > ? ? ? ? > The dependencies for gexiv2 (exiv2,libexiv2,libexiv2-dev) >> > > > ? ? ? ? were installed >> > > > ? ? ? ? > from Ubuntu's repositories. >> > > > ? ? ? ? > >> > > > ? ? ? ? > I've tried moving the installation for gexiv2 to someplace >> > > > ? ? ? ? outside of >> > > > ? ? ? ? > ~/shotwell to no avail. >> > > > ? ? ? ? > >> > > > ? ? ? ? > I'd appreciate any help. >> > > > ? ? ? ? > >> > > > ? ? ? ? > Dave >> > > > >> > > > ? ? ? ? > _______________________________________________ >> > > > ? ? ? ? > 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 >> >> >> _______________________________________________ >> 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 david.velazquez08 at gmail.com Fri Jun 4 19:13:05 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 15:13:05 -0400 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: Thanks Bruno, Jim, this clears some things up for me. I went ahead and used my sudo powers to install gexiv2 which Shotwell promptly found. Inevitably shotwell failed at finding libraw, but that was my own doing ;). It seems I may have to compile that to. >From the conversation we've been having it appears to me that Shotwell is not capable of installing to a local directory unless it's dependencies, gexiv2 (amongst others) are installed in the standard locations where pkg-config would look for them. I'm sure it's more complicated than that, but hopefully I got the gist of it. I bet the majority of users have no problems with this since most of them will use a binary deb file (for instance), the PPA, or the release in their distro of choice. In the case of someone with no root or sudo powers who wants to use Shotwell it seems they're out of luck for now since certain dependencies don't appear to be in the repository and they would not have access to them even if they were. The reason I mentioned deluge previously was to bring up the fact that deluge and all the things it depends on are capable of being compiled in a users local directory with no need for root powers. I don't think this is a use case that comes up often, however, it's probably not one that should be ignored. If I am correct in these assumptions, and you agree with me, I will go ahead and ticket this idea that Shotwell and it's direct dependencies that Yorba works on should be able to be built locally. I understand one has no control over those that are not built by Yorba directly. Dave On Fri, Jun 4, 2010 at 2:46 PM, Jim Nelson wrote: > So, PREFIX is used to declare the base directory for a whole host of > files being installed. Thus, with your prefix, the following files > will be installed as follows: > > /home/dave/shotwell/gexiv2/lib/libgexiv2.la > /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) > /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc > /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi > > I see two immediate problems here. > > First, because gexiv2.pc is stored in a non-standard location, > pkg-config can't find it. Shotwell's Makefile relies on pkg-config > locating gexiv2 to (a) verify gexiv2 is installed and (b) to get > necessary gcc flags for building Shotwell with gexiv2. This is what > the PKG_CONFIG_PATH message is telling you. > > Second, the VAPI file is also in a non-standard location. valac needs > to be told of this additional VAPI directory. I don't know of any > environment variable that can be used to direct valac to this > directory, you have to specify it on the command-line with --vapidir. > Shotwell's Makefile currently doesn't allow you to specify that with > the configure script ... if this is important, I'll let you ticket > this. You can modify Shotwell's Makefile directly in the interim. > > I would point out that unlike deluge, gexiv2 is a library, not a > program, and therefore must be locatable for programs to build and > execute. > > -- Jim > > On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez > wrote: > > Thanks for the tips but I did not want to install shotwell to the system > > directories. Call it stubbornness :) Is there anyway to install it > locally > > like Bengt suggested, in ~/unstable/shotwell > > > > I thought I had been specifying the prefix in ./configure which is why I > > attempted to run make install without sudo. Does make accept the prefix > > parameter like ./configure does? > > > > There must be a way to install without sudo here. I've done it for > programs > > like deluge in the past which normally require root powers to install. > > > > > > > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree wrote: > > > >> Or specify the prefix parameter and install in ~/unstable/shotwell .... > >> > >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > >> > David, > >> > > >> > As Mattias pointed out, you need to be root to run make install, so on > >> > Ubuntu, you would do: > >> > > >> > $ make > >> > $ sudo make install > >> > > >> > Everything is installed in /usr/local so is completely separate from > >> > what is installed through apt-get or Synaptic. I've got it working > fine > >> > on my Lucid laptop. > >> > > >> > Bruno > >> > > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > >> > > Sorry, I was wrong here, as I did not read your letter thoroughly. > >> > > > >> > > You definitely need to run make install with sudo, since it has to > >> > > install to system directories, where user cannot write to. > >> > > > >> > > Actually in the install instructions there is written "# make > install", > >> > > where # refers to a command which needs to be run as root (or with > >> > > sudo), as opposed to $ which refers to a ordinary user. > >> > > > >> > > > >> > > Mattias > >> > > > >> > > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David > Velazquez: > >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. > >> Try > >> > > > as I might I can't seem to get shotwell to complain about anything > >> > > > other than gexiv2 which, according to the output, should have been > >> > > > compiled properly. > >> > > > > >> > > > The only thing apt-get build-dep shotwell wants to install is > >> > > > libhal-dev which is no longer needed when building from trunk. I > have > >> > > > libgudev which replaces it though. > >> > > > > >> > > > Thanks for the tips. > >> > > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru < > mahfiaz at gmail.com> > >> > > > wrote: > >> > > > To build you need header files, which are in *-dev > packages. > >> > > > Install > >> > > > libexiv2-dev and see if this makes shotwell compile (or > >> > > > complain about > >> > > > another dependency). > >> > > > If you hit another dependency apt-get search exiv (or > >> whatever > >> > > > it > >> > > > complains about) and install corresponding package. > >> > > > > >> > > > All dependencies for the version in repository can be > >> > > > installed with > >> > > > apt-get build-dep packagename > >> > > > > >> > > > http://yorba.org/shotwell/install/ > >> > > > > >> > > > > >> > > > Mattias > >> > > > > >> > > > > >> > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas > David > >> > > > Velazquez: > >> > > > > >> > > > > I'm confident I'm doing something simple wrong, > somewhere, > >> > > > but I can't seem > >> > > > > to build shotwell from trunk in Lucid > >> > > > > > >> > > > > Right now it's saying that it can't find gexiv2 and > >> > > > suggesting I change the > >> > > > > PKG_CONFIG_PATH. > >> > > > > > >> > > > > I understand gexiv2 needed to be built from scratch as > well > >> > > > so I pulled it > >> > > > > and compiled it in ~/shotwell/gexiv2 using: > >> > > > > > >> > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > >> > > > > make > >> > > > > make install > >> > > > > > >> > > > > The only error I get from gexiv2 occurs during make > install > >> > > > and is this: > >> > > > > > >> > > > > /sbin/ldconfig.real: Can't create temporary cache > >> > > > file /etc/ld.so.cache~: > >> > > > > Permission denied > >> > > > > make: [install] Error 1 (ignored) > >> > > > > > >> > > > > I assume this is due to me not using sudo and it not > being > >> > > > able to write to > >> > > > > /etc/ld.so.cache > >> > > > > Is this enough to prevent gexiv2 from building properly > and > >> > > > therefore > >> > > > > shotwell from using it? > >> > > > > > >> > > > > > >> > > > > Shotwell itself is being built (or attempting to be > built) > >> > > > in ~/shotwell > >> > > > > using the command ./configure > --prefix=/home/dave/shotwell > >> > > > > > >> > > > > The dependencies for gexiv2 > (exiv2,libexiv2,libexiv2-dev) > >> > > > were installed > >> > > > > from Ubuntu's repositories. > >> > > > > > >> > > > > I've tried moving the installation for gexiv2 to > someplace > >> > > > outside of > >> > > > > ~/shotwell to no avail. > >> > > > > > >> > > > > I'd appreciate any help. > >> > > > > > >> > > > > Dave > >> > > > > >> > > > > _______________________________________________ > >> > > > > 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 > >> > >> > >> _______________________________________________ > >> 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 brunogirin at gmail.com Fri Jun 4 21:52:49 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 04 Jun 2010 22:52:49 +0100 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: <1275688369.1595.55.camel@nuuk> On Fri, 2010-06-04 at 15:13 -0400, David Velazquez wrote: > Thanks Bruno, Jim, this clears some things up for me. I went ahead and used > my sudo powers to install gexiv2 which Shotwell promptly found. Inevitably > shotwell failed at finding libraw, but that was my own doing ;). It seems I > may have to compile that to. Yes indeed, you can get it here: http://www.libraw.org/download#stable > > From the conversation we've been having it appears to me that Shotwell is > not capable of installing to a local directory unless it's dependencies, > gexiv2 (amongst others) are installed in the standard locations where > pkg-config would look for them. I'm sure it's more complicated than that, > but hopefully I got the gist of it. I bet the majority of users have no > problems with this since most of them will use a binary deb file (for > instance), the PPA, or the release in their distro of choice. > > In the case of someone with no root or sudo powers who wants to use Shotwell > it seems they're out of luck for now since certain dependencies don't appear > to be in the repository and they would not have access to them even if they > were. The reason I mentioned deluge previously was to bring up the fact that > deluge and all the things it depends on are capable of being compiled in a > users local directory with no need for root powers. I don't think this is a > use case that comes up often, however, it's probably not one that should be > ignored. > > If I am correct in these assumptions, and you agree with me, I will go ahead > and ticket this idea that Shotwell and it's direct dependencies that Yorba > works on should be able to be built locally. I understand one has no control > over those that are not built by Yorba directly. That sounds reasonable. Based on Jim's email, it would be a case of enabling the customisation of the --vapidir option in the makefile, and possibly adding relevant instructions to the INSTALL file. If you want to file it in Trac, I'll have a go at solving it. Bruno > > Dave > > On Fri, Jun 4, 2010 at 2:46 PM, Jim Nelson wrote: > > > So, PREFIX is used to declare the base directory for a whole host of > > files being installed. Thus, with your prefix, the following files > > will be installed as follows: > > > > /home/dave/shotwell/gexiv2/lib/libgexiv2.la > > /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) > > /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc > > /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi > > > > I see two immediate problems here. > > > > First, because gexiv2.pc is stored in a non-standard location, > > pkg-config can't find it. Shotwell's Makefile relies on pkg-config > > locating gexiv2 to (a) verify gexiv2 is installed and (b) to get > > necessary gcc flags for building Shotwell with gexiv2. This is what > > the PKG_CONFIG_PATH message is telling you. > > > > Second, the VAPI file is also in a non-standard location. valac needs > > to be told of this additional VAPI directory. I don't know of any > > environment variable that can be used to direct valac to this > > directory, you have to specify it on the command-line with --vapidir. > > Shotwell's Makefile currently doesn't allow you to specify that with > > the configure script ... if this is important, I'll let you ticket > > this. You can modify Shotwell's Makefile directly in the interim. > > > > I would point out that unlike deluge, gexiv2 is a library, not a > > program, and therefore must be locatable for programs to build and > > execute. > > > > -- Jim > > > > On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez > > wrote: > > > Thanks for the tips but I did not want to install shotwell to the system > > > directories. Call it stubbornness :) Is there anyway to install it > > locally > > > like Bengt suggested, in ~/unstable/shotwell > > > > > > I thought I had been specifying the prefix in ./configure which is why I > > > attempted to run make install without sudo. Does make accept the prefix > > > parameter like ./configure does? > > > > > > There must be a way to install without sudo here. I've done it for > > programs > > > like deluge in the past which normally require root powers to install. > > > > > > > > > > > > > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree wrote: > > > > > >> Or specify the prefix parameter and install in ~/unstable/shotwell .... > > >> > > >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > >> > David, > > >> > > > >> > As Mattias pointed out, you need to be root to run make install, so on > > >> > Ubuntu, you would do: > > >> > > > >> > $ make > > >> > $ sudo make install > > >> > > > >> > Everything is installed in /usr/local so is completely separate from > > >> > what is installed through apt-get or Synaptic. I've got it working > > fine > > >> > on my Lucid laptop. > > >> > > > >> > Bruno > > >> > > > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > >> > > Sorry, I was wrong here, as I did not read your letter thoroughly. > > >> > > > > >> > > You definitely need to run make install with sudo, since it has to > > >> > > install to system directories, where user cannot write to. > > >> > > > > >> > > Actually in the install instructions there is written "# make > > install", > > >> > > where # refers to a command which needs to be run as root (or with > > >> > > sudo), as opposed to $ which refers to a ordinary user. > > >> > > > > >> > > > > >> > > Mattias > > >> > > > > >> > > > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David > > Velazquez: > > >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. > > >> Try > > >> > > > as I might I can't seem to get shotwell to complain about anything > > >> > > > other than gexiv2 which, according to the output, should have been > > >> > > > compiled properly. > > >> > > > > > >> > > > The only thing apt-get build-dep shotwell wants to install is > > >> > > > libhal-dev which is no longer needed when building from trunk. I > > have > > >> > > > libgudev which replaces it though. > > >> > > > > > >> > > > Thanks for the tips. > > >> > > > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru < > > mahfiaz at gmail.com> > > >> > > > wrote: > > >> > > > To build you need header files, which are in *-dev > > packages. > > >> > > > Install > > >> > > > libexiv2-dev and see if this makes shotwell compile (or > > >> > > > complain about > > >> > > > another dependency). > > >> > > > If you hit another dependency apt-get search exiv (or > > >> whatever > > >> > > > it > > >> > > > complains about) and install corresponding package. > > >> > > > > > >> > > > All dependencies for the version in repository can be > > >> > > > installed with > > >> > > > apt-get build-dep packagename > > >> > > > > > >> > > > http://yorba.org/shotwell/install/ > > >> > > > > > >> > > > > > >> > > > Mattias > > >> > > > > > >> > > > > > >> > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas > > David > > >> > > > Velazquez: > > >> > > > > > >> > > > > I'm confident I'm doing something simple wrong, > > somewhere, > > >> > > > but I can't seem > > >> > > > > to build shotwell from trunk in Lucid > > >> > > > > > > >> > > > > Right now it's saying that it can't find gexiv2 and > > >> > > > suggesting I change the > > >> > > > > PKG_CONFIG_PATH. > > >> > > > > > > >> > > > > I understand gexiv2 needed to be built from scratch as > > well > > >> > > > so I pulled it > > >> > > > > and compiled it in ~/shotwell/gexiv2 using: > > >> > > > > > > >> > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > >> > > > > make > > >> > > > > make install > > >> > > > > > > >> > > > > The only error I get from gexiv2 occurs during make > > install > > >> > > > and is this: > > >> > > > > > > >> > > > > /sbin/ldconfig.real: Can't create temporary cache > > >> > > > file /etc/ld.so.cache~: > > >> > > > > Permission denied > > >> > > > > make: [install] Error 1 (ignored) > > >> > > > > > > >> > > > > I assume this is due to me not using sudo and it not > > being > > >> > > > able to write to > > >> > > > > /etc/ld.so.cache > > >> > > > > Is this enough to prevent gexiv2 from building properly > > and > > >> > > > therefore > > >> > > > > shotwell from using it? > > >> > > > > > > >> > > > > > > >> > > > > Shotwell itself is being built (or attempting to be > > built) > > >> > > > in ~/shotwell > > >> > > > > using the command ./configure > > --prefix=/home/dave/shotwell > > >> > > > > > > >> > > > > The dependencies for gexiv2 > > (exiv2,libexiv2,libexiv2-dev) > > >> > > > were installed > > >> > > > > from Ubuntu's repositories. > > >> > > > > > > >> > > > > I've tried moving the installation for gexiv2 to > > someplace > > >> > > > outside of > > >> > > > > ~/shotwell to no avail. > > >> > > > > > > >> > > > > I'd appreciate any help. > > >> > > > > > > >> > > > > Dave > > >> > > > > > >> > > > > _______________________________________________ > > >> > > > > 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 > > >> > > >> > > >> _______________________________________________ > > >> 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 david.velazquez08 at gmail.com Fri Jun 4 22:59:42 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 18:59:42 -0400 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275688369.1595.55.camel@nuuk> References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> <1275688369.1595.55.camel@nuuk> Message-ID: I managed to get it, thanks Bruno. Silly me was sleepy last night and I forgot that piece. Created the ticket here: http://trac.yorba.org/ticket/2047 On Fri, Jun 4, 2010 at 5:52 PM, Bruno Girin wrote: > On Fri, 2010-06-04 at 15:13 -0400, David Velazquez wrote: > > Thanks Bruno, Jim, this clears some things up for me. I went ahead and > used > > my sudo powers to install gexiv2 which Shotwell promptly found. > Inevitably > > shotwell failed at finding libraw, but that was my own doing ;). It seems > I > > may have to compile that to. > > Yes indeed, you can get it here: http://www.libraw.org/download#stable > > > > > From the conversation we've been having it appears to me that Shotwell is > > not capable of installing to a local directory unless it's dependencies, > > gexiv2 (amongst others) are installed in the standard locations where > > pkg-config would look for them. I'm sure it's more complicated than that, > > but hopefully I got the gist of it. I bet the majority of users have no > > problems with this since most of them will use a binary deb file (for > > instance), the PPA, or the release in their distro of choice. > > > > In the case of someone with no root or sudo powers who wants to use > Shotwell > > it seems they're out of luck for now since certain dependencies don't > appear > > to be in the repository and they would not have access to them even if > they > > were. The reason I mentioned deluge previously was to bring up the fact > that > > deluge and all the things it depends on are capable of being compiled in > a > > users local directory with no need for root powers. I don't think this is > a > > use case that comes up often, however, it's probably not one that should > be > > ignored. > > > > If I am correct in these assumptions, and you agree with me, I will go > ahead > > and ticket this idea that Shotwell and it's direct dependencies that > Yorba > > works on should be able to be built locally. I understand one has no > control > > over those that are not built by Yorba directly. > > That sounds reasonable. Based on Jim's email, it would be a case of > enabling the customisation of the --vapidir option in the makefile, and > possibly adding relevant instructions to the INSTALL file. > > If you want to file it in Trac, I'll have a go at solving it. > > Bruno > > > > > Dave > > > > On Fri, Jun 4, 2010 at 2:46 PM, Jim Nelson wrote: > > > > > So, PREFIX is used to declare the base directory for a whole host of > > > files being installed. Thus, with your prefix, the following files > > > will be installed as follows: > > > > > > /home/dave/shotwell/gexiv2/lib/libgexiv2.la > > > /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) > > > /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc > > > /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi > > > > > > I see two immediate problems here. > > > > > > First, because gexiv2.pc is stored in a non-standard location, > > > pkg-config can't find it. Shotwell's Makefile relies on pkg-config > > > locating gexiv2 to (a) verify gexiv2 is installed and (b) to get > > > necessary gcc flags for building Shotwell with gexiv2. This is what > > > the PKG_CONFIG_PATH message is telling you. > > > > > > Second, the VAPI file is also in a non-standard location. valac needs > > > to be told of this additional VAPI directory. I don't know of any > > > environment variable that can be used to direct valac to this > > > directory, you have to specify it on the command-line with --vapidir. > > > Shotwell's Makefile currently doesn't allow you to specify that with > > > the configure script ... if this is important, I'll let you ticket > > > this. You can modify Shotwell's Makefile directly in the interim. > > > > > > I would point out that unlike deluge, gexiv2 is a library, not a > > > program, and therefore must be locatable for programs to build and > > > execute. > > > > > > -- Jim > > > > > > On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez > > > wrote: > > > > Thanks for the tips but I did not want to install shotwell to the > system > > > > directories. Call it stubbornness :) Is there anyway to install it > > > locally > > > > like Bengt suggested, in ~/unstable/shotwell > > > > > > > > I thought I had been specifying the prefix in ./configure which is > why I > > > > attempted to run make install without sudo. Does make accept the > prefix > > > > parameter like ./configure does? > > > > > > > > There must be a way to install without sudo here. I've done it for > > > programs > > > > like deluge in the past which normally require root powers to > install. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree > wrote: > > > > > > > >> Or specify the prefix parameter and install in ~/unstable/shotwell > .... > > > >> > > > >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > > >> > David, > > > >> > > > > >> > As Mattias pointed out, you need to be root to run make install, > so on > > > >> > Ubuntu, you would do: > > > >> > > > > >> > $ make > > > >> > $ sudo make install > > > >> > > > > >> > Everything is installed in /usr/local so is completely separate > from > > > >> > what is installed through apt-get or Synaptic. I've got it working > > > fine > > > >> > on my Lucid laptop. > > > >> > > > > >> > Bruno > > > >> > > > > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > > >> > > Sorry, I was wrong here, as I did not read your letter > thoroughly. > > > >> > > > > > >> > > You definitely need to run make install with sudo, since it has > to > > > >> > > install to system directories, where user cannot write to. > > > >> > > > > > >> > > Actually in the install instructions there is written "# make > > > install", > > > >> > > where # refers to a command which needs to be run as root (or > with > > > >> > > sudo), as opposed to $ which refers to a ordinary user. > > > >> > > > > > >> > > > > > >> > > Mattias > > > >> > > > > > >> > > > > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David > > > Velazquez: > > > >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already > installed. > > > >> Try > > > >> > > > as I might I can't seem to get shotwell to complain about > anything > > > >> > > > other than gexiv2 which, according to the output, should have > been > > > >> > > > compiled properly. > > > >> > > > > > > >> > > > The only thing apt-get build-dep shotwell wants to install is > > > >> > > > libhal-dev which is no longer needed when building from trunk. > I > > > have > > > >> > > > libgudev which replaces it though. > > > >> > > > > > > >> > > > Thanks for the tips. > > > >> > > > > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru < > > > mahfiaz at gmail.com> > > > >> > > > wrote: > > > >> > > > To build you need header files, which are in *-dev > > > packages. > > > >> > > > Install > > > >> > > > libexiv2-dev and see if this makes shotwell compile > (or > > > >> > > > complain about > > > >> > > > another dependency). > > > >> > > > If you hit another dependency apt-get search exiv (or > > > >> whatever > > > >> > > > it > > > >> > > > complains about) and install corresponding package. > > > >> > > > > > > >> > > > All dependencies for the version in repository can be > > > >> > > > installed with > > > >> > > > apt-get build-dep packagename > > > >> > > > > > > >> > > > http://yorba.org/shotwell/install/ > > > >> > > > > > > >> > > > > > > >> > > > Mattias > > > >> > > > > > > >> > > > > > > >> > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas > > > David > > > >> > > > Velazquez: > > > >> > > > > > > >> > > > > I'm confident I'm doing something simple wrong, > > > somewhere, > > > >> > > > but I can't seem > > > >> > > > > to build shotwell from trunk in Lucid > > > >> > > > > > > > >> > > > > Right now it's saying that it can't find gexiv2 and > > > >> > > > suggesting I change the > > > >> > > > > PKG_CONFIG_PATH. > > > >> > > > > > > > >> > > > > I understand gexiv2 needed to be built from scratch > as > > > well > > > >> > > > so I pulled it > > > >> > > > > and compiled it in ~/shotwell/gexiv2 using: > > > >> > > > > > > > >> > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > > >> > > > > make > > > >> > > > > make install > > > >> > > > > > > > >> > > > > The only error I get from gexiv2 occurs during make > > > install > > > >> > > > and is this: > > > >> > > > > > > > >> > > > > /sbin/ldconfig.real: Can't create temporary cache > > > >> > > > file /etc/ld.so.cache~: > > > >> > > > > Permission denied > > > >> > > > > make: [install] Error 1 (ignored) > > > >> > > > > > > > >> > > > > I assume this is due to me not using sudo and it not > > > being > > > >> > > > able to write to > > > >> > > > > /etc/ld.so.cache > > > >> > > > > Is this enough to prevent gexiv2 from building > properly > > > and > > > >> > > > therefore > > > >> > > > > shotwell from using it? > > > >> > > > > > > > >> > > > > > > > >> > > > > Shotwell itself is being built (or attempting to be > > > built) > > > >> > > > in ~/shotwell > > > >> > > > > using the command ./configure > > > --prefix=/home/dave/shotwell > > > >> > > > > > > > >> > > > > The dependencies for gexiv2 > > > (exiv2,libexiv2,libexiv2-dev) > > > >> > > > were installed > > > >> > > > > from Ubuntu's repositories. > > > >> > > > > > > > >> > > > > I've tried moving the installation for gexiv2 to > > > someplace > > > >> > > > outside of > > > >> > > > > ~/shotwell to no avail. > > > >> > > > > > > > >> > > > > I'd appreciate any help. > > > >> > > > > > > > >> > > > > Dave > > > >> > > > > > > >> > > > > _______________________________________________ > > > >> > > > > 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 > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 bengt at thuree.com Fri Jun 4 23:10:01 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sat, 05 Jun 2010 09:10:01 +1000 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> Message-ID: <1275693001.2894.9.camel@lappis> Hmm... I compile and install shotwell in my local ~/unstable directory without to much of an issue. I install gexiv2 in the same place, make make install ---> Gives an error message at the end, but it seems to work fine. > install -m 644 gexiv2.pc /home/bengt/unstable/gexiv2/lib/pkgconfig > install -m 644 gexiv2.vapi /home/bengt/unstable/gexiv2/share/vala/vapi > ldconfig > make: ldconfig: Command not found > make: [install] Error 127 (ignored) I copy the gexiv2.vapi from ~/unstable/gexiv2/share/vala/vapi/gexiv2.vapi to shotwell/vapi Then when I compile shotwell, I only need to let it know where to find gexiv2's gexiv2.pc file $ PKG_CONFIG_PATH=~/unstable/gexiv2/lib/pkgconfig $ export PKG_CONFIG_PATH /Bengt On Fri, 2010-06-04 at 15:13 -0400, David Velazquez wrote: > Thanks Bruno, Jim, this clears some things up for me. I went ahead and used > my sudo powers to install gexiv2 which Shotwell promptly found. Inevitably > shotwell failed at finding libraw, but that was my own doing ;). It seems I > may have to compile that to. > > From the conversation we've been having it appears to me that Shotwell is > not capable of installing to a local directory unless it's dependencies, > gexiv2 (amongst others) are installed in the standard locations where > pkg-config would look for them. I'm sure it's more complicated than that, > but hopefully I got the gist of it. I bet the majority of users have no > problems with this since most of them will use a binary deb file (for > instance), the PPA, or the release in their distro of choice. > > In the case of someone with no root or sudo powers who wants to use Shotwell > it seems they're out of luck for now since certain dependencies don't appear > to be in the repository and they would not have access to them even if they > were. The reason I mentioned deluge previously was to bring up the fact that > deluge and all the things it depends on are capable of being compiled in a > users local directory with no need for root powers. I don't think this is a > use case that comes up often, however, it's probably not one that should be > ignored. > > If I am correct in these assumptions, and you agree with me, I will go ahead > and ticket this idea that Shotwell and it's direct dependencies that Yorba > works on should be able to be built locally. I understand one has no control > over those that are not built by Yorba directly. > > Dave > > On Fri, Jun 4, 2010 at 2:46 PM, Jim Nelson wrote: > > > So, PREFIX is used to declare the base directory for a whole host of > > files being installed. Thus, with your prefix, the following files > > will be installed as follows: > > > > /home/dave/shotwell/gexiv2/lib/libgexiv2.la > > /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) > > /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc > > /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi > > > > I see two immediate problems here. > > > > First, because gexiv2.pc is stored in a non-standard location, > > pkg-config can't find it. Shotwell's Makefile relies on pkg-config > > locating gexiv2 to (a) verify gexiv2 is installed and (b) to get > > necessary gcc flags for building Shotwell with gexiv2. This is what > > the PKG_CONFIG_PATH message is telling you. > > > > Second, the VAPI file is also in a non-standard location. valac needs > > to be told of this additional VAPI directory. I don't know of any > > environment variable that can be used to direct valac to this > > directory, you have to specify it on the command-line with --vapidir. > > Shotwell's Makefile currently doesn't allow you to specify that with > > the configure script ... if this is important, I'll let you ticket > > this. You can modify Shotwell's Makefile directly in the interim. > > > > I would point out that unlike deluge, gexiv2 is a library, not a > > program, and therefore must be locatable for programs to build and > > execute. > > > > -- Jim > > > > On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez > > wrote: > > > Thanks for the tips but I did not want to install shotwell to the system > > > directories. Call it stubbornness :) Is there anyway to install it > > locally > > > like Bengt suggested, in ~/unstable/shotwell > > > > > > I thought I had been specifying the prefix in ./configure which is why I > > > attempted to run make install without sudo. Does make accept the prefix > > > parameter like ./configure does? > > > > > > There must be a way to install without sudo here. I've done it for > > programs > > > like deluge in the past which normally require root powers to install. > > > > > > > > > > > > > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree wrote: > > > > > >> Or specify the prefix parameter and install in ~/unstable/shotwell .... > > >> > > >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > >> > David, > > >> > > > >> > As Mattias pointed out, you need to be root to run make install, so on > > >> > Ubuntu, you would do: > > >> > > > >> > $ make > > >> > $ sudo make install > > >> > > > >> > Everything is installed in /usr/local so is completely separate from > > >> > what is installed through apt-get or Synaptic. I've got it working > > fine > > >> > on my Lucid laptop. > > >> > > > >> > Bruno > > >> > > > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > >> > > Sorry, I was wrong here, as I did not read your letter thoroughly. > > >> > > > > >> > > You definitely need to run make install with sudo, since it has to > > >> > > install to system directories, where user cannot write to. > > >> > > > > >> > > Actually in the install instructions there is written "# make > > install", > > >> > > where # refers to a command which needs to be run as root (or with > > >> > > sudo), as opposed to $ which refers to a ordinary user. > > >> > > > > >> > > > > >> > > Mattias > > >> > > > > >> > > > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David > > Velazquez: > > >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already installed. > > >> Try > > >> > > > as I might I can't seem to get shotwell to complain about anything > > >> > > > other than gexiv2 which, according to the output, should have been > > >> > > > compiled properly. > > >> > > > > > >> > > > The only thing apt-get build-dep shotwell wants to install is > > >> > > > libhal-dev which is no longer needed when building from trunk. I > > have > > >> > > > libgudev which replaces it though. > > >> > > > > > >> > > > Thanks for the tips. > > >> > > > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru < > > mahfiaz at gmail.com> > > >> > > > wrote: > > >> > > > To build you need header files, which are in *-dev > > packages. > > >> > > > Install > > >> > > > libexiv2-dev and see if this makes shotwell compile (or > > >> > > > complain about > > >> > > > another dependency). > > >> > > > If you hit another dependency apt-get search exiv (or > > >> whatever > > >> > > > it > > >> > > > complains about) and install corresponding package. > > >> > > > > > >> > > > All dependencies for the version in repository can be > > >> > > > installed with > > >> > > > apt-get build-dep packagename > > >> > > > > > >> > > > http://yorba.org/shotwell/install/ > > >> > > > > > >> > > > > > >> > > > Mattias > > >> > > > > > >> > > > > > >> > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas > > David > > >> > > > Velazquez: > > >> > > > > > >> > > > > I'm confident I'm doing something simple wrong, > > somewhere, > > >> > > > but I can't seem > > >> > > > > to build shotwell from trunk in Lucid > > >> > > > > > > >> > > > > Right now it's saying that it can't find gexiv2 and > > >> > > > suggesting I change the > > >> > > > > PKG_CONFIG_PATH. > > >> > > > > > > >> > > > > I understand gexiv2 needed to be built from scratch as > > well > > >> > > > so I pulled it > > >> > > > > and compiled it in ~/shotwell/gexiv2 using: > > >> > > > > > > >> > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > >> > > > > make > > >> > > > > make install > > >> > > > > > > >> > > > > The only error I get from gexiv2 occurs during make > > install > > >> > > > and is this: > > >> > > > > > > >> > > > > /sbin/ldconfig.real: Can't create temporary cache > > >> > > > file /etc/ld.so.cache~: > > >> > > > > Permission denied > > >> > > > > make: [install] Error 1 (ignored) > > >> > > > > > > >> > > > > I assume this is due to me not using sudo and it not > > being > > >> > > > able to write to > > >> > > > > /etc/ld.so.cache > > >> > > > > Is this enough to prevent gexiv2 from building properly > > and > > >> > > > therefore > > >> > > > > shotwell from using it? > > >> > > > > > > >> > > > > > > >> > > > > Shotwell itself is being built (or attempting to be > > built) > > >> > > > in ~/shotwell > > >> > > > > using the command ./configure > > --prefix=/home/dave/shotwell > > >> > > > > > > >> > > > > The dependencies for gexiv2 > > (exiv2,libexiv2,libexiv2-dev) > > >> > > > were installed > > >> > > > > from Ubuntu's repositories. > > >> > > > > > > >> > > > > I've tried moving the installation for gexiv2 to > > someplace > > >> > > > outside of > > >> > > > > ~/shotwell to no avail. > > >> > > > > > > >> > > > > I'd appreciate any help. > > >> > > > > > > >> > > > > Dave > > >> > > > > > >> > > > > _______________________________________________ > > >> > > > > 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 > > >> > > >> > > >> _______________________________________________ > > >> 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 david.velazquez08 at gmail.com Fri Jun 4 23:23:19 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 4 Jun 2010 19:23:19 -0400 Subject: [Shotwell] Building shotwell from trunk In-Reply-To: <1275693001.2894.9.camel@lappis> References: <1275629833.8324.9.camel@antiloop> <1275641051.18379.4.camel@antiloop> <1275650664.1856.3.camel@nuuk> <1275661941.2894.0.camel@lappis> <1275693001.2894.9.camel@lappis> Message-ID: That's where I was going wrong! I never did copy gexiv2.vapi and while I tried messing with the pkg config path I didn't know enough about it to do what I needed to do. This message will come in handy for the future though, thank you for pointing out how you did it. For now I have gexiv2 dependencies installed from Ubuntu's repositories, gexiv2 installed in /usr/local, and shotwell itself built locally. Overall, it was a pretty easy process. I would like to note to anyone else who might be considering this that Shotwell from trunk will, while not overwriting your library, make it unavailable to . 5.2. In case you want to revert it would be necessary to build your library from scratch or assign a different library to the trunk one by running: shotwell -d ~/.shotwell2 Thanks for the help in getting this done! On Fri, Jun 4, 2010 at 7:10 PM, Bengt Thuree wrote: > Hmm... > I compile and install shotwell in my local ~/unstable directory without > to much of an issue. > > I install gexiv2 in the same place, > make > make install ---> Gives an error message at the end, but it seems to > work fine. > > > install -m 644 gexiv2.pc /home/bengt/unstable/gexiv2/lib/pkgconfig > > install -m 644 gexiv2.vapi /home/bengt/unstable/gexiv2/share/vala/vapi > > ldconfig > > make: ldconfig: Command not found > > make: [install] Error 127 (ignored) > > I copy the gexiv2.vapi from ~/unstable/gexiv2/share/vala/vapi/gexiv2.vapi > to shotwell/vapi > > Then when I compile shotwell, I only need to let it know where to find > gexiv2's gexiv2.pc file > > $ PKG_CONFIG_PATH=~/unstable/gexiv2/lib/pkgconfig > $ export PKG_CONFIG_PATH > > /Bengt > > > On Fri, 2010-06-04 at 15:13 -0400, David Velazquez wrote: > > Thanks Bruno, Jim, this clears some things up for me. I went ahead and > used > > my sudo powers to install gexiv2 which Shotwell promptly found. > Inevitably > > shotwell failed at finding libraw, but that was my own doing ;). It seems > I > > may have to compile that to. > > > > From the conversation we've been having it appears to me that Shotwell is > > not capable of installing to a local directory unless it's dependencies, > > gexiv2 (amongst others) are installed in the standard locations where > > pkg-config would look for them. I'm sure it's more complicated than that, > > but hopefully I got the gist of it. I bet the majority of users have no > > problems with this since most of them will use a binary deb file (for > > instance), the PPA, or the release in their distro of choice. > > > > In the case of someone with no root or sudo powers who wants to use > Shotwell > > it seems they're out of luck for now since certain dependencies don't > appear > > to be in the repository and they would not have access to them even if > they > > were. The reason I mentioned deluge previously was to bring up the fact > that > > deluge and all the things it depends on are capable of being compiled in > a > > users local directory with no need for root powers. I don't think this is > a > > use case that comes up often, however, it's probably not one that should > be > > ignored. > > > > If I am correct in these assumptions, and you agree with me, I will go > ahead > > and ticket this idea that Shotwell and it's direct dependencies that > Yorba > > works on should be able to be built locally. I understand one has no > control > > over those that are not built by Yorba directly. > > > > Dave > > > > On Fri, Jun 4, 2010 at 2:46 PM, Jim Nelson wrote: > > > > > So, PREFIX is used to declare the base directory for a whole host of > > > files being installed. Thus, with your prefix, the following files > > > will be installed as follows: > > > > > > /home/dave/shotwell/gexiv2/lib/libgexiv2.la > > > /home/dave/shotwell/gexiv2/include/gexiv2.h (and more header files) > > > /home/dave/shotwell/gexiv2/lib/pkgconfig/gexiv2.pc > > > /home/dave/shotwell/gexiv2/share/vala/vapi/gexiv2.vapi > > > > > > I see two immediate problems here. > > > > > > First, because gexiv2.pc is stored in a non-standard location, > > > pkg-config can't find it. Shotwell's Makefile relies on pkg-config > > > locating gexiv2 to (a) verify gexiv2 is installed and (b) to get > > > necessary gcc flags for building Shotwell with gexiv2. This is what > > > the PKG_CONFIG_PATH message is telling you. > > > > > > Second, the VAPI file is also in a non-standard location. valac needs > > > to be told of this additional VAPI directory. I don't know of any > > > environment variable that can be used to direct valac to this > > > directory, you have to specify it on the command-line with --vapidir. > > > Shotwell's Makefile currently doesn't allow you to specify that with > > > the configure script ... if this is important, I'll let you ticket > > > this. You can modify Shotwell's Makefile directly in the interim. > > > > > > I would point out that unlike deluge, gexiv2 is a library, not a > > > program, and therefore must be locatable for programs to build and > > > execute. > > > > > > -- Jim > > > > > > On Fri, Jun 4, 2010 at 10:57 AM, David Velazquez > > > wrote: > > > > Thanks for the tips but I did not want to install shotwell to the > system > > > > directories. Call it stubbornness :) Is there anyway to install it > > > locally > > > > like Bengt suggested, in ~/unstable/shotwell > > > > > > > > I thought I had been specifying the prefix in ./configure which is > why I > > > > attempted to run make install without sudo. Does make accept the > prefix > > > > parameter like ./configure does? > > > > > > > > There must be a way to install without sudo here. I've done it for > > > programs > > > > like deluge in the past which normally require root powers to > install. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 4, 2010 at 10:32 AM, Bengt Thuree > wrote: > > > > > > > >> Or specify the prefix parameter and install in ~/unstable/shotwell > .... > > > >> > > > >> On Fri, 2010-06-04 at 12:24 +0100, Bruno Girin wrote: > > > >> > David, > > > >> > > > > >> > As Mattias pointed out, you need to be root to run make install, > so on > > > >> > Ubuntu, you would do: > > > >> > > > > >> > $ make > > > >> > $ sudo make install > > > >> > > > > >> > Everything is installed in /usr/local so is completely separate > from > > > >> > what is installed through apt-get or Synaptic. I've got it working > > > fine > > > >> > on my Lucid laptop. > > > >> > > > > >> > Bruno > > > >> > > > > >> > On Fri, 2010-06-04 at 11:44 +0300, Mattias P?ldaru wrote: > > > >> > > Sorry, I was wrong here, as I did not read your letter > thoroughly. > > > >> > > > > > >> > > You definitely need to run make install with sudo, since it has > to > > > >> > > install to system directories, where user cannot write to. > > > >> > > > > > >> > > Actually in the install instructions there is written "# make > > > install", > > > >> > > where # refers to a command which needs to be run as root (or > with > > > >> > > sudo), as opposed to $ which refers to a ordinary user. > > > >> > > > > > >> > > > > > >> > > Mattias > > > >> > > > > > >> > > > > > >> > > ?hel kenal p?eval, R, 2010-06-04 kell 02:11, kirjutas David > > > Velazquez: > > > >> > > > Hey, I have exiv2, libexiv2-6, and libexiv2-dev already > installed. > > > >> Try > > > >> > > > as I might I can't seem to get shotwell to complain about > anything > > > >> > > > other than gexiv2 which, according to the output, should have > been > > > >> > > > compiled properly. > > > >> > > > > > > >> > > > The only thing apt-get build-dep shotwell wants to install is > > > >> > > > libhal-dev which is no longer needed when building from trunk. > I > > > have > > > >> > > > libgudev which replaces it though. > > > >> > > > > > > >> > > > Thanks for the tips. > > > >> > > > > > > >> > > > On Fri, Jun 4, 2010 at 1:37 AM, Mattias P?ldaru < > > > mahfiaz at gmail.com> > > > >> > > > wrote: > > > >> > > > To build you need header files, which are in *-dev > > > packages. > > > >> > > > Install > > > >> > > > libexiv2-dev and see if this makes shotwell compile > (or > > > >> > > > complain about > > > >> > > > another dependency). > > > >> > > > If you hit another dependency apt-get search exiv (or > > > >> whatever > > > >> > > > it > > > >> > > > complains about) and install corresponding package. > > > >> > > > > > > >> > > > All dependencies for the version in repository can be > > > >> > > > installed with > > > >> > > > apt-get build-dep packagename > > > >> > > > > > > >> > > > http://yorba.org/shotwell/install/ > > > >> > > > > > > >> > > > > > > >> > > > Mattias > > > >> > > > > > > >> > > > > > > >> > > > ?hel kenal p?eval, R, 2010-06-04 kell 01:18, kirjutas > > > David > > > >> > > > Velazquez: > > > >> > > > > > > >> > > > > I'm confident I'm doing something simple wrong, > > > somewhere, > > > >> > > > but I can't seem > > > >> > > > > to build shotwell from trunk in Lucid > > > >> > > > > > > > >> > > > > Right now it's saying that it can't find gexiv2 and > > > >> > > > suggesting I change the > > > >> > > > > PKG_CONFIG_PATH. > > > >> > > > > > > > >> > > > > I understand gexiv2 needed to be built from scratch > as > > > well > > > >> > > > so I pulled it > > > >> > > > > and compiled it in ~/shotwell/gexiv2 using: > > > >> > > > > > > > >> > > > > ./configure --prefix=/home/dave/shotwell/gexiv2 > > > >> > > > > make > > > >> > > > > make install > > > >> > > > > > > > >> > > > > The only error I get from gexiv2 occurs during make > > > install > > > >> > > > and is this: > > > >> > > > > > > > >> > > > > /sbin/ldconfig.real: Can't create temporary cache > > > >> > > > file /etc/ld.so.cache~: > > > >> > > > > Permission denied > > > >> > > > > make: [install] Error 1 (ignored) > > > >> > > > > > > > >> > > > > I assume this is due to me not using sudo and it not > > > being > > > >> > > > able to write to > > > >> > > > > /etc/ld.so.cache > > > >> > > > > Is this enough to prevent gexiv2 from building > properly > > > and > > > >> > > > therefore > > > >> > > > > shotwell from using it? > > > >> > > > > > > > >> > > > > > > > >> > > > > Shotwell itself is being built (or attempting to be > > > built) > > > >> > > > in ~/shotwell > > > >> > > > > using the command ./configure > > > --prefix=/home/dave/shotwell > > > >> > > > > > > > >> > > > > The dependencies for gexiv2 > > > (exiv2,libexiv2,libexiv2-dev) > > > >> > > > were installed > > > >> > > > > from Ubuntu's repositories. > > > >> > > > > > > > >> > > > > I've tried moving the installation for gexiv2 to > > > someplace > > > >> > > > outside of > > > >> > > > > ~/shotwell to no avail. > > > >> > > > > > > > >> > > > > I'd appreciate any help. > > > >> > > > > > > > >> > > > > Dave > > > >> > > > > > > >> > > > > _______________________________________________ > > > >> > > > > 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 > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 mordred at inaugust.com Sun Jun 6 00:42:27 2010 From: mordred at inaugust.com (Monty Taylor) Date: Sat, 05 Jun 2010 17:42:27 -0700 Subject: [Shotwell] Importing picasa.ini files Message-ID: <4C0AEEF3.5080506@inaugust.com> Hi! I filed a ticket a while back: http://trac.yorba.org/ticket/1930 for importing picasa.ini file meta information while doing a bulk folder import. I Totally understand that, as a feature request, it's likely gone unnoticed. (I know I don't normally spend huge amounts of time poring over feature requests on my projects) Thing is - I've implemented it, and I'm not sure how better to alert anyone to that, or to possibly get my patch merged- or get feedback on what you'd like to see different in the patch to make it more acceptable. SO... I've attached a patch to the ticket, but also have attached it here. Thanks! Monty -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: picasa_import.patch URL: From baldakkl at gmail.com Mon Jun 7 18:06:44 2010 From: baldakkl at gmail.com (Lorenzo Baldacchini) Date: Mon, 7 Jun 2010 20:06:44 +0200 Subject: [Shotwell] file .arw Message-ID: Hi all, this is my first email to the mailing list, so sorry if it doesn't respect the standard I will try to write better the next. I have the Shotwell 0.5.90+trunk version. I have a collection of .arw photo and, when I click on "open with an external editor" it makes a jpg copy of the image and opens this copy with gimp. Shouldn't it open directly the raw file with the editor chosen from the dialog? Should I open some bug-ticket? Thank you very much. Lorenzo From lucas at yorba.org Mon Jun 7 18:17:30 2010 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 7 Jun 2010 11:17:30 -0700 Subject: [Shotwell] Slovenian translation for Shotwell In-Reply-To: References: <4C06E1A7.2040201@yorba.org> Message-ID: > I have one question about transifex (this is the first program i am > translating through their interface). Does the funcion "watch it" also > notifies me of .pot changes or only if someone else updates /po/sl_SI.po? To my knowledge, you can't set a watch on the translation source file (i.e., the POT strings template file); you can only set watches on individual PO files. That said, with Shotwell, POT watches aren't as necessary as they might be for some other projects, because we have a very well defined translation workflow and schedule for pushing new POT files. In general, when translating Shotwell, you can count on the following: (i) About two weeks before any major release of Shotwell, strings will be frozen and a new, finalized POT file containing all strings included in the upcoming release will be pushed to Transifex. When this happens, all translators are notified by email that a release is coming up and that a finalized POT file for the release is available. (ii) During the middle of the development cycle (i.e. in the months between major releases), we re-generate the POT file and push it to Transifex once every 2-3 weeks, usually on Tuesdays. So if you simply check Transifex every Wednesday, you'll be able to see if a new POT file has been created within 24 hours of its generation. Thanks for all your hard work translating Shotwell. Take care, Lucas From adam at yorba.org Mon Jun 7 18:18:16 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 07 Jun 2010 11:18:16 -0700 Subject: [Shotwell] file .arw In-Reply-To: References: Message-ID: <4C0D37E8.4060201@yorba.org> On 06/07/2010 11:06 AM, Lorenzo Baldacchini wrote: > Hi all, > this is my first email to the mailing list, so sorry if it doesn't > respect the standard I will try to write better the next. > I have the Shotwell 0.5.90+trunk version. > I have a collection of .arw photo and, when I click on "open with an > external editor" it makes a jpg copy of the image and opens this copy > with gimp. > Shouldn't it open directly the raw file with the editor chosen from the dialog? > In the current trunk build, the Open With External Editor command doesn't open your RAW editor. To do that, you need to choose the Open With RAW Editor command in the Photos menu. We haven't made a final decision about which menus will contain these commands in the 0.6 release, but perhaps we should consider adding Open With RAW Editor to the context menu for RAW photos. Any other feedback is welcome! adam From baldakkl at gmail.com Tue Jun 8 07:55:29 2010 From: baldakkl at gmail.com (Lorenzo Baldacchini) Date: Tue, 8 Jun 2010 09:55:29 +0200 Subject: [Shotwell] Shotwell Digest, Vol 11, Issue 9 In-Reply-To: References: Message-ID: > In the current trunk build, the Open With External Editor command > doesn't open your RAW editor. ?To do that, you need to choose the Open > With RAW Editor command in the Photos menu. > > We haven't made a final decision about which menus will contain these > commands in the 0.6 release, but perhaps we should consider adding Open > With RAW Editor to the context menu for RAW photos. ?Any other feedback > is welcome! > > adam Ok, got it. Thank you. In my personal opinion the best option would be that the open with external editor in the context menu opens the file according with its extension, without adding too much options in the context menu. Then, from the Photos menu one can choose how to open the file. Anyway thanks a lot, now I have the perfect the perfect photo organizer for ubuntu! From jim at yorba.org Thu Jun 10 23:43:03 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 10 Jun 2010 16:43:03 -0700 Subject: [Shotwell] New GNOME Journal article on Shotwell Message-ID: GNOME Journal has just published an article on Shotwell penned by some guy named Jim Nelson: http://gnomejournal.org/article/99/shotwell-photo-manager Allison Barlow created the wonderful screenshots that accompany it. Cheers, -- Jim From vperetokin at gmail.com Thu Jun 10 23:58:45 2010 From: vperetokin at gmail.com (Vadim Peretokin) Date: Thu, 10 Jun 2010 19:58:45 -0400 Subject: [Shotwell] New GNOME Journal article on Shotwell In-Reply-To: References: Message-ID: Very nice. I was born a year after the mentioned date though :( On Jun 10, 2010 7:43 PM, "Jim Nelson" wrote: GNOME Journal has just published an article on Shotwell penned by some guy named Jim Nelson: http://gnomejournal.org/article/99/shotwell-photo-manager Allison Barlow created the wonderful screenshots that accompany it. Cheers, -- Jim _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From tommy.he at linux.com Fri Jun 11 17:13:53 2010 From: tommy.he at linux.com (Tommy He) Date: Fri, 11 Jun 2010 18:13:53 +0100 Subject: [Shotwell] New GNOME Journal article on Shotwell In-Reply-To: References: Message-ID: Pleasant to read this god article. Especially for the future preview part. ;-) On 11 June 2010 00:43, Jim Nelson wrote: > GNOME Journal has just published an article on Shotwell penned by some guy > named Jim Nelson: > > http://gnomejournal.org/article/99/shotwell-photo-manager > > Allison Barlow created the wonderful screenshots that accompany it. > > Cheers, > > -- Jim > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- Take a Deep Breath out of Windows From peter.puk at gmail.com Sat Jun 12 09:03:58 2010 From: peter.puk at gmail.com (Peter Puk) Date: Sat, 12 Jun 2010 11:03:58 +0200 Subject: [Shotwell] Burn CD from selected photo's Message-ID: Hi developers, I (and my mother, which isn't very familiar with computers) like to see an "Burn to CD" option. Currently she has to select the photo's on the harddisk in different folders and drag them to the CD programm. This involves a lot of clicks/tasks and confuses her vey much. Is there any change the next version includes this burn option? Ronnie From brunogirin at gmail.com Sat Jun 12 11:20:00 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sat, 12 Jun 2010 12:20:00 +0100 Subject: [Shotwell] Burn CD from selected photo's In-Reply-To: References: Message-ID: <1276341600.1574.5.camel@nuuk> Hi Ronnie, This sounds like a great idea. I added it as an enhancement to the Trac database: http://trac.yorba.org/ticket/2101 I don't know what version it will be in but at least it's now on the list :-) In the meantime, if you want to simplify the workflow, you can do the following: * Select all the pictures you want to burn to CD in Shotwell * Go to File -> Export * Export the pictures to a new empty directory * Go to the file manager and drag the content of that new directory to the CD program This should mean that you just have to select pictures from a single directory rather than several, hopefully making it a bit easier. Bruno On Sat, 2010-06-12 at 11:03 +0200, Peter Puk wrote: > Hi developers, > > I (and my mother, which isn't very familiar with computers) like to see an > "Burn to CD" option. Currently she has to select the photo's on the harddisk > in different folders and drag them to the CD programm. This involves a lot > of clicks/tasks and confuses her vey much. Is there any change the next > version includes this burn option? > > Ronnie > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From arph at gmx.net Sun Jun 13 20:59:45 2010 From: arph at gmx.net (arph at gmx.net) Date: Sun, 13 Jun 2010 22:59:45 +0200 Subject: [Shotwell] Monitoring the filesystem for photos and automatically adding them to Shotwell. Message-ID: <4C1546C1.6010403@gmx.net> Hello, i read the upcoming features for shotwell. one thing i am really interested in is the monitoring. There is no further description of what is meant by monitoring so i'd like to know if this is the same like for example amarok monitors the local library. does that mean shotwell will monitor folders and if files are added/removed then it will update its database automatically? when will this feature be implemented? next 0.6? From adam at yorba.org Mon Jun 14 15:44:12 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 14 Jun 2010 08:44:12 -0700 Subject: [Shotwell] Monitoring the filesystem for photos and automatically adding them to Shotwell. In-Reply-To: <4C1546C1.6010403@gmx.net> References: <4C1546C1.6010403@gmx.net> Message-ID: <4C164E4C.3030304@yorba.org> On 06/13/2010 01:59 PM, arph at gmx.net wrote: > Hello, > > i read the upcoming features for shotwell. one thing i am really > interested in is the monitoring. > There is no further description of what is meant by monitoring so i'd > like to know if this is the same like for example amarok monitors the > local library. > does that mean shotwell will monitor folders and if files are > added/removed then it will update its database automatically? > Yes. Our ticket for this feature is at http://trac.yorba.org/ticket/374 , by the way. > when will this feature be implemented? next 0.6? > Monitoring is not yet implemented and will not be in the 0.6 release later this month, but is a relatively high priority for 0.7 which we're planning to release later this summer, probably in August. adam From douglas.m.stanley at gmail.com Mon Jun 14 15:53:44 2010 From: douglas.m.stanley at gmail.com (Douglas Stanley) Date: Mon, 14 Jun 2010 11:53:44 -0400 Subject: [Shotwell] Photos not getting copied to photo library... Message-ID: Hello List, I apologize if this has already been discussed on the list. I tried searching the archives and the tickets and didn't see anything. I had an Ubuntu box, and I installed shotwell. I imported a few thousand photos, and everything was fine. Then I had hard drive issues. I copied the photos, and the shotwell db files over to another machine. I started up shotwell, and everything looked fine. Then I tried to import new photos, and it refuses to copy them to the photo library. It just puts the location to where I imported them from in the shotwell db (I confirmed this by looking at the db file with sqliteman). When importing, I made sure the "copy files to library" box was checked, but it doesn't seem to make any difference! Has anyone else come across this? Thanks, Doug -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From adam at yorba.org Mon Jun 14 16:04:33 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 14 Jun 2010 09:04:33 -0700 Subject: [Shotwell] Photos not getting copied to photo library... In-Reply-To: References: Message-ID: <4C165311.1040909@yorba.org> Doug, On 06/14/2010 08:53 AM, Douglas Stanley wrote: > I had an Ubuntu box, and I installed shotwell. I imported a few > thousand photos, and everything was fine. Then I had hard drive > issues. I copied the photos, and the shotwell db files over to another > machine. I started up shotwell, and everything looked fine. > > Then I tried to import new photos, and it refuses to copy them to the > photo library. It just puts the location to where I imported them from > in the shotwell db (I confirmed this by looking at the db file with > sqliteman). > > When importing, I made sure the "copy files to library" box was > checked, but it doesn't seem to make any difference! Has anyone else > come across this? > If you import photo files which are *already* in your Shotwell library directory, then Shotwell will not copy them even if "copy files to library" is checked. So this is almost certainly the case. If you're using Shotwell 0.5, then your library directory is always the XDG Pictures directory. Look at the definition of XDG_PICTURES_DIR in ~/.config/user-dirs.dirs. If for some reason it is set to your home directory, then Shotwell will believe that all imported photos are already in the library and will never copy them. If you've built Shotwell from trunk (soon to become 0.6) then the situation is a little better: you can use Edit->Preferences to view and change the library directory. Furthermore, the trunk build will warn you if your library directory is your home directory since that's probably not what you want. I hope this helps! adam From adam at yorba.org Mon Jun 14 18:43:06 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 14 Jun 2010 11:43:06 -0700 Subject: [Shotwell] Photos not getting copied to photo library... In-Reply-To: References: <4C165311.1040909@yorba.org> Message-ID: <4C16783A.1040607@yorba.org> Doug, On 06/14/2010 09:17 AM, Douglas Stanley wrote: > > Well, I was trying to import new photos, ones that hadn't been > imported before. But I remember one time it sort of worked, and > imported them into my $HOME dir. I then removed them and tried > re-importing, but then never imported after that. I will double check > the value in the ~/.config/user-dirs.dirs file, to see if that was the > cause. > > I know I tried importing them straight from the SD card though, which > wouldn't have been located under my home dir. It just copied the path > to the SD card into the shotwell DB. > Odd. If you can come up with a reproducible case in which photos imported from an SD card are not copied, and the SD card path is not under your XDG_PICTURES_DIR, then we'd certainly be interested to hear about it. >> If you've built Shotwell from trunk (soon to become 0.6) then the >> situation is a little better: you can use Edit->Preferences to view and >> change the library directory. Furthermore, the trunk build will warn >> you if your library directory is your home directory since that's >> probably not what you want. >> > I was using shotwell 0.5 from ubuntu repos. When 0.6 comes out, any > chance there will be an ubuntu ppa for it? > Yes. As soon as we release Shotwell 0.6 we will also make it available in the Yorba PPA at https://launchpad.net/~yorba/+archive/ppa . > > The tip about where the photo library path is stored, is gold in > itself! That really should be in a wiki or something :) > Good point. I've just added this information to the Shotwell documentation at http://trac.yorba.org/wiki/UsingShotwell0.5 . adam From adam at yorba.org Tue Jun 15 15:59:19 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 15 Jun 2010 08:59:19 -0700 Subject: [Shotwell] shotwell mockups(daniel planas) In-Reply-To: <1274984302.4831.16.camel@dani-laptop> References: <1274984302.4831.16.camel@dani-laptop> Message-ID: <4C17A357.5080603@yorba.org> > my name is Daniel Planas, it's you may know me by some of my work in > ubuntu as a designer, I made some mockups of a possible reorganization > of the program. thus be located above the toolbar as most applications > and is more consistent for the user. I hope you like. > > http://i50.tinypic.com/vwsbch.jpg > > http://i49.tinypic.com/1xz7ls.jpg http://i49.tinypic.com/1xz7ls.jpg > > http://i49.tinypic.com/ae409d.jpg http://i49.tinypic.com/ae409d.jpg > > http://i49.tinypic.com/30cu4ye.jpg http://i49.tinypic.com/30cu4ye.jpg > > Daniel.P > Daniel, Thanks for putting these mockups together, and apologies for the delay in getting back to you - we've been very busy trying to finish up Shotwell 0.6. We're always interested in discussing Shotwell's look and feel. It looks like you're suggesting some of the following changes: - toolbar at the top We intentionally put Shotwell's toolbar at the bottom of the window (unlike most GNOME applications) because we wanted to minimize visual distractions when looking at a photo. We think the eye is most sensitive to the top of an image - that's where faces are likely to be, for example - and so we wanted to minimize visual noise in that area. Totem has also chosen to put its toolbar at the bottom, presumably for similar reasons. We also think that having the toolbar at the bottom fits nicely with the Basic Information pane on the lower left. If lots of people would prefer having the toolbar at the top, however, we could reconsider or possibly make this an option. I'd be happy to hear opinions from other people on this list. - icons at the ends of the zoom slider Agreed; this would be a nice touch. We have a ticket for this at http://trac.yorba.org/ticket/1614 . - search box Agreed; it would be great to have a search box where I could type the name of any tag or any photo filename or caption, for instance. We have a ticket for this at http://trac.yorba.org/ticket/80 . - new icons I like the look of the icons you've suggested. Currently some of Shotwell's icons are fixed but should instead change to adapt to the user's theme as described at http://trac.yorba.org/ticket/1578 . Your icons look like a particularly good match for Ubuntu's Ambiance theme. It's too late to make icon changes for 0.6, but we're planning to release 0.7 later this summer in time for Ubuntu 10.10, and we should work together to make sure that the icons in that release are a good match for the theme in that Ubuntu release (and other distributions as well, of course). - lowercase button text This is a bit unusual for a GNOME application, though I myself don't mind this look. Possibly worth considering. I think that covers most of your proposed changes. In a few of your mockups there's a red circle with the number 1 by the mouse cursor when it's over the Edit button. I don't quite understand what that's about; feel free to explain that if you'd like to discuss it more. Great pictures, by the way. :) adam From robert.ancell at canonical.com Tue Jun 15 23:19:45 2010 From: robert.ancell at canonical.com (Robert Ancell) Date: Wed, 16 Jun 2010 09:19:45 +1000 Subject: [Shotwell] shotwell mockups(daniel planas) In-Reply-To: <4C17A357.5080603@yorba.org> References: <1274984302.4831.16.camel@dani-laptop> <4C17A357.5080603@yorba.org> Message-ID: <4C180A91.9050704@canonical.com> > - lowercase button text > > This is a bit unusual for a GNOME application, though I myself don't > mind this look. Possibly worth considering. > > Button text should always be in "header capitalization": http://library.gnome.org/devel/hig-book/stable/controls-buttons.html.en\ From jim at yorba.org Wed Jun 16 02:34:35 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 15 Jun 2010 19:34:35 -0700 Subject: [Shotwell] Call for testing Message-ID: Hello, We've been working diligently on Shotwell 0.6 and we have high hopes forthis release. Several big new features have been added as well as a slew of tweaks, additions, and bug fixes. Some of the more big ticket items include: * Basic RAW support * Image zooming * PNG support * Support for EXIF, IPTC, and XMP * Edit with external editor * ... and more! We could use your help. We're hoping to ship Shotwell 0.6 in the next two weeks and would like to run it through its paces. We need people to download the current revision in trunk (not the tarball) and really beat up on it. If you're interested, follow the directions here for getting the source and building it: http://www.yorba.org/shotwell/install/#source If you find bugs or issues -- anything that seems odd -- please feel free to report them here on the mailing list or via our Trac ticketing system at: http://trac.yorba.org/ Thanks for your continued support! -- Jim Nelson From vera at yorba.org Wed Jun 16 02:54:15 2010 From: vera at yorba.org (Vera Yin) Date: Tue, 15 Jun 2010 19:54:15 -0700 Subject: [Shotwell] Last Chance to Submit Translations for Shotwell 0.6 Message-ID: Hello Friends of Shotwell, ? As those of you following Shotwell's development may know, Shotwell 0.6 is due out in the next few weeks. We're very excited about this release. It introduces a bonanza of exciting new features, like basic support for working with RAW images, the ability to zoom into and pan over photos to reveal latent detail, and user interface improvements that bring new levels of polish and usability to the Shotwell experience. ? A few weeks ago, we asked previous translators of Shotwell to submit new and updated translations. The response was fantastic. That said, we're still in need of translations for several major languages, including Spanish, Japanese, Arabic, Portuguese, and Hindi. If you'd like to see Shotwell available in one of these languages, we invite you to submit or update a translation file. To make your translation a part of the Shotwell 0.6 distribution, please submit it as a PO file by Monday, June 21 at 9:00am Pacific Daylight Time (UTC-7), either directly in reply to this email or on our Transifex project page at http://www.transifex.net/projects/p/shotwell/c/default/. For your convenience, I have attached the new Shotwell 0.6 POT strings template file to this message. If you've never translated Shotwell before, the process is straightforward with the right tools. Most Shotwell translators prefer POEdit (http://www.poedit.net/), the GNOME translation tool, but some choose LoKalize (http://userbase.kde.org/Lokalize) from the KDE Project. Both tools are easy to use and make translation simple. If you're creating a new translation, all you need to begin is the POT file attached to this message. If you're updating an existing translation, download the existing PO file for that language from our Transifex page and start from there. ? We thank you for your efforts. We hope you're as excited about Shotwell 0.6 as we are, and we wish you all the best. Best Regards, Vera ----------------------------------------- Vera Yin Internationalization Engineer Yorba Foundation From mnemo at minimum.se Wed Jun 16 21:52:14 2010 From: mnemo at minimum.se (Martin Olsson) Date: Wed, 16 Jun 2010 23:52:14 +0200 Subject: [Shotwell] Call for testing In-Reply-To: References: Message-ID: <4C19478E.30103@minimum.se> I tested r1806. I found no critical bugs yet, but some minor stuff: * When I do "Show in File Manager" I would like the specific file pre-selected in the nautilus window that appears. I really find this annoying. * When I use "Set as Desktop Background" on a 2000x3000 (i.e. non-landscape orientation) photo, only a part of the photo is visible on my 1680x1050 screen. It's nice that you switched from the current "scale to fit" to another approach where you add padding instead so that the whole photo is guaranteed to be on screen (this is much better than the current "scale to fit width" which will sometimes crop faces halfway through etc). Maybe you can use a PNG so that the padding is transparent (does that mean the bgcolor in the GNOME appearence dialog is used? not sure...) Otherwise black is probably fine. * Workflow issue; two persons take photos at a party/trip or whatever and later share photos with each other. Since the photos are from the same day, Shotwell mixes the two different sets of photos into a single event. This is a problem because I might want to show someone just my photos. Also, if this wasn't a party but some sort of professional photo shot, it's critical to know which photos where taken by whom for copyright reasons etc. Looking at camera EXIF is not sufficient since people might very well have the same camera. This can be solved by implementing "autotag with tag BLAH on import" but I would personally prefer if the default was to import each set of photos into a named event instead. * Import the JPG linked below. Pango injection attack ftw! :-) http://temp.minimum.se/shotwell_other/pango_needs_escaping.tgz (shotwell:17678): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity - escape ampersand as & What you need to do is to take the tags through: http://www.valadoc.org/glib-2.0/GLib.Markup.printf_escaped.html * The "Browse" button under "Preferences" would use some padding love, it looks too compact with the image right next to the word "Browse". * The Preferences dialog should be resizable. I, for one, tried to make it bigger so I could read the full path set for "import photos to". * Pressing ALT-E, ALT-R, ALT-I in "Preferences", don't work; i.e. console says it all: (shotwell:18398): Gtk-WARNING **: Couldn't find a target for a mnemonic activation. * Inside "Preferences"; ALT-R is bound to both "Browse"-button and "External RAW editor". * Open a specific photo, hit F11 to go fullscreen (this makes gnome-panel go away) and then click "Red Eye" in the toolbar. Now gnome-panel appears again, which is a bit untidy. I see this on a clean Ubuntu 10.04 * When I do "File::Import" Shotwell asks me if I want to make copies of the images or link directly. However, if I drag files to the Shotwell window, it doesn't ask (I think it might just link to the external photo in this case which might cause users to accidentally delete them when they "move to trash" later on). I think it should ask in this case as well just to keep things clear. * Resize the shotwell window so that it consomes about 25% of the screen, then moved it to the bottom right quadrant of the screen. Select some photos and hit "Slideshow". Then press Escape to exit the slideshow. Now the Shotwell window has been moved to 0,0 instead so the Shotwell window is located in the top left quadrant of the screen. * If I open a photo and press CTRL-D to open the "Adjust" dialog. Then I can't reach the top widget by pressing TAB (i.e. where you move the light-point and dark-point in the histogram or whatever those things are called). Accessibility-wise it would be nice if this feature was usable with keyboard only setups (making it much easier to use with screenreaders etc). * At the email/password screen under "File::Publish::Picasa::Login" the keybindings ALT-E for e-mail and ALT-P for password are shown using mnemonics but they don't work. * Previously, one could extract debug info to the terminal using "SHOTWELL_LOG=1 shotwell" but now it's necessary to use "SHOTWELL_LOG=1 SHOTWELL_LOG_FILE=:console: shotwell". I think the latter environment variable should be set to console by default so it works even if you use the old way. * If I select a photo and "Photos :: Adjust Time & Date" and change the exposure date by a large amount like a couple of days then the photos are moved out of the current viewport but they are still selected. I think it would be better if you called something like viewport.scroll_to_selection() after the exposure date has been changed, just to make sure that the selected photos are always visible to the user. * I don't use AM/PM time since I live in Europe. So I'd prefer if the "Adjust Time & Date" dialog was adjusted to my locale and thus didn't show AM/PM but instead a 24-hour clock. If I right click the Date+Time in gnome-panel and select Preferences, I've got 24-hour clock configured in there so maybe Shotwell can read this setting from "/apps/panel/applets/clock_screen0/prefs/format" or similar? * The print preview dialog pre-select the "Letter" paper size and also happily informs me that an A4 is 8.27 inch x 11.69 inch but we use "cm" here and most europeans print on A4 papers. This repros even if I go into "System::Administration::Language Support", switch to the "Text" TAB and choose swedish locale there and finally pressing apply system-wide and restarting Shotwell. * When selecting multiple photos and then opening "Photos::Adjust Date&Time" only one photo is shown which is a bit confusing. It would be nice if there was a visual cue in the UI here that clearly indicated that this photo is just the first among the selected photos. For example, you could render it as a stack of photos where the second photo is showing up partially behind the first one. Martin On 06/16/2010 04:34 AM, Jim Nelson wrote: > Hello, > > We've been working diligently on Shotwell 0.6 and we have high hopes > forthis release. Several big new features have been added as well as > a slew of > tweaks, additions, and bug fixes. Some of the more big ticket items > include: > > * Basic RAW support > * Image zooming > * PNG support > * Support for EXIF, IPTC, and XMP > * Edit with external editor > * ... and more! > > We could use your help. We're hoping to ship Shotwell 0.6 in the next two > weeks and would like to run it through its paces. We need people to > download the current revision in trunk (not the tarball) and really beat up > on it. If you're interested, follow the directions here for getting the > source and building it: > > http://www.yorba.org/shotwell/install/#source > > If you find bugs or issues -- anything that seems odd -- please feel free to > report them here on the mailing list or via our Trac ticketing system at: > > http://trac.yorba.org/ > > Thanks for your continued support! > > -- Jim Nelson > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From baldakkl at gmail.com Wed Jun 16 22:18:15 2010 From: baldakkl at gmail.com (Lorenzo Baldacchini) Date: Thu, 17 Jun 2010 00:18:15 +0200 Subject: [Shotwell] Shotwell Digest, Vol 11, Issue 15 In-Reply-To: References: Message-ID: Hi guys, I have encountered a small problem with the last svn version of shotwell. In the preferences menu, where I have to choose the external raw editor, it doesn't make me choose Bibble5, which is, obviously, installed on my system. In the menu there are the other raw editors (ufraw, darktable and rawstudio) but not Bibble5. I tried to reinstall both bibble than shotwell, but the situation doesn't change. I would suggest to add a voice "use a personal command" to choose whatever one wants (like for example in preferred application for gnome). Thank you very much for the great work that you are doing. Lorenzo 2010/6/16 : > Send Shotwell mailing list submissions to > ? ? ? ?shotwell at lists.yorba.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > or, via email, send a message with subject or body 'help' to > ? ? ? ?shotwell-request at lists.yorba.org > > You can reach the person managing the list at > ? ? ? ?shotwell-owner at lists.yorba.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Shotwell digest..." > > > Today's Topics: > > ? 1. Re: shotwell mockups(daniel planas) (Robert Ancell) > ? 2. Call for testing (Jim Nelson) > ? 3. Last Chance to Submit Translations for Shotwell 0.6 (Vera Yin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Jun 2010 09:19:45 +1000 > From: Robert Ancell > Subject: Re: [Shotwell] shotwell mockups(daniel planas) > To: shotwell at lists.yorba.org > Message-ID: <4C180A91.9050704 at canonical.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >> - lowercase button text >> >> This is a bit unusual for a GNOME application, though I myself don't >> mind this look. ?Possibly worth considering. >> >> > > Button text should always be in "header capitalization": > http://library.gnome.org/devel/hig-book/stable/controls-buttons.html.en\ > > > ------------------------------ > > Message: 2 > Date: Tue, 15 Jun 2010 19:34:35 -0700 > From: Jim Nelson > Subject: [Shotwell] Call for testing > To: shotwell > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > We've been working diligently on Shotwell 0.6 and we have high hopes > forthis release. ?Several big new features have been added as well as > a slew of > tweaks, additions, and bug fixes. ?Some of the more big ticket items > include: > > * Basic RAW support > * Image zooming > * PNG support > * Support for EXIF, IPTC, and XMP > * Edit with external editor > * ... and more! > > We could use your help. ?We're hoping to ship Shotwell 0.6 in the next two > weeks and would like to run it through its paces. ?We need people to > download the current revision in trunk (not the tarball) and really beat up > on it. ?If you're interested, follow the directions here for getting the > source and building it: > > http://www.yorba.org/shotwell/install/#source > > If you find bugs or issues -- anything that seems odd -- please feel free to > report them here on the mailing list or via our Trac ticketing system at: > > http://trac.yorba.org/ > > Thanks for your continued support! > > -- Jim Nelson > > > ------------------------------ > > Message: 3 > Date: Tue, 15 Jun 2010 19:54:15 -0700 > From: Vera Yin > Subject: [Shotwell] Last Chance to Submit Translations for Shotwell > ? ? ? ?0.6 > To: shotwell at lists.yorba.org > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset="iso-8859-1" > > Hello Friends of Shotwell, > > ? As those of you following Shotwell's development may know, Shotwell > 0.6 is due out in the next few weeks. We're very excited about this > release. It introduces a bonanza of exciting new features, like basic > support for working with RAW images, the ability to zoom into and pan > over photos to reveal latent detail, and user interface improvements > that bring new levels of polish and usability to the Shotwell > experience. > > ? A few weeks ago, we asked previous translators of Shotwell to submit > new and updated translations. The response was fantastic. That said, > we're still in need of translations for several major languages, > including Spanish, Japanese, Arabic, Portuguese, and Hindi. If you'd > like to see Shotwell available in one of these languages, we invite > you to submit or update a translation file. > > ? To make your translation a part of the Shotwell 0.6 distribution, > please submit it as a PO file by Monday, June 21 at 9:00am Pacific > Daylight Time (UTC-7), either directly in reply to this email or on > our Transifex project page at > http://www.transifex.net/projects/p/shotwell/c/default/. For your > convenience, I have attached the new Shotwell 0.6 POT strings template > file to this message. > > ? If you've never translated Shotwell before, the process is > straightforward with the right tools. Most Shotwell translators prefer > POEdit (http://www.poedit.net/), the GNOME translation tool, but some > choose LoKalize (http://userbase.kde.org/Lokalize) from the KDE > Project. Both tools are easy to use and make translation simple. If > you're creating a new translation, all you need to begin is the POT > file attached to this message. If you're updating an existing > translation, download the existing PO file for that language from our > Transifex page and start from there. > > ? We thank you for your efforts. We hope you're as excited about > Shotwell 0.6 as we are, and we wish you all the best. > > Best Regards, > Vera > > ----------------------------------------- > Vera Yin > Internationalization Engineer > Yorba Foundation > > ------------------------------ > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > End of Shotwell Digest, Vol 11, Issue 15 > **************************************** > From jim at yorba.org Wed Jun 16 23:31:12 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 16 Jun 2010 16:31:12 -0700 Subject: [Shotwell] Call for testing In-Reply-To: <4C19478E.30103@minimum.se> References: <4C19478E.30103@minimum.se> Message-ID: Hi Martin, Great work! Sounds like you've really gone through Shotwell with a fine-toothed comb. I've ticketed many of these. If you're interested in watching any or all of them, I'll let you add yourself to the appropriate cc: list. On Wed, Jun 16, 2010 at 2:52 PM, Martin Olsson wrote: > * When I do "Show in File Manager" I would like the specific > file pre-selected in the nautilus window that appears. I really > find this annoying. > I do too, but I could not find a way to launch Nautilus and have it highlight a specific file -- it would only open a directory window. If you run Nautilus from the command line ("nautilus /home/jim/test.jpg") I get this message: Could not display "/home/jim/test.jpg" The location is not a folder Maybe there's a way with Nautilus actions to have it highlight a file in the directory? I still can't find a solution to this. I've ticketed it: http://trac.yorba.org/ticket/2129 > * When I use "Set as Desktop Background" on a 2000x3000 > (i.e. non-landscape orientation) photo, only a part of the > photo is visible on my 1680x1050 screen. It's nice that you > switched from the current "scale to fit" to another approach > where you add padding instead so that the whole photo is > guaranteed to be on screen (this is much better than the > current "scale to fit width" which will sometimes crop > faces halfway through etc). Maybe you can use a PNG so that > the padding is transparent (does that mean the bgcolor in > the GNOME appearence dialog is used? not sure...) Otherwise > black is probably fine. > Our thinking is that black is a better border for photos than allowing the theme color to come through the transparency. (That's also how we display photos in full-window and fullscreen mode, for example.) I'm not sure an image with a lot of transparency would look good with many background colors. > * Workflow issue; two persons take photos at a party/trip or > whatever and later share photos with each other. Since the > photos are from the same day, Shotwell mixes the two > different sets of photos into a single event. This is a problem > because I might want to show someone just my photos. > Also, if this wasn't a party but some sort of professional > photo shot, it's critical to know which photos > where taken by whom for copyright reasons etc. > Looking at camera EXIF is not sufficient since > people might very well have the same camera. > This can be solved by implementing "autotag with tag BLAH on import" > but I would personally prefer if the default was to import > each set of photos into a named event instead. > The current code should only include photos in the same event when they're imported at the same time. That is, if you import 10 photos from a camera, Shotwell generates events for those photos. If you then import another 10 photos, you should get new events, and not photos mixed in with the old events. If you're seeing this, please let us know, that's a bug. > * Import the JPG linked below. Pango injection attack ftw! :-) > http://temp.minimum.se/shotwell_other/pango_needs_escaping.tgz > (shotwell:17678): Gtk-WARNING **: Failed to set text from markup due to > error parsing markup: Error on line 1: Entity did not end with a semicolon; > most likely you used an ampersand character without intending to start an > entity - escape ampersand as & > What you need to do is to take the tags through: > http://www.valadoc.org/glib-2.0/GLib.Markup.printf_escaped.html > > Good catch: http://trac.yorba.org/ticket/2139 I also noted this bug with your sample photo: http://trac.yorba.org/ticket/2140 > * The "Browse" button under "Preferences" would use some padding love, > it looks too compact with the image right next to the word "Browse". > I compared it to the Browse button in Rhythm Box's Preferences dialog, it looks to be only 1 or 2 pixels off. Still, I've ticketed: http://trac.yorba.org/ticket/2130 > * The Preferences dialog should be resizable. I, for one, tried to make > it bigger so I could read the full path set for "import photos to". > http://trac.yorba.org/ticket/2131 > * Pressing ALT-E, ALT-R, ALT-I in "Preferences", don't work; i.e. console > says it all: > (shotwell:18398): Gtk-WARNING **: Couldn't find a target for a mnemonic > activation. > > * Inside "Preferences"; ALT-R is bound to both "Browse"-button and > "External RAW editor". > > Both in http://trac.yorba.org/ticket/2132 > * Open a specific photo, hit F11 to go fullscreen (this makes gnome-panel > go away) > and then click "Red Eye" in the toolbar. Now gnome-panel appears again, > which is a > bit untidy. I see this on a clean Ubuntu 10.04 > Ticketed: http://trac.yorba.org/ticket/2141 > * When I do "File::Import" Shotwell asks me if I want to make copies of the > images > or link directly. However, if I drag files to the Shotwell window, it > doesn't ask > (I think it might just link to the external photo in this case which might > cause > users to accidentally delete them when they "move to trash" later on). I > think it > should ask in this case as well just to keep things clear. > This is a new change: http://trac.yorba.org/ticket/1602 We had numerous user requests for this because they felt copying was wasteful of disk resources. Drag-and-drop does offer a way to force an "ask": if you press and hold the Alt key while dragging, the cursor will turn into a question mark and the dialog appears on the drop. (This is similar to Nautilus' behavior.) > * Resize the shotwell window so that it consomes about 25% of the screen, > then moved > it to the bottom right quadrant of the screen. Select some photos and hit > "Slideshow". > Then press Escape to exit the slideshow. Now the Shotwell window has been > moved to > 0,0 instead so the Shotwell window is located in the top left quadrant of > the screen. > This is a known bug: http://trac.yorba.org/ticket/1462 > * If I open a photo and press CTRL-D to open the "Adjust" dialog. > Then I can't reach the top widget by pressing TAB (i.e. where you > move the light-point and dark-point in the histogram or whatever > those things are called). Accessibility-wise it would be nice > if this feature was usable with keyboard only setups (making it > much easier to use with screenreaders etc). > Ticketed: http://trac.yorba.org/ticket/2133 > * At the email/password screen under "File::Publish::Picasa::Login" > the keybindings ALT-E for e-mail and ALT-P for password are shown > using mnemonics but they don't work. > Ticketed: http://trac.yorba.org/ticket/2134 > * Previously, one could extract debug info to the terminal > using "SHOTWELL_LOG=1 shotwell" but now it's necessary to > use "SHOTWELL_LOG=1 SHOTWELL_LOG_FILE=:console: shotwell". > I think the latter environment variable should be set to > console by default so it works even if you use the old way. > Logging has changed a bit; Shotwell now generates a log to disk automatically (in ~/.cache/shotwell). This can be attached to tickets and is added to bug reports via Apport. Because of this, we wanted to allow the user to (a) specify where to put the file exactly, and (b) still make it available on the console. More thinking could go into how to make the log more easily accessible to interested users and developers: http://trac.yorba.org/ticket/2135 > * If I select a photo and "Photos :: Adjust Time & Date" and > change the exposure date by a large amount like a couple of > days then the photos are moved out of the current viewport > but they are still selected. I think it would be better if > you called something like viewport.scroll_to_selection() after > the exposure date has been changed, just to make sure that > the selected photos are always visible to the user. > Ticketed: http://trac.yorba.org/ticket/2136 > * I don't use AM/PM time since I live in Europe. > So I'd prefer if the "Adjust Time & Date" dialog was adjusted > to my locale and thus didn't show AM/PM but instead a 24-hour > clock. If I right click the Date+Time in gnome-panel and select > Preferences, I've got 24-hour clock configured in there so > maybe Shotwell can read this setting from > "/apps/panel/applets/clock_screen0/prefs/format" or similar? > Ticketed: http://trac.yorba.org/ticket/2137 > * The print preview dialog pre-select the "Letter" paper size > and also happily informs me that an A4 is 8.27 inch x 11.69 inch > but we use "cm" here and most europeans print on A4 papers. > This repros even if I go into "System::Administration::Language Support", > switch to the "Text" TAB and choose swedish locale there > and finally pressing apply system-wide and restarting Shotwell. > Can you tell me which tab of the Print dialog you're seeing this? We only have control over one tab, "Image Settings". Or do you mean Page Setup? Again, that's a GTK control. If you open Firefox (File -> Page Setup) do you see the same thing? > * When selecting multiple photos and then opening > "Photos::Adjust Date&Time" only one photo is shown > which is a bit confusing. It would be nice if there > was a visual cue in the UI here that clearly indicated > that this photo is just the first among the selected > photos. For example, you could render it as a stack of > photos where the second photo is showing up partially > behind the first one. > Ticketed: http://trac.yorba.org/ticket/2138 Thanks for all this great input! Hopefully some of these will be fixed in time for 0.6. -- Jim From Sebastian at SSpaeth.de Thu Jun 17 06:56:01 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Thu, 17 Jun 2010 08:56:01 +0200 Subject: [Shotwell] Shotwell reviewed in LWN References: Message-ID: <871vc6gnb2.fsf@SSpaeth.de> Dear all, I am new here. Hello! I wanted to point you to a quick grumpy editors review of shotwell: http://lwn.net/SubscriberLink/392261/b6d9e95899253392/ I am sure you have a couple of comments or trac tickets to respond :-). Thanks for shotwell, I am a happy user looking forward to: - Monitoring of my media dir (http://trac.yorba.org/ticket/374) - No zoom possibilities of pictures at all? I must be doing sth wrong - Ability to replace my original photo with the edited version (if I crop a photo, I often don't want to keep the original around) Sebastian From mweisshaupt1988 at googlemail.com Thu Jun 17 09:07:43 2010 From: mweisshaupt1988 at googlemail.com (=?ISO-8859-1?Q?Martin_Wei=DFhaupt?=) Date: Thu, 17 Jun 2010 11:07:43 +0200 Subject: [Shotwell] Call for testing In-Reply-To: References: Message-ID: <4C19E5DF.8070406@googlemail.com> Hello everyone, I tested the last revision yesterday and I found something that should be improved. Shotwell can now handle more than one profile but it seems that it doesn't store the import location separately. After I importet pictures to my second shotwell library the pictures appeared in the same location as the pictures from the first library. Then I changed the target directory in the preference window, imported some pictures and now it worked. But then I went back to my first library and looked at the preference window. There was the new location set. To make a long story short: Please store the target folder for imported pictures for every library. Regards, Martin Wei?haupt Am 16.06.2010 04:34, schrieb Jim Nelson: > Hello, > > We've been working diligently on Shotwell 0.6 and we have high hopes > forthis release. Several big new features have been added as well as > a slew of > tweaks, additions, and bug fixes. Some of the more big ticket items > include: > > * Basic RAW support > * Image zooming > * PNG support > * Support for EXIF, IPTC, and XMP > * Edit with external editor > * ... and more! > > We could use your help. We're hoping to ship Shotwell 0.6 in the next two > weeks and would like to run it through its paces. We need people to > download the current revision in trunk (not the tarball) and really beat up > on it. If you're interested, follow the directions here for getting the > source and building it: > > http://www.yorba.org/shotwell/install/#source > > If you find bugs or issues -- anything that seems odd -- please feel free to > report them here on the mailing list or via our Trac ticketing system at: > > http://trac.yorba.org/ > > Thanks for your continued support! > > -- Jim Nelson > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From brunogirin at gmail.com Thu Jun 17 10:35:49 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Thu, 17 Jun 2010 11:35:49 +0100 Subject: [Shotwell] Call for testing In-Reply-To: References: <4C19478E.30103@minimum.se> Message-ID: <1276770949.1579.35.camel@nuuk> On Wed, 2010-06-16 at 16:31 -0700, Jim Nelson wrote: > Hi Martin, > > Great work! Sounds like you've really gone through Shotwell with a > fine-toothed comb. I've ticketed many of these. If you're interested in > watching any or all of them, I'll let you add yourself to the appropriate > cc: list. > > On Wed, Jun 16, 2010 at 2:52 PM, Martin Olsson wrote: > > > * When I do "Show in File Manager" I would like the specific > > file pre-selected in the nautilus window that appears. I really > > find this annoying. > > > > I do too, but I could not find a way to launch Nautilus and have it > highlight a specific file -- it would only open a directory window. If you > run Nautilus from the command line ("nautilus /home/jim/test.jpg") I get > this message: > > Could not display "/home/jim/test.jpg" > The location is not a folder > > Maybe there's a way with Nautilus actions to have it highlight a file in the > directory? I still can't find a solution to this. I've ticketed it: > http://trac.yorba.org/ticket/2129 AFAIK, it's a Nautilus bug. I've seen a bug go past on Launchpad about this but I can't find it at the moment. You have the same problem with Firefox for example: if you open the download window, select a file, right-click and select "open containing folder", it will open the folder but not select the file. Bruno From douglas.m.stanley at gmail.com Thu Jun 17 12:18:16 2010 From: douglas.m.stanley at gmail.com (Douglas Stanley) Date: Thu, 17 Jun 2010 08:18:16 -0400 Subject: [Shotwell] Photos not getting copied to photo library... In-Reply-To: <4C16783A.1040607@yorba.org> References: <4C165311.1040909@yorba.org> <4C16783A.1040607@yorba.org> Message-ID: I just wanted to send an update. It was in fact what you suspected, and my pictures dir in ~/.config/user-dirs.dirs was set to my home directory! Not sure how that happened, but that was in fact the problem after all. Thank you very much for your quick responses. I'm always happy to see such an active community around such great software! Keep up the good work! Dougg On Mon, Jun 14, 2010 at 2:43 PM, Adam Dingle wrote: > Doug, > > On 06/14/2010 09:17 AM, Douglas Stanley wrote: >> >> Well, I was trying to import new photos, ones that hadn't been >> imported before. But I remember one time it sort of worked, and >> imported them into my $HOME dir. I then removed them and tried >> re-importing, but then never imported after that. I will double check >> the value in the ~/.config/user-dirs.dirs file, to see if that was the >> cause. >> >> I know I tried importing them straight from the SD card though, which >> wouldn't have been located under my home dir. It just copied the path >> to the SD card into the shotwell DB. >> > > Odd. ?If you can come up with a reproducible case in which photos imported > from an SD card are not copied, and the SD card path is not under your > XDG_PICTURES_DIR, then we'd certainly be interested to hear about it. > >>> If you've built Shotwell from trunk (soon to become 0.6) then the >>> situation is a little better: you can use Edit->Preferences to view and >>> change the library directory. ?Furthermore, the trunk build will warn >>> you if your library directory is your home directory since that's >>> probably not what you want. >>> >> >> I was using shotwell 0.5 from ubuntu repos. When 0.6 comes out, any >> chance there will be an ubuntu ppa for it? >> > > Yes. ?As soon as we release Shotwell 0.6 we will also make it available in > the Yorba PPA at https://launchpad.net/~yorba/+archive/ppa . > >> >> The tip about where the photo library path is stored, is gold in >> itself! That really should be in a wiki or something :) >> > > Good point. ?I've just added this information to the Shotwell documentation > at http://trac.yorba.org/wiki/UsingShotwell0.5 . > > adam > > -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From bengt at thuree.com Thu Jun 17 12:20:31 2010 From: bengt at thuree.com (Bengt Thuree) Date: Thu, 17 Jun 2010 22:20:31 +1000 Subject: [Shotwell] Location and search? Message-ID: <1276777231.2581.238.camel@lappis> Hi Guys Just wondering when import of Location data will be considered/implemented? Also, searching with boolean algorithm among the tags, and meta data. I know not for this release, but hopefully before next release, or? /Bengt p.s. Will definitely test latest SVN version tonight... :) From adam at yorba.org Thu Jun 17 16:57:36 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 17 Jun 2010 09:57:36 -0700 Subject: [Shotwell] Call for testing In-Reply-To: <4C19E5DF.8070406@googlemail.com> References: <4C19E5DF.8070406@googlemail.com> Message-ID: <4C1A5400.7040909@yorba.org> On 06/17/2010 02:07 AM, Martin Wei?haupt wrote: > Hello everyone, > > I tested the last revision yesterday and I found something that should > be improved. > > Shotwell can now handle more than one profile but it seems that it > doesn't store the import location separately. > After I importet pictures to my second shotwell library the pictures > appeared in the same location as the pictures from the first library. > > Then I changed the target directory in the preference window, imported > some pictures and now it worked. > But then I went back to my first library and looked at the preference > window. There was the new location set. > > To make a long story short: Please store the target folder for imported > pictures for every library. > Martin, that's a reasonable suggestion - I've ticketed this at http://trac.yorba.org/ticket/2146 . Not yet sure if this will make 0.6, but it would be nice to fix this if possible. adam From c.dupaty at free.fr Thu Jun 17 17:07:02 2010 From: c.dupaty at free.fr (Charles) Date: Thu, 17 Jun 2010 19:07:02 +0200 Subject: [Shotwell] Red-Eyes Message-ID: <4C1A5636.8000502@free.fr> Hello, I'm a new user of Shotwell and I like it, but, I have a problem with the red-eyes adjustment : the red pupil is replaced by light-grey pupil, which looks like dead eye. the best solution would be possibilty of choice of the new nuance (from white to black) of the pupil, or simply, change the light grey by dark grey (in fact pupils are black, isn't it ?) sorry for my bad bad english, but I hope you will understand From adam at yorba.org Thu Jun 17 17:43:11 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 17 Jun 2010 10:43:11 -0700 Subject: [Shotwell] Shotwell Digest, Vol 11, Issue 15 In-Reply-To: References: Message-ID: <4C1A5EAF.6030601@yorba.org> On 06/16/2010 03:18 PM, Lorenzo Baldacchini wrote: > Hi guys, > I have encountered a small problem with the last svn version of shotwell. > In the preferences menu, where I have to choose the external raw > editor, it doesn't make me choose Bibble5, which is, obviously, > installed on my system. > In the menu there are the other raw editors (ufraw, darktable and > rawstudio) but not Bibble5. > I tried to reinstall both bibble than shotwell, but the situation > doesn't change. > I would suggest to add a voice > "use a personal command" to choose whatever one wants (like for > example in preferred application for gnome). > Thank you very much for the great work that you are doing. > Lorenzo > Lorenzo, thanks for your suggestion. Today, Shotwell allows you to choose any external editor which has registered itself as handling the MIME types that represent images. In other words, Shotwell lets you choose any editor which shows up in the "Open With" context menu when you right click the image file in Nautilus. We agree that it would be nice to be able to choose other editors as well - we have a ticket for this at http://trac.yorba.org/ticket/2014 . This won't make 0.6, but hopefully we'll get to this before too long. adam From jim at yorba.org Thu Jun 17 17:54:41 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 17 Jun 2010 10:54:41 -0700 Subject: [Shotwell] Shotwell reviewed in LWN In-Reply-To: <871vc6gnb2.fsf@SSpaeth.de> References: <871vc6gnb2.fsf@SSpaeth.de> Message-ID: No comments about the review, but to answer your other questions: - No zoom possibilities of pictures at all? I must be doing sth wrong > Zoom is in trunk and will be available when 0.6 is released. > - Ability to replace my original photo with the edited version (if I > crop a photo, I often don't want to keep the original around) > We've considered a few variations of this and decided to postpone it until we have a better fix on how to do this right: http://trac.yorba.org/ticket/1798 -- Jim From adam at yorba.org Thu Jun 17 18:26:36 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 17 Jun 2010 11:26:36 -0700 Subject: [Shotwell] Location and search? In-Reply-To: <1276777231.2581.238.camel@lappis> References: <1276777231.2581.238.camel@lappis> Message-ID: <4C1A68DC.60306@yorba.org> On 06/17/2010 05:20 AM, Bengt Thuree wrote: > Hi Guys > > Just wondering when import of Location data will be > considered/implemented? > > Also, searching with boolean algorithm among the tags, and meta data. > I know not for this release, but hopefully before next release, or? > > Bengt, it's still undecided when these features will happen. We're currently focused on getting 0.6 out the door in the next week or two. Once that happens, we'll discuss features for 0.7, and it would be nice to put together a tentative roadmap that includes 0.8 as well. And of course we'd like to involve the Shotwell community in that discussion on this mailing list. Of course, if anyone out there wants to work on these features then they will happen sooner than they would otherwise. :) cheers adam From lucas at yorba.org Thu Jun 17 19:15:34 2010 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 17 Jun 2010 12:15:34 -0700 Subject: [Shotwell] Red-Eyes In-Reply-To: <4C1A5636.8000502@free.fr> References: <4C1A5636.8000502@free.fr> Message-ID: Hi Charles, First, thank you very much for your interest in Shotwell! I appreciate your comments and suggestions about the functionality of the red-eye tool. To address your points: > the best solution would be possibilty of choice of the new nuance (from > white to black) of the pupil We could consider this for an upcoming release of Shotwell. Indeed, I've ticketed it here: http://trac.yorba.org/ticket/2148 . > the red pupil is replaced by light-grey pupil, which looks like dead eye ... > in fact pupils are black, isn't it? Yes, pupils are black, but the viewer rarely perceives them as black. This is because the surface of the human eye is moist and highly reflective. As a result, pupils are shiny and reflect light very well. So most of the time, they appear to be a gunmetal or lead gray color. What's more, because they are so shiny, pupils have a reflectance distribution across their surface. So some areas of the pupil will be silvery-white because of the light they reflect while others will appear jet-black. When we designed the red-eye feature in Shotwell, it was very important to us to try to maintain this natural distribution of reflected light. So we don't just fill the pixels with black or gray like some other programs. Instead, we attempt to extract luminance information from the green and blue channels and transfer it evenly into the red channel, thus preserving the natural highlights of the pupil. This is why your pupil appears light gray. It's not an artifact of Shotwell. It's the way the pupil was naturally lit. Does that make sense? Take care, Lucas -------------------------------- Lucas Beeler Software Designer Yorba Foundation From mnemo at minimum.se Thu Jun 17 21:35:14 2010 From: mnemo at minimum.se (Martin Olsson) Date: Thu, 17 Jun 2010 23:35:14 +0200 Subject: [Shotwell] Call for testing In-Reply-To: References: <4C19478E.30103@minimum.se> Message-ID: <4C1A9512.3030902@minimum.se> On 06/17/2010 01:31 AM, Jim Nelson wrote: >> * When I use "Set as Desktop Background" on a 2000x3000 >> (i.e. non-landscape orientation) photo, only a part of the >> photo is visible on my 1680x1050 screen. It's nice that you >> switched from the current "scale to fit" to another approach >> where you add padding instead so that the whole photo is >> guaranteed to be on screen (this is much better than the >> current "scale to fit width" which will sometimes crop >> faces halfway through etc). Maybe you can use a PNG so that >> the padding is transparent (does that mean the bgcolor in >> the GNOME appearence dialog is used? not sure...) Otherwise >> black is probably fine. >> > > Our thinking is that black is a better border for photos than allowing the > theme color to come through the transparency. (That's also how we display > photos in full-window and fullscreen mode, for example.) I'm not sure an > image with a lot of transparency would look good with many background > colors. The note about the color of the padding was just an extra not, the bug is about Shotwell using "scale to width" rather than adding padding. Or did you mean that there was an existing ticket for the "scale to width" issue? If so what was the bug no (I can't find it). For example if you download and import this photo and use set as desktop background, then Shotwell crops the _ball_ out of a basket ball image: http://www.pe.com/imagesdaily/2008/04-24/lakers24dwba_300.jpg Well, to get the buggy effect I guess you need to have "Style == Scale" set under System::Preferences::Appearence (this is the default setting for Ubuntu 10.04). So actually, I think what needs to happen is that when you set the desktop background itself you also need to set the "style" option and the "solid background color" in the GNOME Appearance dialog as well (you can probably not get away with just adding the padding as extra black pixels in the image because then it will look bad if the user changes resolution so setting the solid bgcolor to black is more versatile). >> * Workflow issue; two persons take photos at a party/trip or >> whatever and later share photos with each other. Since the >> photos are from the same day, Shotwell mixes the two >> different sets of photos into a single event. This is a problem >> because I might want to show someone just my photos. >> Also, if this wasn't a party but some sort of professional >> photo shot, it's critical to know which photos >> where taken by whom for copyright reasons etc. >> Looking at camera EXIF is not sufficient since >> people might very well have the same camera. >> This can be solved by implementing "autotag with tag BLAH on import" >> but I would personally prefer if the default was to import >> each set of photos into a named event instead. >> > > The current code should only include photos in the same event when they're > imported at the same time. That is, if you import 10 photos from a camera, > Shotwell generates events for those photos. If you then import another 10 > photos, you should get new events, and not photos mixed in with the old > events. If you're seeing this, please let us know, that's a bug. Ah I accidently looked at the photos view. You're right, it's not a bug. >> * The print preview dialog pre-select the "Letter" paper size >> and also happily informs me that an A4 is 8.27 inch x 11.69 inch >> but we use "cm" here and most europeans print on A4 papers. >> This repros even if I go into "System::Administration::Language Support", >> switch to the "Text" TAB and choose swedish locale there >> and finally pressing apply system-wide and restarting Shotwell. >> > > Can you tell me which tab of the Print dialog you're seeing this? We only > have control over one tab, "Image Settings". Or do you mean Page Setup? > Again, that's a GTK control. If you open Firefox (File -> Page Setup) do > you see the same thing? Oh, right. If I start using: LANGUAGE=sv ./shotwell ...I get the right paper size etc so no bug here either. Martin From adam at yorba.org Thu Jun 17 22:58:21 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 17 Jun 2010 15:58:21 -0700 Subject: [Shotwell] Shotwell reviewed in LWN In-Reply-To: <871vc6gnb2.fsf@SSpaeth.de> References: <871vc6gnb2.fsf@SSpaeth.de> Message-ID: <4C1AA88D.2030604@yorba.org> On 06/16/2010 11:56 PM, Sebastian Spaeth wrote: > Dear all, I am new here. Hello! > > I wanted to point you to a quick grumpy editors review of shotwell: > > http://lwn.net/SubscriberLink/392261/b6d9e95899253392/ > > I am sure you have a couple of comments or trac tickets to respond :-). > Sebastian, thanks for the link to the LWN review! FYI I just posted a response on that page, which I'll also include here: === Grumpy Editor, I'm the founder of Yorba (makers of Shotwell) and have been deeply involved in Shotwell's design from day one. Thanks a lot for trying out Shotwell and for the candid and thorough review. We always appreciate direct feedback and are happy to hear about what people do and do not like. Grumpy Editor, your review touched on various points about Shotwell, but of course your biggest gripe was about the way Shotwell imports photos and about the relationship between the Shotwell photo library and the file system. I'll first provide brief feedback about some of the smaller points: - You mentioned the lack of support for RAW photos and zooming into photos. Both of these features have been impemented in trunk and will be present in the Shotwell 0.6 release (coming in the next two weeks). - As someone else pointed out in another comment, it actually is possible to split an event apart in Shotwell: simply select the photos you'd like to split into a separate event, then choose Events->New Event. - It actually is possible to remove a tag from several photos at once. Simply select the tag in the sidebar, then select the photos you'd like to remove it from and choose Tags->Remove Tags From Photos. - We do hope to implement hierarchical tags at some point (that's http://trac.yorba.org/ticket/1401, if you're curious). OK, and now on to your Major Concern. As you pointed out in your review, Shotwell expects you to import all photos into its library. As you do so, Shotwell indexes their metadata so you can search them in various ways. You can edit photos in Shotwell, but normally your changes stay in the Shotwell universe. Changes get written to files only when you export (or, in Shotwell 0.6, when you use Shotwell's Open in External Editor command, which writes pending changes to a file and then opens an external program such as GIMP on it). The Shotwell model is common among commercial photo programs; iPhoto, Aperture and (to some degree) Picasa all work this way, for instance. But clearly you want a photo program to use a different model. You'd like to be able to browse through photos easily according to their on-disk file hierarchy, and presumably you'd like photo edits and metadata to be stored in the photo files themselves, at all times. I imagine you'd also like to be able to search for all photos matching a given tag or in a given date range. For this to be possible, a photo program must of course index the on-disk photos, which is itself a form of importing, really. But it sounds like you're opposed to an explicit import step. (Perhaps you'd like to point a photo program at your top-level photo directory and let it index everything in the background. Or maybe you'd like a photo program to automatically index all the photos in directories which the user browses through.) So, then, which model is superior? We built Shotwell to use explicit importing and to store edits in its own database both because other popular programs work that way and because certain users have told us they want us never to touch their originals (see, for example, the discussion at http://lists.yorba.org/pipermail/shotwell/2010-April/0002... ). But recently we've been getting more and more feedback from people like you who want a storage model based directly on the filesystem (see, for example, http://ubuntuforums.org/showthread.php?p=9475456 or https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/5... ). So I've actually become less and less sure that we've gotten this right, and I think it's likely that we'll switch to something like your preferred storage model in a not-too-distant release, at least as an option for the user. In fact, different users seem to have distinctly different storage preferences, and so perhaps we can even evolve Shotwell to the point where the user can choose where data is stored. For example, a user might want us to store metadata (e.g. photo titles/keywords) either in the original files, in sidecar XMP files, in the Shotwell database, or in Tracker. It might be cool if Shotwell could do any of these as you please. As you mentioned, Shotwell is a young utility. We do in fact plan to evolve it to work more flexibly together with other Linux tools, so thanks again for the feedback and please keep your eyes open for future Shotwell developments! Cheers, adam === From c.dupaty at free.fr Thu Jun 17 21:59:05 2010 From: c.dupaty at free.fr (Charles) Date: Thu, 17 Jun 2010 23:59:05 +0200 Subject: [Shotwell] Red-Eyes In-Reply-To: References: <4C1A5636.8000502@free.fr> Message-ID: <4C1A9AA9.10607@free.fr> thank you for your explanations, yes, it makes sense, I can see that there are nuances in the grey of the corrected eye, which was very bright when red, but the result looks like dead eye, specially with large pupils, i join a photo of my dog, with a red eye and a corrected eye, and the original with 2 red eyes. Possibility of making the eye darker would arrange this feeling of dead eye Le 17/06/2010 21:15, Lucas Beeler a ?crit : > Hi Charles, > > First, thank you very much for your interest in Shotwell! I appreciate > your comments and suggestions about the functionality of the red-eye > tool. To address your points: > > >> the best solution would be possibilty of choice of the new nuance (from >> white to black) of the pupil >> > We could consider this for an upcoming release of Shotwell. Indeed, > I've ticketed it here: http://trac.yorba.org/ticket/2148 . > > >> the red pupil is replaced by light-grey pupil, which looks like dead eye ... >> in fact pupils are black, isn't it? >> > Yes, pupils are black, but the viewer rarely perceives them as black. > This is because the surface of the human eye is moist and highly > reflective. As a result, pupils are shiny and reflect light very well. > So most of the time, they appear to be a gunmetal or lead gray color. > What's more, because they are so shiny, pupils have a reflectance > distribution across their surface. So some areas of the pupil will be > silvery-white because of the light they reflect while others will > appear jet-black. > > When we designed the red-eye feature in Shotwell, it was very > important to us to try to maintain this natural distribution of > reflected light. So we don't just fill the pixels with black or gray > like some other programs. Instead, we attempt to extract luminance > information from the green and blue channels and transfer it evenly > into the red channel, thus preserving the natural highlights of the > pupil. This is why your pupil appears light gray. It's not an artifact > of Shotwell. It's the way the pupil was naturally lit. Does that make > sense? > > Take care, > Lucas > > -------------------------------- > Lucas Beeler > Software Designer > Yorba Foundation > From lucas at yorba.org Thu Jun 17 23:17:25 2010 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 17 Jun 2010 16:17:25 -0700 Subject: [Shotwell] Red-Eyes In-Reply-To: <4C1A9AA9.10607@free.fr> References: <4C1A5636.8000502@free.fr> <4C1A9AA9.10607@free.fr> Message-ID: Hi Charles, Thanks for the photos of your dog! What's going on in this photo is that the reflection of the flash caused the eye (by far the most reflective object in the photo) to become over-exposed. This is a flash-flare problem that is more significant than just red-eye distortion. I agree with you that we should try to correct this kind of problem in Shotwell. This will come when we implement the fix described in Shotwell ticket #2148 (http://trac.yorba.org/ticket/2148), which I created this morning in response to your initial question. Take care, Lucas From dkorzhevin at lsupport.net Thu Jun 17 23:39:46 2010 From: dkorzhevin at lsupport.net (Dmitry Korzhevin) Date: Fri, 18 Jun 2010 02:39:46 +0300 Subject: [Shotwell] Parameters of image comparison Message-ID: <4C1AB242.8040306@lsupport.net> Hello Please tell me, how Shotwell compares images for similarity? Estimated values: file name, date snapshot of the EXIF, the file size ... -- Best regards, Dmitry Korzhevin Tel: +38 (039) 295-0000 Office Phone: +38 (044) 383-14-12 E-mail: dkorzhevin at lsupport.net Jabber ID: dkorzhevin at lsupport.net Skype: dkorzhevin URL: http://lsupport.net Linux Support LLC From brunogirin at gmail.com Fri Jun 18 00:10:21 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 18 Jun 2010 01:10:21 +0100 Subject: [Shotwell] Parameters of image comparison In-Reply-To: <4C1AB242.8040306@lsupport.net> References: <4C1AB242.8040306@lsupport.net> Message-ID: <1276819821.2701.15.camel@nuuk> On Fri, 2010-06-18 at 02:39 +0300, Dmitry Korzhevin wrote: > Hello > > Please tell me, how Shotwell compares images for similarity? Estimated > values: file name, date snapshot of the EXIF, the file size ... > If you are referring to how Shotwell identifies duplicates, it uses an MD5 hash of the image's binary data. Bruno From vperetokin at gmail.com Fri Jun 18 00:18:07 2010 From: vperetokin at gmail.com (Vadim Peretokin) Date: Thu, 17 Jun 2010 20:18:07 -0400 Subject: [Shotwell] Shotwell reviewed in LWN In-Reply-To: <4C1AA88D.2030604@yorba.org> References: <871vc6gnb2.fsf@SSpaeth.de> <4C1AA88D.2030604@yorba.org> Message-ID: That's great :) From mordred at inaugust.com Fri Jun 18 00:40:17 2010 From: mordred at inaugust.com (Monty Taylor) Date: Thu, 17 Jun 2010 17:40:17 -0700 Subject: [Shotwell] Shotwell reviewed in LWN In-Reply-To: References: <871vc6gnb2.fsf@SSpaeth.de> <4C1AA88D.2030604@yorba.org> Message-ID: <4C1AC071.6080601@inaugust.com> On 06/17/2010 05:18 PM, Vadim Peretokin wrote: > That's great :) ++ Well written. From lutimdale at yahoo.com Fri Jun 18 03:42:28 2010 From: lutimdale at yahoo.com (Lu Timdale) Date: Thu, 17 Jun 2010 20:42:28 -0700 (PDT) Subject: [Shotwell] Shotwell 0.5 Impressions of a New User Message-ID: <828528.99582.qm@web33707.mail.mud.yahoo.com> I think this application shows the most promise from any linux based photo manager thus far. Things I liked a lot: - I like the concept of events and the way it is filtered based on date. I love "mark key photo for event". - Speed. This app is fast. Everything seems to sing. 'nuff said. - I love merge events. Select 2 events, right-click, merge. Beautiful. Similarly creating a new event from a subset of pictures. This one is not obvious though... have to select Event > New Event from menu. A right-click option would be good here. - when selecting multiple events, the status on bottom left was intelligent and let you know from/to dates. Nice touch. Similarly for selecting photos. - the general feel of the app is that it is well thought out and what is there works well. Things that need to be fixed: - red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. - I was confused that when renaming an event, it didn't bring in the current name of the event (the date), but a blank entry dialog. When I typed something, it overwrote the date... no way to get it back in the same format. I personally like to name my events "date + name"... for example "2010-01-01 New Years Day" - I was really confused as to where the files were stored. Import didn't really tell me where they were imported to, and I couldn't find it within the filesystem. There is no preference for the file location. There is no right click option to locate the file. - rotate needs to be both ways... cannot click 3 times to rotate to the left. - when looking at an individual picture, it is unclear how to get back to the gallery (especially the same spot you were in before). A "back to gallery" button could help here. - when I enhanced a picture, I didn't understand if it was saved or not. I think most people don't care about storing multiple copies of pictures... they want to fix their pictures and move on. I think a "Save Changes" button or prompt would fix this issue. I would like to see: - nesting of tags (eg. Family > Kids > Johnny) where tagging something with Family only works as well. Filtering by Family brings in everything explicitly tagged as family, but also all the nested tags under family - import rolls. At the very least, the last imported role. THis should be a high level folder along with Photos, Events, Tags. "Recently Imported" probably makes sense here. - Favorites as a top level item. It is a bit confusing to click on Photos, then select "View > only favorites". Ideally, it would be based on a 1 to 4 star system, not just one star. This would be similar to nesting of tags, where selecting 2 stars gives you everything 2 stars and above. - when viewing a single photo, the controls can all be on the left pane instead of showing the hierarchy, which doesn't apply for the individual photo. - View by filesystem as a top level tier. Currently you get only all via photos. As mentioned above, it would be ideal if renaming an event a) renamed the folder the photos were contained in (eg. 2010-01-01 New Year's Eve) and b) renamed the pictures to a similar format "2010-01-01 New Year's Eve 001.jpg" The filesystem view should show all folders nested under the currently selected folder, separated by the name of the folder containing those files. - if allowing file system view, events do not need to be renamed. Events become a date view. Events should be the file system view... no? - Import should be file system based (organize by folder) and this should be configurable. Pictures/2010/2010-01-01 New Year's Eve/ or Pictures/2010/01/New Year's Eve or whatever format a user wants. I cannot stress how important this is. This is required for archival purposes. You should not need Shotwell 10 years from now to be able to view your organized photos. I should also be able to import my pictures, organize them, and be able to browse them intelligently in the file manager. That's all for me. I hope this application gets some of the changes mentioned. There is no good enough application on linux for importing/managing photos yet at the filesystem level. I have been using Linux on the desktop for 2 years. Believe it or not, I still use Windows PHoto Gallery within a VirtualBox/windows vm to import my photos. Please help me get rid of this dependency. Thanks. Lu Timdale lutimdale at yahoo.com From vperetokin at gmail.com Fri Jun 18 03:47:37 2010 From: vperetokin at gmail.com (Vadim Peretokin) Date: Thu, 17 Jun 2010 23:47:37 -0400 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <828528.99582.qm@web33707.mail.mud.yahoo.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> Message-ID: Why would you, as a user, ever need to worry as to where import goes? I don't fully know where my programs are installed to, and frankly I'm glad I don't have to worth about that. Same here. On Jun 17, 2010 11:42 PM, "Lu Timdale" wrote: I think this application shows the most promise from any linux based photo manager thus far. Things I liked a lot: - I like the concept of events and the way it is filtered based on date. I love "mark key photo for event". - Speed. This app is fast. Everything seems to sing. 'nuff said. - I love merge events. Select 2 events, right-click, merge. Beautiful. Similarly creating a new event from a subset of pictures. This one is not obvious though... have to select Event > New Event from menu. A right-click option would be good here. - when selecting multiple events, the status on bottom left was intelligent and let you know from/to dates. Nice touch. Similarly for selecting photos. - the general feel of the app is that it is well thought out and what is there works well. Things that need to be fixed: - red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. - I was confused that when renaming an event, it didn't bring in the current name of the event (the date), but a blank entry dialog. When I typed something, it overwrote the date... no way to get it back in the same format. I personally like to name my events "date + name"... for example "2010-01-01 New Years Day" - I was really confused as to where the files were stored. Import didn't really tell me where they were imported to, and I couldn't find it within the filesystem. There is no preference for the file location. There is no right click option to locate the file. - rotate needs to be both ways... cannot click 3 times to rotate to the left. - when looking at an individual picture, it is unclear how to get back to the gallery (especially the same spot you were in before). A "back to gallery" button could help here. - when I enhanced a picture, I didn't understand if it was saved or not. I think most people don't care about storing multiple copies of pictures... they want to fix their pictures and move on. I think a "Save Changes" button or prompt would fix this issue. I would like to see: - nesting of tags (eg. Family > Kids > Johnny) where tagging something with Family only works as well. Filtering by Family brings in everything explicitly tagged as family, but also all the nested tags under family - import rolls. At the very least, the last imported role. THis should be a high level folder along with Photos, Events, Tags. "Recently Imported" probably makes sense here. - Favorites as a top level item. It is a bit confusing to click on Photos, then select "View > only favorites". Ideally, it would be based on a 1 to 4 star system, not just one star. This would be similar to nesting of tags, where selecting 2 stars gives you everything 2 stars and above. - when viewing a single photo, the controls can all be on the left pane instead of showing the hierarchy, which doesn't apply for the individual photo. - View by filesystem as a top level tier. Currently you get only all via photos. As mentioned above, it would be ideal if renaming an event a) renamed the folder the photos were contained in (eg. 2010-01-01 New Year's Eve) and b) renamed the pictures to a similar format "2010-01-01 New Year's Eve 001.jpg" The filesystem view should show all folders nested under the currently selected folder, separated by the name of the folder containing those files. - if allowing file system view, events do not need to be renamed. Events become a date view. Events should be the file system view... no? - Import should be file system based (organize by folder) and this should be configurable. Pictures/2010/2010-01-01 New Year's Eve/ or Pictures/2010/01/New Year's Eve or whatever format a user wants. I cannot stress how important this is. This is required for archival purposes. You should not need Shotwell 10 years from now to be able to view your organized photos. I should also be able to import my pictures, organize them, and be able to browse them intelligently in the file manager. That's all for me. I hope this application gets some of the changes mentioned. There is no good enough application on linux for importing/managing photos yet at the filesystem level. I have been using Linux on the desktop for 2 years. Believe it or not, I still use Windows PHoto Gallery within a VirtualBox/windows vm to import my photos. Please help me get rid of this dependency. Thanks. Lu Timdale lutimdale at yahoo.com _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From lutimdale at yahoo.com Fri Jun 18 03:50:34 2010 From: lutimdale at yahoo.com (Lu Timdale) Date: Thu, 17 Jun 2010 20:50:34 -0700 (PDT) Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: References: <828528.99582.qm@web33707.mail.mud.yahoo.com> Message-ID: <509220.54733.qm@web33705.mail.mud.yahoo.com> Because I don't backup or share my installed programs. I definitely browse my photos via the filesystem, back them up, and share a subset of them with others. Thanks. Lu Timdale lutimdale at yahoo.com ________________________________ From: Vadim Peretokin To: Lu Timdale Cc: shotwell at lists.yorba.org Sent: Thu, June 17, 2010 11:47:37 PM Subject: Re: [Shotwell] Shotwell 0.5 Impressions of a New User Why would you, as a user, ever need to worry as to where import goes? I don't fully know where my programs are installed to, and frankly I'm glad I don't have to worth about that. Same here. On Jun 17, 2010 11:42 PM, "Lu Timdale" wrote: > >I think this application shows the most promise from any linux based photo manager thus far. > > >>Things I liked a lot: > >>- I like the concept of events and the way it is filtered based on date. I love "mark key photo for event". > >>- Speed. This app is fast. Everything seems to sing. 'nuff said. > >>- I love merge events. Select 2 events, right-click, merge. Beautiful. >>Similarly creating a new event from a subset of pictures. This one is not obvious though... have to select Event > New Event from menu. A right-click option would be good here. > >>- when selecting multiple events, the status on bottom left was intelligent and let you know from/to dates. Nice touch. Similarly for selecting photos. > >>- the general feel of the app is that it is well thought out and what is there works well. > > > >>Things that need to be fixed: >>- red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. > >>- I was confused that when renaming an event, it didn't bring in the current name of the event (the date), but a blank entry dialog. When I typed something, it overwrote the date... no way to get it back in the same format. I personally like to name my events "date + name"... for example "2010-01-01 New Years Day" > >>- I was really confused as to where the files were stored. Import didn't really tell me where they were imported to, and I couldn't find it within the filesystem. There is no preference for the file location. There is no right click option to locate the file. > >>- rotate needs to be both ways... cannot click 3 times to rotate to the left. > >>- when looking at an individual picture, it is unclear how to get back to the gallery (especially the same spot you were in before). A "back to gallery" button could help here. > >>- when I enhanced a picture, I didn't understand if it was saved or not. I think most people don't care about storing multiple copies of pictures... they want to fix their pictures and move on. I think a "Save Changes" button or prompt would fix this issue. > > >>I would like to see: >>- nesting of tags (eg. Family > Kids > Johnny) where tagging >>something with Family only works as well. Filtering by Family brings in everything explicitly tagged as family, but also all the nested tags >>under family > >>- import rolls. At the very least, the last imported role. THis should be a high level folder along with Photos, Events, Tags. "Recently >>Imported" probably makes sense here. > >>- Favorites as a top level item. It is a bit confusing to click on >>Photos, then select "View > only favorites". Ideally, it would be >>based on a 1 to 4 star system, not just one star. This would be similar to nesting of tags, where selecting 2 stars gives you everything 2 >>stars and above. > >>- when viewing a single photo, the controls can all be on the left pane instead of showing the hierarchy, which doesn't apply for the individual photo. > >>- View by filesystem as a top level tier. Currently you get only all via photos. As mentioned above, it would be ideal if renaming an event >>a) renamed the folder the photos were contained in (eg. 2010-01-01 New Year's Eve) and >>b) renamed the pictures to a similar format "2010-01-01 New Year's Eve 001.jpg" >>The filesystem view should show all folders nested under the currently selected folder, separated by the name of the folder containing those files. > >>- if allowing file system view, events do not need to be renamed. Events become a date view. Events should be the file system view... no? > >>- Import should be file system based (organize by folder) and this should be configurable. >>Pictures/2010/2010-01-01 New Year's Eve/ >>or >>Pictures/2010/01/New Year's Eve >>or whatever format a user wants. >>I cannot stress how important this is. This is required for archival purposes. You should not need Shotwell 10 years from now to be able to view your organized photos. I should also be able to import my pictures, organize them, and be able to browse them intelligently in the file manager. > > >>That's all for me. I hope this application gets some of the changes mentioned. There is no good enough application on linux for importing/managing photos yet at the filesystem level. I have been using Linux on the desktop for 2 years. Believe it or not, I still use Windows PHoto Gallery within a VirtualBox/windows vm to import my photos. Please help me get rid of this dependency. > >>Thanks. > > >> Lu Timdale >lutimdale at yahoo.com > > > >>_______________________________________________ >>Shotwell mailing list >Shotwell at lists.yorba.org >http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Fri Jun 18 14:31:13 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 18 Jun 2010 07:31:13 -0700 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <828528.99582.qm@web33707.mail.mud.yahoo.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> Message-ID: <4C1B8331.5040101@yorba.org> Lu, On 06/17/2010 08:42 PM, Lu Timdale wrote: > I think this application shows the most promise from any linux based photo manager thus far. > Thanks! > - I love merge events. Select 2 events, right-click, merge. Beautiful. > Similarly creating a new event from a subset of pictures. This one is not obvious though... have to select Event> New Event from menu. A right-click option would be good here. > It's true that the New Event command is slightly hard to discover. We've tried to keep our context menus short by including only the most commonly used commands, and we haven't included this command for now because we think users won't use it too often. > Things that need to be fixed: > - red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. > I'll leave it to Lucas, our red eye expert, to respond to this point. :) > - I was confused that when renaming an event, it didn't bring in the current name of the event (the date), but a blank entry dialog. When I typed something, it overwrote the date... no way to get it back in the same format. I personally like to name my events "date + name"... for example "2010-01-01 New Years Day" > If you give an event a name, Shotwell uses that name; otherwise Shotwell uses the event's date. So if you want to return an event to the state where Shotwell displays its date, simply edit the event's name and delete the entire name. It's true that Shotwell doesn't give you any way to use your preferred format "2010-01-01 New Year's Day" easily. Perhaps at some point we could provide an option to display both the date and the user-specified name. > - I was really confused as to where the files were stored. Import didn't really tell me where they were imported to, and I couldn't find it within the filesystem. There is no preference for the file location. There is no right click option to locate the file. > As described in the Shotwell documentation at http://trac.yorba.org/wiki/UsingShotwell0.5, Shotwell 0.5 stores your photo library in the XDG Pictures directory. The XDG Pictures location is specified as XDG_PICTURES_DIR in ~/.config/user-dirs.dirs. Usually XDG_PICTURES_DIR is ~/Pictures . In Shotwell 0.6, which will be released in the next two weeks, there is a preference for the file location and a right click option to locate the file. These features are implemented in the trunk, so if you'd like them now you can build from source, or you can just wait for the 0.6 release. > - rotate needs to be both ways... cannot click 3 times to rotate to the left. > The Photos menu contains Rotate Left and Rotate Right commands. As described in the Shotwell documentation, you can also rotate right by clicking on the Rotate toolbar button, or rotate left by holding Ctrl and clicking on the same button. In Shotwell 0.6, the '[' and ']' keyboard shortcuts also map to Rotate Left and Rotate Right. > - when looking at an individual picture, it is unclear how to get back to the gallery (especially the same spot you were in before). A "back to gallery" button could help here. > As you probably figured out, you can either double click the photo or press Escape. It's true we could add a "back to gallery" button, though I doubt anyone would ever use it once they've realized they can double click or press Escape. > - when I enhanced a picture, I didn't understand if it was saved or not. I think most people don't care about storing multiple copies of pictures... they want to fix their pictures and move on. I think a "Save Changes" button or prompt would fix this issue. > Yes - a number of users have complained about this. We'll try to improve the situation in 0.7. > > I would like to see: > - nesting of tags (eg. Family> Kids> Johnny) where tagging > something with Family only works as well. Filtering by Family brings in everything explicitly tagged as family, but also all the nested tags > under family > We'd like this too. This is http://trac.yorba.org/ticket/1401 . > - import rolls. At the very least, the last imported role. THis should be a high level folder along with Photos, Events, Tags. "Recently > Imported" probably makes sense here. > Agreed. We have tickets at http://trac.yorba.org/ticket/897 (to show last imported photos) and http://trac.yorba.org/ticket/1793 (for a more general import roll capability). > - Favorites as a top level item. It is a bit confusing to click on > Photos, then select "View> only favorites". Ideally, it would be > based on a 1 to 4 star system, not just one star. This would be similar to nesting of tags, where selecting 2 stars gives you everything 2 > stars and above. > Yes - Shotwell currently has only a binary rating system where a photo either is or is not a favorite, but it's become clear that many photographers want a 5-star system, and we need that to be able to preserve ratings imported from other programs such as F-Spot or iPhoto. This is http://trac.yorba.org/ticket/1878; probably coming soon. > - when viewing a single photo, the controls can all be on the left pane instead of showing the hierarchy, which doesn't apply for the individual photo. > True. We may eventually move some controls into the left pane once we have more adjustment options. > - View by filesystem as a top level tier. Currently you get only all via photos. As mentioned above, it would be ideal if renaming an event > a) renamed the folder the photos were contained in (eg. 2010-01-01 New Year's Eve) and > b) renamed the pictures to a similar format "2010-01-01 New Year's Eve 001.jpg" > The filesystem view should show all folders nested under the currently selected folder, separated by the name of the folder containing those files. > Yes - we do want to put a file hierarchy tree into the sidebar. This is http://trac.yorba.org/ticket/1594. A lot of users want this, so we may even take this on for 0.7. > - if allowing file system view, events do not need to be renamed. Events become a date view. Events should be the file system view... no? > This is a Big Question and is debatable. Once we have a file system view, it's true that you could simply arrange photos into directories based on their time and rename the directories to have event-like names. With that usage pattern, events simply become a date view and there's no need to rename them. Many people might want to use Shotwell this way, but some might want to use a different directory organization but still have independent renameable events. I'm reluctant to take away a feature that people may be using and like, so I think we'll probably still allow events to be renameable even after the file system view is implemented. > - Import should be file system based (organize by folder) and this should be configurable. > Pictures/2010/2010-01-01 New Year's Eve/ > or > Pictures/2010/01/New Year's Eve > or whatever format a user wants. > I cannot stress how important this is. This is required for archival purposes. You should not need Shotwell 10 years from now to be able to view your organized photos. I should also be able to import my pictures, organize them, and be able to browse them intelligently in the file manager. > Completely agreed. This is http://trac.yorba.org/ticket/1597 . I hope we can make this happen before too long. > > That's all for me. I hope this application gets some of the changes mentioned. There is no good enough application on linux for importing/managing photos yet at the filesystem level. I have been using Linux on the desktop for 2 years. Believe it or not, I still use Windows PHoto Gallery within a VirtualBox/windows vm to import my photos. Please help me get rid of this dependency. > OK - thanks for all the feedback, and yes, I also hope we can eliminate your Windows Gallery dependency before too long! :) adam From brunogirin at gmail.com Fri Jun 18 16:17:34 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 18 Jun 2010 17:17:34 +0100 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <4C1B8331.5040101@yorba.org> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> <4C1B8331.5040101@yorba.org> Message-ID: <1276877854.1563.64.camel@nuuk> On Fri, 2010-06-18 at 07:31 -0700, Adam Dingle wrote: > > - if allowing file system view, events do not need to be renamed. Events become a date view. Events should be the file system view... no? > > > > This is a Big Question and is debatable. Once we have a file system > view, it's true that you could simply arrange photos into directories > based on their time and rename the directories to have event-like > names. With that usage pattern, events simply become a date view and > there's no need to rename them. Many people might want to use Shotwell > this way, but some might want to use a different directory organization > but still have independent renameable events. I'm reluctant to take > away a feature that people may be using and like, so I think we'll > probably still allow events to be renameable even after the file system > view is implemented. I'm one of those people who like the feature of having an event view that is de-coupled from the file system. The reason for this is that the file system view would give me a pure chronological view of photos while the event view may not. Furthermore, if you implement hierarchical tags, you could also consider implementing hierarchical events, which wouldn't work too well if events were tied to the file system. I'll give you an example that may end up being quite messy if the event and file views are the same: * Let's say I'm going to the Wimbledon tennis championship that starts on Monday and spans 2 weeks (so I may go on several days), I would want to group all my Wimbledon photos into a single event. But then in between Wimbledon photos, I may take other photos (after all, over 2 weeks, that's very likely). If the event and file system views are the same, I lose the actual chronology of the photos (unless I have an additional chronological view that is not linked to the file system). * Then say that I want to create hierarchical events so that I group my Wimbledon photos according to the matches I've seen: 1 top event for Wimbledon, 1 sub-event for the Federer - Falla first round match, 1 sub-event for the quarter-final, etc. If event and file system views are the same, there's bound to be quite a lot of activity on disk before I'm done. The whole benefit of having a database is to be able to create a logical arrangement of photos that is independent from the file system storage. If you have both an event and a file view in Shotwell, it's then down to you, the user, to decide whether you'd rather use the event or the file view as your primary way of interacting with the software. This then becomes even more complicated the day Shotwell introduces the concept of People and Places views, the same way as F-Spot does, or the concept of user collections (like Rhythmbox or iTunes playlists). In that case, which scheme should you follow when storing photos on disk? My last reason for keeping the file system arrangement as it is that it is the simplest arrangement that guarantees I won't have any file name clashes. All files coming out of my camera have a name in the form IMG_XXXX.JPG (or .CR2) where XXXX is a number between 0000 and 9999. Once I reach 10000 pictures (I've done that once so far), the counter resets so I may have two different pictures with the file name IMG_1234.JPG in my collection. With a pure date-based chronological arrangement at the file system level, I can be sure that those two files will reside in two different directory. With any other naming scheme, I may accidentally have a name clash. Of course, that doesn't solve the situation where you have 2 camera bodies but it still makes a clash very unlikely :-) If the argument is to ensure that the event information is stored independently of the Shotwell database, I would say that it should be stored in the photo meta-data so that you can copy the photo around and keep the event information whatever happens. My 2 pence, Bruno From subscribed-lists at sterndata.com Fri Jun 18 16:49:33 2010 From: subscribed-lists at sterndata.com (Steven Stern) Date: Fri, 18 Jun 2010 11:49:33 -0500 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <828528.99582.qm@web33707.mail.mud.yahoo.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> Message-ID: <4C1BA39D.9080306@sterndata.com> On 06/17/2010 10:42 PM, Lu Timdale wrote: > I think this application shows the most promise from any linux based photo manager thus far. > Overall, I'm pretty happy with Shotwell. I think my major problem is that I've been collecting images for years and those images include .bmp and .gif files. I know I can convert them to .jpg, but why should I have to? PS: Let me put in a vote for keeping the "changes to images are held in the database" model. I like being able to undo or redo changes at a later date. I also like the idea of figuring out what I did to an image a long time ago when I have a similar problem image now. -- -- Steve From adam at yorba.org Fri Jun 18 17:00:34 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 18 Jun 2010 10:00:34 -0700 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <4C1BA39D.9080306@sterndata.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> <4C1BA39D.9080306@sterndata.com> Message-ID: <4C1BA632.2030409@yorba.org> On 06/18/2010 09:49 AM, Steven Stern wrote: > Overall, I'm pretty happy with Shotwell. Glad to hear it! :) > I think my major problem is > that I've been collecting images for years and those images include .bmp > and .gif files. I know I can convert them to .jpg, but why should I > have to? > > A reasonable point. I've just created a ticket for BMP and GIF support: http://trac.yorba.org/ticket/2154 . > PS: Let me put in a vote for keeping the "changes to images are held in > the database" model. I like being able to undo or redo changes at a > later date. I also like the idea of figuring out what I did to an image > a long time ago when I have a similar problem image now. > Thanks for the input. We may be enhancing Shotwell's storage model in some ways in 0.7, but we completely agree that being able to undo or redo changes at a later date is critical, and that capability won't go away (in fact, Shotwell was designed from the ground up to support exactly that). adam From brunogirin at gmail.com Fri Jun 18 17:33:35 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 18 Jun 2010 18:33:35 +0100 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <4C1BA39D.9080306@sterndata.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> <4C1BA39D.9080306@sterndata.com> Message-ID: <1276882415.1563.78.camel@nuuk> On Fri, 2010-06-18 at 11:49 -0500, Steven Stern wrote: > On 06/17/2010 10:42 PM, Lu Timdale wrote: > > I think this application shows the most promise from any linux based photo manager thus far. > > > > Overall, I'm pretty happy with Shotwell. I think my major problem is > that I've been collecting images for years and those images include .bmp > and .gif files. I know I can convert them to .jpg, but why should I > have to? If you have images in .gif or .bmp format, you'd be better off converting them to .png rather than .jpg. The reason for this is that .png uses a lossless compression algorithm, like .gif (.bmp doesn't use compression so is by definition lossless too), while .jpg uses a compression algorithm that can lead to unexpected artefacts in images that have large areas of a single colour. In practice, such artefacts are invisible on a photograph because images of real life never produce large areas of a single colour but they can be very obvious on drawings and icons. As to why should you have to convert your images, the only reason I can think of is that .bmp images are uncompressed so converting them to .png would save disk space while not loosing any details. Anyway, the perfect solution is Adam's one: add a ticket to Shotwell so that when it is resolved, Shotwell will handle .gif and .bmp :-) Bruno From c.dupaty at free.fr Fri Jun 18 18:27:15 2010 From: c.dupaty at free.fr (Charles) Date: Fri, 18 Jun 2010 20:27:15 +0200 Subject: [Shotwell] Red-Eyes In-Reply-To: References: <4C1A5636.8000502@free.fr> <4C1A9AA9.10607@free.fr> Message-ID: <4C1BBA83.8060408@free.fr> Hi Lucas you've understood that it was not for the dog, but for its eyes :) I completely agree, and will be patient until the fix of the ticket thank you very much Charles Le 18/06/2010 01:17, Lucas Beeler a ?crit : > Hi Charles, > > Thanks for the photos of your dog! What's going on in this photo is > that the reflection of the flash caused the eye (by far the most > reflective object in the photo) to become over-exposed. This is a > flash-flare problem that is more significant than just red-eye > distortion. I agree with you that we should try to correct this kind > of problem in Shotwell. This will come when we implement the fix > described in Shotwell ticket #2148 > (http://trac.yorba.org/ticket/2148), which I created this morning in > response to your initial question. > > Take care, > Lucas > From david.velazquez08 at gmail.com Fri Jun 18 23:01:43 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Fri, 18 Jun 2010 19:01:43 -0400 Subject: [Shotwell] Shotwell reviewed in LWN In-Reply-To: <4C1AA88D.2030604@yorba.org> References: <871vc6gnb2.fsf@SSpaeth.de> <4C1AA88D.2030604@yorba.org> Message-ID: Adam, thanks for cross posting your comment here. My thoughts on the issue of how Shotwell handles photomodification (it sounds like it boils down to saving changes on the file system or it's own database) would be that users would never be completely pleased and satisfied with how Shotwell handles it no matter how many options there are. Referencing the launchpad bug report, it sounds like either options A or B would work for any person, it's just a matter of how well Shotwell would work for them. Creating two different ways of doing what is essentially the same thing seems complicated to me and may open up Shotwell to more complicated and difficult bugs in the future, I think. To me, a better approach might be to choose what user group, either amateurs or professionals, Shotwell is geared towards and decide which way of saving changes would work best for them based on the comments received. I understand this may be an unpopular post and completely against the way Yorba might like to do things, but in my limited experience it isn't easy to be a jack of all trades here. By all means though, if you decide that's your goal I'm all for it!! Just my thoughts on this. Dave On Thu, Jun 17, 2010 at 6:58 PM, Adam Dingle wrote: > On 06/16/2010 11:56 PM, Sebastian Spaeth wrote: > > Dear all, I am new here. Hello! > > > > I wanted to point you to a quick grumpy editors review of shotwell: > > > > http://lwn.net/SubscriberLink/392261/b6d9e95899253392/ > > > > I am sure you have a couple of comments or trac tickets to respond :-). > > > > Sebastian, > > thanks for the link to the LWN review! FYI I just posted a response on > that page, which I'll also include here: > > === > > Grumpy Editor, > > I'm the founder of Yorba (makers of Shotwell) and have been deeply > involved in Shotwell's design from day one. Thanks a lot for trying out > Shotwell and for the candid and thorough review. We always appreciate > direct feedback and are happy to hear about what people do and do not like. > > Grumpy Editor, your review touched on various points about Shotwell, but > of course your biggest gripe was about the way Shotwell imports photos > and about the relationship between the Shotwell photo library and the > file system. I'll first provide brief feedback about some of the smaller > points: > > - You mentioned the lack of support for RAW photos and zooming into > photos. Both of these features have been impemented in trunk and will be > present in the Shotwell 0.6 release (coming in the next two weeks). > > - As someone else pointed out in another comment, it actually is > possible to split an event apart in Shotwell: simply select the photos > you'd like to split into a separate event, then choose Events->New Event. > > - It actually is possible to remove a tag from several photos at once. > Simply select the tag in the sidebar, then select the photos you'd like > to remove it from and choose Tags->Remove Tags From Photos. > > - We do hope to implement hierarchical tags at some point (that's > http://trac.yorba.org/ticket/1401, if you're curious). > > OK, and now on to your Major Concern. As you pointed out in your review, > Shotwell expects you to import all photos into its library. As you do > so, Shotwell indexes their metadata so you can search them in various > ways. You can edit photos in Shotwell, but normally your changes stay in > the Shotwell universe. Changes get written to files only when you export > (or, in Shotwell 0.6, when you use Shotwell's Open in External Editor > command, which writes pending changes to a file and then opens an > external program such as GIMP on it). > > The Shotwell model is common among commercial photo programs; iPhoto, > Aperture and (to some degree) Picasa all work this way, for instance. > But clearly you want a photo program to use a different model. You'd > like to be able to browse through photos easily according to their > on-disk file hierarchy, and presumably you'd like photo edits and > metadata to be stored in the photo files themselves, at all times. I > imagine you'd also like to be able to search for all photos matching a > given tag or in a given date range. For this to be possible, a photo > program must of course index the on-disk photos, which is itself a form > of importing, really. But it sounds like you're opposed to an explicit > import step. (Perhaps you'd like to point a photo program at your > top-level photo directory and let it index everything in the background. > Or maybe you'd like a photo program to automatically index all the > photos in directories which the user browses through.) > > So, then, which model is superior? We built Shotwell to use explicit > importing and to store edits in its own database both because other > popular programs work that way and because certain users have told us > they want us never to touch their originals (see, for example, the > discussion at > http://lists.yorba.org/pipermail/shotwell/2010-April/0002... > ). But > recently we've been getting more and more feedback from people like you > who want a storage model based directly on the filesystem (see, for > example, http://ubuntuforums.org/showthread.php?p=9475456 or > https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/5... > ). So > I've actually become less and less sure that we've gotten this right, > and I think it's likely that we'll switch to something like your > preferred storage model in a not-too-distant release, at least as an > option for the user. In fact, different users seem to have distinctly > different storage preferences, and so perhaps we can even evolve > Shotwell to the point where the user can choose where data is stored. > For example, a user might want us to store metadata (e.g. photo > titles/keywords) either in the original files, in sidecar XMP files, in > the Shotwell database, or in Tracker. It might be cool if Shotwell could > do any of these as you please. > > As you mentioned, Shotwell is a young utility. We do in fact plan to > evolve it to work more flexibly together with other Linux tools, so > thanks again for the feedback and please keep your eyes open for future > Shotwell developments! > > Cheers, > adam > > === > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From svetoslav.trochev at gmail.com Sun Jun 20 13:09:37 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Sun, 20 Jun 2010 06:09:37 -0700 Subject: [Shotwell] The old DB vs File-system and Destructive vs Non-destructive management of photos. Message-ID: Hi Everyone, Please forgive me if I am stepping out of line a bit and because I am new and don't know the background. For many years I am struggling to find a good tool to manage my photo work flow. I am still stuck using a multiple tools and some of them are close source and I hate them. They hold me hostage to their ecosystem without solving my problem. As result I spend way too much time to manage my photos instead of doing something fun like creating and editing them. I am happy that I discover the Shotwell right at the moment when discussion about photo management is going on. I would like to share my ideas and tap into community wisdom in order to solve the "my photo management" problem once and for all. So let start. My work flow is: Phase I: 1. Get an image. (cameras, scanners, web and etc.) 2. Store them in some file-system structure. 3. Enter basic meta-data. ( Event, People, Purpose, Source, Copyright, ratings, and etc) 4. At this point this is my 'Digital Negatives' (DNs) 5. Remove useless crap. 6. Basic non-destructive editing usually using RAW converter ( Lens corrections: geometric distortion and chromatic aberration, tilt, and perspective, exposure, and color correction ) 7. Archive (Network share and Removable media) Phase II: Image processing. This is very different based on the job. It includes things like selecting the right images, HDR, 3D and etc. Using the right tool for the job. Most often it is destructive editing Phase III: Sharing the images. Again it varies a lot As you can see I need both DB and File-system management. Because I want to be able to remove the DNs from my local file system, but to continue to be able to search the archive and see preview. This only could be done by DB. At the same time I need to manage multiple 'prints' as part of Phase II. This only could be done in different project folders and should share meta-data with other tools. And finally to maintain multiple share options by creating galleries this is most well done by DB/Export. That way I don't have to maintain multiple backups of the same photo. When it comes to editing I need both again. Non-destructive edits organized in 'recipes' The recipes should be attached to the RAW/original file and I would like to copy recipe from one file and add it to one ore more files. This feature speeds my work multiple times. That is the main reason why I still use original software from Canon and stuck with Windows. In all other cases I really like how Shotwell manages the edits and the use of DB. Probably would be good idea to be able to export edit data if needed to other tools and managing the steps like version control between different tools when destructive editing is needed. So new feature would be needed I think. Other tools call it stacks where you see the last result, but you can go back and see previous steps. I understand why proprietary tools never going to provide this unless it cost $$$$ and needs to be updated every year for $$$ more just to add new feature or to fix a single bug or even worst to continue to access your photos. I strongly believe that FOSS is the right way to fix this and I am bit surprised that we have not done this already. Please speak up! Svetoslav From brunogirin at gmail.com Sun Jun 20 18:10:27 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sun, 20 Jun 2010 19:10:27 +0100 Subject: [Shotwell] The old DB vs File-system and Destructive vs Non-destructive management of photos. In-Reply-To: References: Message-ID: <1277057427.1573.91.camel@nuuk> Hi Svetoslav, Thanks for your input, this is very interesting! I've added some comments below on some of your points. On Sun, 2010-06-20 at 06:09 -0700, Svetoslav Trochev wrote: > Hi Everyone, > > Please forgive me if I am stepping out of line a bit and because I am > new and don't know the background. For many years I am struggling to > find a good tool to manage my photo work flow. I am still stuck using > a multiple tools and some of them are close source and I hate them. > They hold me hostage to their ecosystem without solving my problem. As > result I spend way too much time to manage my photos instead of doing > something fun like creating and editing them. I am happy that I > discover the Shotwell right at the moment when discussion about photo > management is going on. I would like to share my ideas and tap into > community wisdom in order to solve the "my photo management" problem > once and for all. So let start. My work flow is: > > Phase I: > 1. Get an image. (cameras, scanners, web and etc.) > 2. Store them in some file-system structure. > 3. Enter basic meta-data. ( Event, People, Purpose, Source, Copyright, > ratings, and etc) > 4. At this point this is my 'Digital Negatives' (DNs) > 5. Remove useless crap. > 6. Basic non-destructive editing usually using RAW converter ( Lens > corrections: geometric distortion and chromatic aberration, tilt, and > perspective, exposure, and color correction ) > 7. Archive (Network share and Removable media) > > Phase II: > Image processing. This is very different based on the job. It includes > things like selecting the right images, HDR, 3D and etc. Using the > right tool for the job. Most often it is destructive editing > > Phase III: > Sharing the images. Again it varies a lot > > As you can see I need both DB and File-system management. Because I > want to be able to remove the DNs from my local file system, but to > continue to be able to search the archive and see preview. This only > could be done by DB. At the same time I need to manage multiple > 'prints' as part of Phase II. This only could be done in different > project folders and should share meta-data with other tools. And > finally to maintain multiple share options by creating galleries this > is most well done by DB/Export. That way I don't have to maintain > multiple backups of the same photo. There are lots of interesting suggestions here. I think the concept of having multiple prints could be very useful, even for users who are not as advanced as you are. For example, any user would understand the benefit of being able to have, say a "black & white" print and a sepia one and compare between them. > > When it comes to editing I need both again. Non-destructive edits > organized in 'recipes' The recipes should be attached to the > RAW/original file and I would like to copy recipe from one file and > add it to one ore more files. This feature speeds my work multiple > times. That is the main reason why I still use original software from > Canon and stuck with Windows. In all other cases I really like how > Shotwell manages the edits and the use of DB. Probably would be good > idea to be able to export edit data if needed to other tools and > managing the steps like version control between different tools when > destructive editing is needed. So new feature would be needed I think. > Other tools call it stacks where you see the last result, but you can > go back and see previous steps. In practice, what Shotwell does is create a recipe to re-create a particular set of edit on top of an existing negative. Being able to copy that recipe from one photograph to another to apply it in batch to a collection of photograph would be very useful. The concept of stacks could actually be extended to allow branching in the stack, in order to support the concept of multiple prints (and derivations thereof). In fact, you're right, the best way to see this would probably be to model it on version control tools, with added visual goodness. > > I understand why proprietary tools never going to provide this unless > it cost $$$$ and needs to be updated every year for $$$ more just to > add new feature or to fix a single bug or even worst to continue to > access your photos. I strongly believe that FOSS is the right way to > fix this and I am bit surprised that we have not done this already. I agree with you, FOSS is the right way to fix this and I believe Shotwell is a good platform to do so. It certainly has the potential. What you've said above has given me a few ideas. I need to clarify them and put them down in writing. Once I've done that, I'll share it with the list so that you can tell whether it makes sense. Bruno From martin at minimum.se Mon Jun 21 08:09:01 2010 From: martin at minimum.se (Martin Olsson) Date: Mon, 21 Jun 2010 10:09:01 +0200 (CEST) Subject: [Shotwell] shotwell doesn't compile with 0.9.2 Message-ID: <57575.213.236.208.22.1277107741.squirrel@www.scorpiondata.com> Vala git master (and the recently released 0.9.2) no longer compiles Shotwell git master: http://trac.yorba.org/ticket/2164 --- ColorTransformation.vala:35.9-35.33: error: unsupported lvalue in assignment this = hsv_pixel.to_rgb(); ^^^^^^^^^^^^^^^^^^^^^^^^^ ...for this Shotwell code: public RGBAnalyticPixel.from_hsv(HSVAnalyticPixel hsv_pixel) { this = hsv_pixel.to_rgb(); } --- commit 95b2e15a05fdd6ffa2a75654f06932378cd8ebbb Author: Luca Bruno Date: Wed Jun 2 11:11:03 2010 +0200 Do not support assigning to `this' Fixes bug 620120. https://bugzilla.gnome.org/show_bug.cgi?id=620120 From pdo.smith at gmail.com Mon Jun 21 09:33:29 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 21 Jun 2010 11:33:29 +0200 Subject: [Shotwell] Tags enhancement Message-ID: At last, a photo manager that I really like. I have just downloaded and built from the repository. This programs shows such promise. The team deserve full marks. I know that an enhancement for nested tags has been proposed but I would like to suggest a simpler and more powerful alternative. Why not use Ctrl-click to select two or more tags and display the subset of photos with those combined tags? I prefer this to an hierarchical system which requires me to make prior decisions about my photo structure. A linear list of tags which can be combined in many ways with multiple selections is both simple and very powerful. Of course you could do both leaving people to organise tags in their preferred way. The new picture zoom feature is very welcome. Would like to see the percentage zoom though. When I try to drag the image after zooming, on the first try it resets the displayed size and then on the second try works as expected. I am not sure if this is a bug or a user error. From brunogirin at gmail.com Mon Jun 21 11:37:50 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 21 Jun 2010 12:37:50 +0100 Subject: [Shotwell] Tags enhancement In-Reply-To: References: Message-ID: <1277120270.1570.30.camel@nuuk> On Mon, 2010-06-21 at 11:33 +0200, Peter DO Smith wrote: > At last, a photo manager that I really like. I have just downloaded and > built from the repository. This programs shows such promise. The team > deserve full marks. > > I know that an enhancement for nested tags has been proposed but I would > like to suggest a simpler and more powerful alternative. Why not use > Ctrl-click to select two or more tags and display the subset of photos with > those combined tags? So basically, if I understand it well, what you are asking for is to add to the UI the ability to select photos based on a combination of tags, such as: * All photos that have the tags "London", "Bus" and "Red" * All photos that have either the tag "Madrid" or "Barcelona" That makes sense :-) The difficulty here is probably to come up with a UI that is actually easy and intuitive to use. > > I prefer this to an hierarchical system which requires me to make prior > decisions about my photo structure. A linear list of tags which can be > combined in many ways with multiple selections is both simple and very > powerful. > > Of course you could do both leaving people to organise tags in their > preferred way. I think both have their uses and I can see usage patterns where I would use one or the other, or even a combination of both. > > The new picture zoom feature is very welcome. Would like to see the > percentage zoom though. Something like having the actual magnification percentage displayed next to the slider? > When I try to drag the image after zooming, on the first try it resets the > displayed size and then on the second try works as expected. I am not sure > if this is a bug or a user error. Do you mean? * Double click on the photo in the library * Zoom into the photo * Drag the photo => it reverts to default size If that's the case, what version of Shotwell are you using? It doesn't do this with a trunk build so it may be that this is a bug that has now been resolved. Bruno From pdo.smith at gmail.com Mon Jun 21 11:55:04 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 21 Jun 2010 13:55:04 +0200 Subject: [Shotwell] Tags enhancement In-Reply-To: <1277120270.1570.30.camel@nuuk> References: <1277120270.1570.30.camel@nuuk> Message-ID: On Mon, Jun 21, 2010 at 1:37 PM, Bruno Girin wrote: > > On Mon, 2010-06-21 at 11:33 +0200, Peter DO Smith wrote: > > At last, a photo manager that I really like. I have just downloaded and > > built from the repository. This programs shows such promise. The team > > deserve full marks. > > > > I know that an enhancement for nested tags has been proposed but I would > > like to suggest a simpler and more powerful alternative. Why not use > > Ctrl-click to select two or more tags and display the subset of photos with > > those combined tags? > > So basically, if I understand it well, what you are asking for is to add > to the UI the ability to select photos based on a combination of tags, > such as: > ? ? ?* All photos that have the tags "London", "Bus" and "Red" > ? ? ?* All photos that have either the tag "Madrid" or "Barcelona" Yes, except I mean a logical AND > > That makes sense :-) The difficulty here is probably to come up with a > UI that is actually easy and intuitive to use. > Leave the UI as it is. You simply Control-Click on the tags to build up your tag selection (and change the colour of the marked tags) > > > > I prefer this to an hierarchical system which requires me to make prior > > decisions about my photo structure. A linear list of tags which can be > > combined in many ways with multiple selections is both simple and very > > powerful. > > > > Of course you could do both leaving people to organise tags in their > > preferred way. > > I think both have their uses and I can see usage patterns where I would > use one or the other, or even a combination of both. > > > > > The new picture zoom feature is very welcome. Would like to see the > > percentage zoom though. > > Something like having the actual magnification percentage displayed next > to the slider? Yes, I routinely go to a 100% or 1:1 view to check the sharpness of my photos > > > > When I try to drag the image after zooming, on the first try it resets the > > displayed size and then on the second try works as expected. I am not sure > > if this is a bug or a user error. > > Do you mean? > ? ? ?* Double click on the photo in the library > ? ? ?* Zoom into the photo > ? ? ?* Drag the photo => it reverts to default size > > If that's the case, what version of Shotwell are you using? It doesn't > do this with a trunk build so it may be that this is a bug that has now > been resolved. I downloaded the trunk this morning. If I double click, zoom and drag it works OK. If I press F11, zoom and drag it exhibits this behaviour but only under these conditions. I drag the slider, pause while I consider the degree of magnification. While I pause the bottom popup panel disappears. Now if I move the cursor over the image it remains a pointer (does not change to a drag hand). If now I click and hold on the image, preparatory to dragging, the image size resets. > From brunogirin at gmail.com Mon Jun 21 12:18:23 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 21 Jun 2010 13:18:23 +0100 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> Message-ID: <1277122703.1570.40.camel@nuuk> On Mon, 2010-06-21 at 13:55 +0200, Peter DO Smith wrote: > On Mon, Jun 21, 2010 at 1:37 PM, Bruno Girin wrote: > > > > On Mon, 2010-06-21 at 11:33 +0200, Peter DO Smith wrote: > > > At last, a photo manager that I really like. I have just downloaded and > > > built from the repository. This programs shows such promise. The team > > > deserve full marks. > > > > > > I know that an enhancement for nested tags has been proposed but I would > > > like to suggest a simpler and more powerful alternative. Why not use > > > Ctrl-click to select two or more tags and display the subset of photos with > > > those combined tags? > > > > So basically, if I understand it well, what you are asking for is to add > > to the UI the ability to select photos based on a combination of tags, > > such as: > > * All photos that have the tags "London", "Bus" and "Red" > > * All photos that have either the tag "Madrid" or "Barcelona" > > Yes, except I mean a logical AND Yes, I gathered that. I just thought that a logical OR may be useful too :-) > > > > > That makes sense :-) The difficulty here is probably to come up with a > > UI that is actually easy and intuitive to use. > > > > Leave the UI as it is. You simply Control-Click on the tags to build > up your tag selection (and change the colour of the marked tags) OK, that could be a quick shortcut. > > Something like having the actual magnification percentage displayed next > > to the slider? > > Yes, I routinely go to a 100% or 1:1 view to check the sharpness of my photos That makes sense. Another improvement that could be useful for this use case would be to have easy shortcuts for default magnification like 100%, best fit, etc. > If I press F11, zoom and drag it exhibits this behaviour but only > under these conditions. I drag the slider, pause while I consider the > degree of magnification. While I pause the bottom popup panel > disappears. Now if I move the cursor over the image it remains a > pointer (does not change to a drag hand). If now I click and hold on > the image, preparatory to dragging, the image size resets. OK, I managed to reproduce it and opened a ticket: http://trac.yorba.org/ticket/2166 Bruno From pdo.smith at gmail.com Mon Jun 21 12:19:55 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 21 Jun 2010 14:19:55 +0200 Subject: [Shotwell] The DB debate Message-ID: I see in earlier threads it was discussed whether the present system of storing photo data in a sqlite database should be retained. I much prefer the present system, please retain it. It is simple to write add-on programs that query/update the database. It took me fives minutes to inspect the database structure to understand it well enough so that I could query it and update it. This simplicity helped me to re-organise my photos after importing. A large group of my photos had no exif header, an artifact of a batch program I wrote. After importing several thousand photos I could not find them because they were not assigned to an event, having no date. Realising my mistake, I used jhead to create exif headers and assign dates. But now when I tried to import again I was told the photos were already in the database and therefore I could not import again. What to do? Fortunately, because you used a database, it was trivial for me to write a SQL query that located and deleted the photos from the database, allowing me to re-import them. So please, keep the present system. From my point of view it works really well. Arising out of this experience I would like to make two suggestions:- 1) Allow the user an option of forcing the import to accept the same photos again. This will allow to reorganise the folder structure of his photos. 2) Where the photos have no exif date create an 'unassigned' event and link these photos to that event. Peter From svetoslav.trochev at gmail.com Mon Jun 21 12:24:41 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Mon, 21 Jun 2010 05:24:41 -0700 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> Message-ID: Hi Everyone. On Mon, Jun 21, 2010 at 4:55 AM, Peter DO Smith wrote: > On Mon, Jun 21, 2010 at 1:37 PM, Bruno Girin wrote: >> >> On Mon, 2010-06-21 at 11:33 +0200, Peter DO Smith wrote: >> > I know that an enhancement for nested tags has been proposed but I would >> > like to suggest a simpler and more powerful alternative. Why not use >> > Ctrl-click to select two or more tags and display the subset of photos with >> > those combined tags? >> >> So basically, if I understand it well, what you are asking for is to add >> to the UI the ability to select photos based on a combination of tags, >> such as: >> ? ? ?* All photos that have the tags "London", "Bus" and "Red" >> ? ? ?* All photos that have either the tag "Madrid" or "Barcelona" > > Yes, except I mean a logical AND > >> >> That makes sense :-) The difficulty here is probably to come up with a >> UI that is actually easy and intuitive to use. >> > > Leave the UI as it is. You simply Control-Click on the tags to build > up your tag selection (and change the colour of the marked tags) > Once I had a similar problem and I solved it by adding custom check box in front of each tag in the list. My customization was that each check box had 4 state instead of 2. My states were (V) tag, (O) tag, ( ) not selected tag and (X) excluded tag. Also I needed meta tag. "Without tag" The logic behind was. If the tag is selected with "V" its added to the query with logical "AND" if it is selected with "O" it is oded with "OR". If the tag is excluded with "X" its added to the query with "NO" and some time I needed to select or exclude elements without tags so by default all elements are tagged with tag: "Undefined" and I did not have to modify the query instead using meta-tag named "Without tag". And this method did not interfered with people who liked to use nested tag system. Personally I think that system with more then 2 levels of tags is difficult to use in the long run. You end up with duplicated tags. I do first level to be category: "People, Places, Assignment, Family, and etc" and all individual tags are under each category. SAL-e From svetoslav.trochev at gmail.com Mon Jun 21 12:35:35 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Mon, 21 Jun 2010 05:35:35 -0700 Subject: [Shotwell] The DB debate In-Reply-To: References: Message-ID: Hi, On Mon, Jun 21, 2010 at 5:19 AM, Peter DO Smith wrote: > I see in earlier threads it was discussed whether the present system > of storing photo data in a sqlite database should be retained. > > I much prefer the present system, please retain it. > > It is simple to write add-on programs that query/update the database. > It took me fives minutes to inspect the database structure to > understand it well enough so that I could query it and update it. > > This simplicity helped me to re-organise my photos after importing. A > large group of my photos had no exif header, an artifact of a batch > program I wrote. After importing several thousand photos I could not > find them because they were not assigned to an event, having no date. > > Realising my mistake, I used jhead to create exif headers and assign > dates. But now when I tried to import again I was told the photos were > already in the database and therefore I could not import again. What > to do? > > Fortunately, because you used a database, it was trivial for me to > write a SQL query that located and deleted the photos from the > database, allowing me to re-import them. > > So please, keep the present system. From my point of view it works really well. > > Arising out of this experience I would like to make two suggestions:- > > 1) Allow the user an option of forcing the import to accept the same > photos again. This will allow to reorganise the folder structure of > his photos. > 2) Where the photos have no exif date create an 'unassigned' event and > link these photos to that event. > > Peter > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > I agree. In my early thread I showed how we need both. The trick is to come with automatic method to update the DB after the user had used tool that does not updated DB. Like moving the photos from one directory to other using OS file manager. I had some ideas, but I need to dig out my notes and I will share them here. If I remember correctly I only needed two meta-tags attached to the each photo: ID and CRC. SAL-e From adam at yorba.org Mon Jun 21 15:23:09 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 08:23:09 -0700 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> Message-ID: <4C1F83DD.9000704@yorba.org> On 06/21/2010 04:55 AM, Peter DO Smith wrote: > On Mon, Jun 21, 2010 at 1:37 PM, Bruno Girin wrote: > >> On Mon, 2010-06-21 at 11:33 +0200, Peter DO Smith wrote: >> >>> At last, a photo manager that I really like. I have just downloaded and >>> built from the repository. This programs shows such promise. The team >>> deserve full marks. >>> Thanks! >>> I know that an enhancement for nested tags has been proposed but I would >>> like to suggest a simpler and more powerful alternative. Why not use >>> Ctrl-click to select two or more tags and display the subset of photos with >>> those combined tags? >>> >> So basically, if I understand it well, what you are asking for is to add >> to the UI the ability to select photos based on a combination of tags, >> such as: >> * All photos that have the tags "London", "Bus" and "Red" >> * All photos that have either the tag "Madrid" or "Barcelona" >> > Yes, except I mean a logical AND > We plan to implement arbitrary boolean searches at some point; this is http://trac.yorba.org/ticket/1587 . Once that's implemented, you'll be able to combine criteria in arbitrary ways; for example, you'll be able to search for photos matching 'barcelona' and 'statue' but excluding the tag 'park', for example. We haven't yet decided what the user interface for this will look like, but probably there will be a dialog where you can add or remove criteria from a search. Your suggestion is another way to perform simple searches: the user could simply select multiple items in the sidebar to construct a search. That's an interesting idea, and I've added it as a comment to the ticket above. It's not clear whether we should perform an AND or OR in this case, though; both are potentially useful. >>> The new picture zoom feature is very welcome. Would like to see the >>> percentage zoom though. >>> >> Something like having the actual magnification percentage displayed next >> to the slider? >> > Yes, I routinely go to a 100% or 1:1 view to check the sharpness of my photos > You probably don't realize this because we haven't written the Shotwell 0.6 documentation yet, but Shotwell 0.6 has keyboard shortcuts to go to several zoom levels: 0 = zoom out completely 1 = zoom to 1:1 view 2 = zoom to 1:2 view (1 photo pixel = 2 screen pixels) Is that good enough for you, or do you think you need a percentage zoom as well? >>> When I try to drag the image after zooming, on the first try it resets the >>> displayed size and then on the second try works as expected. I am not sure >>> if this is a bug or a user error. >>> >> Do you mean? >> * Double click on the photo in the library >> * Zoom into the photo >> * Drag the photo => it reverts to default size >> >> If that's the case, what version of Shotwell are you using? It doesn't >> do this with a trunk build so it may be that this is a bug that has now >> been resolved. >> > I downloaded the trunk this morning. > If I double click, zoom and drag it works OK. > If I press F11, zoom and drag it exhibits this behaviour but only > under these conditions. I drag the slider, pause while I consider the > degree of magnification. While I pause the bottom popup panel > disappears. Now if I move the cursor over the image it remains a > pointer (does not change to a drag hand). If now I click and hold on > the image, preparatory to dragging, the image size resets. > Thanks for the bug report, and thanks to Bruno for adding this as a ticket. We may still fix this for 0.6 if we can. adam From pdo.smith at gmail.com Mon Jun 21 15:35:25 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Mon, 21 Jun 2010 17:35:25 +0200 Subject: [Shotwell] Tags enhancement In-Reply-To: <4C1F83DD.9000704@yorba.org> References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> Message-ID: On Mon, Jun 21, 2010 at 5:23 PM, Adam Dingle wrote: > > We plan to implement arbitrary boolean searches at some point; this is > http://trac.yorba.org/ticket/1587 . ?Once that's implemented, you'll be > able to combine criteria in arbitrary ways; for example, you'll be able > to search for photos matching 'barcelona' and 'statue' but excluding the > tag 'park', for example. ?We haven't yet decided what the user interface > for this will look like, but probably there will be a dialog where you > can add or remove criteria from a search. > > Your suggestion is another way to perform simple searches: the user > could simply select multiple items in the sidebar to construct a > search. ?That's an interesting idea, and I've added it as a comment to > the ticket above. ?It's not clear whether we should perform an AND or OR > in this case, though; both are potentially useful. The beauty of selecting multiple tags is the speed and simplicity of the operation. It doesn't do away with the need for a more comprehensive search. But I am sure a multiple tag selection facility is the one I would use by far the most often.. > You probably don't realize this because we haven't written the Shotwell > 0.6 documentation yet, but Shotwell 0.6 has keyboard shortcuts to go to > several zoom levels: > > 0 = zoom out completely > 1 = zoom to 1:1 view > 2 = zoom to 1:2 view (1 photo pixel = 2 screen pixels) > > Is that good enough for you, or do you think you need a percentage zoom > as well? > Yes, it is good enough for me, I have just tried it out, that is perfect, thanks. Peter From adam at yorba.org Mon Jun 21 16:07:34 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 09:07:34 -0700 Subject: [Shotwell] The DB debate In-Reply-To: References: Message-ID: <4C1F8E46.8060407@yorba.org> On 06/21/2010 05:19 AM, Peter DO Smith wrote: > I see in earlier threads it was discussed whether the present system > of storing photo data in a sqlite database should be retained. > > I much prefer the present system, please retain it. > > It is simple to write add-on programs that query/update the database. > It took me fives minutes to inspect the database structure to > understand it well enough so that I could query it and update it. > > This simplicity helped me to re-organise my photos after importing. A > large group of my photos had no exif header, an artifact of a batch > program I wrote. After importing several thousand photos I could not > find them because they were not assigned to an event, having no date. > > Realising my mistake, I used jhead to create exif headers and assign > dates. But now when I tried to import again I was told the photos were > already in the database and therefore I could not import again. What > to do? > > Fortunately, because you used a database, it was trivial for me to > write a SQL query that located and deleted the photos from the > database, allowing me to re-import them. > > So please, keep the present system. From my point of view it works really well. > Thanks for your comments about this. For 0.7 we are considering making some changes to Shotwell's storage model for modified photos and photo metadata, but we've made no decisions about this yet. But don't worry: the SQLite database is not going away. Lots of users want us to store metadata in photo files, but even if we do that, we'll still cache it in the SQLite database as well; we'll need to do that in order to perform searches quickly (for example, to find all photos matching a given tag). > Arising out of this experience I would like to make two suggestions:- > > 1) Allow the user an option of forcing the import to accept the same > photos again. This will allow to reorganise the folder structure of > his photos. > That's a reasonable idea. I've created a ticket for this at http://trac.yorba.org/ticket/2170 . > 2) Where the photos have no exif date create an 'unassigned' event and > link these photos to that event. > You're right: it's too hard to find photos which have no EXIF date. We have a ticket for this at http://trac.yorba.org/ticket/1712 . adam From adam at yorba.org Mon Jun 21 16:20:56 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 09:20:56 -0700 Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <828528.99582.qm@web33707.mail.mud.yahoo.com> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> Message-ID: <4C1F9168.9070704@yorba.org> On 06/17/2010 08:42 PM, Lu Timdale wrote: > - red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. > We already have a ticket for fully automatic red-eye correction (http://trac.yorba.org/ticket/549). This might be tricky to implement, though, so I think we probably won't get to this any time soon. I've just created a ticket (http://trac.yorba.org/ticket/2171) for red-eye correction on non-circular areas. Perhaps we could allow the user to stretch the red-eye area to be an ellipse with any width/height. If you need to correct red eye on an arbitrary graphical region, though, I think you should probably use a tool such as GIMP since I don't imagine Shotwell allowing the user to select such regions. adam From lutimdale at yahoo.com Mon Jun 21 17:01:27 2010 From: lutimdale at yahoo.com (Lu Timdale) Date: Mon, 21 Jun 2010 10:01:27 -0700 (PDT) Subject: [Shotwell] Shotwell 0.5 Impressions of a New User In-Reply-To: <4C1F9168.9070704@yorba.org> References: <828528.99582.qm@web33707.mail.mud.yahoo.com> <4C1F9168.9070704@yorba.org> Message-ID: <990469.77628.qm@web33701.mail.mud.yahoo.com> I think there should be several models for red-eye. 1. Automatic - full image (best effort) 2. Face (box/circle around face) to hone in on intended area to fix. 3. Eye (box/circle to hone in on eye). In any case, it must work in such a way that only the red portions are replaced. All red-eye programs do their best to do this without replacing areas that are not red (not the eye). The current method of trying to contain one eye in a small circle (or now what you are proposing - oval) is not very useful. Sorry to be so blunt. Lu Timdale lutimdale at yahoo.com ----- Original Message ---- From: Adam Dingle To: shotwell at lists.yorba.org Sent: Mon, June 21, 2010 12:20:56 PM Subject: Re: [Shotwell] Shotwell 0.5 Impressions of a New User On 06/17/2010 08:42 PM, Lu Timdale wrote: > - red eye fix coloured area outside of the pupil which is unacceptable to me. You should be able to click on "fix red eye for entire image" and have it be fixed automatically, or hone in on a general area. It cannot be only the eyeball area... most people have their eyes partially closed (the area requiring fixing is not circular) and it is unrealistic to expect a general user to exactly pinpoint an eyeball. > We already have a ticket for fully automatic red-eye correction (http://trac.yorba.org/ticket/549). This might be tricky to implement, though, so I think we probably won't get to this any time soon. I've just created a ticket (http://trac.yorba.org/ticket/2171) for red-eye correction on non-circular areas. Perhaps we could allow the user to stretch the red-eye area to be an ellipse with any width/height. If you need to correct red eye on an arbitrary graphical region, though, I think you should probably use a tool such as GIMP since I don't imagine Shotwell allowing the user to select such regions. adam _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From zedtux at zedroot.org Mon Jun 21 18:10:31 2010 From: zedtux at zedroot.org (ZedTuX) Date: Mon, 21 Jun 2010 20:10:31 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. Message-ID: Hi all, So, as tell in the title, I want to contribute (heum... say try to contribute, we will see) to implement a new feature. Before to start anythings I'm browsing code and glade file, and there are my errors. I have found the bash script sw-glade that seems to be the right thing to start to edit GUI, but when I stat it, I have a lot of exceptions in the terminal. Glade open even if these exceptions occurred but it only show me the preferences screen. I imagine that's cause of exception. All concerned form haven't been loaded. Here are a copy/past of exceptions: http://pastie.org/1013950 Other informations: My subversion repo is up-to-date (rev 1839), and compilation of Shotwell is done. And finally my question: Why don't you use Launchpad for your project ? From adam at yorba.org Mon Jun 21 19:08:23 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 12:08:23 -0700 Subject: [Shotwell] Call for testing In-Reply-To: <4C1A9512.3030902@minimum.se> References: <4C19478E.30103@minimum.se> <4C1A9512.3030902@minimum.se> Message-ID: <4C1FB8A7.6000003@yorba.org> On 06/17/2010 02:35 PM, Martin Olsson wrote: > On 06/17/2010 01:31 AM, Jim Nelson wrote: > >>> * When I use "Set as Desktop Background" on a 2000x3000 >>> (i.e. non-landscape orientation) photo, only a part of the >>> photo is visible on my 1680x1050 screen. It's nice that you >>> switched from the current "scale to fit" to another approach >>> where you add padding instead so that the whole photo is >>> guaranteed to be on screen (this is much better than the >>> current "scale to fit width" which will sometimes crop >>> faces halfway through etc). Maybe you can use a PNG so that >>> the padding is transparent (does that mean the bgcolor in >>> the GNOME appearence dialog is used? not sure...) Otherwise >>> black is probably fine. >>> >>> >> Our thinking is that black is a better border for photos than allowing the >> theme color to come through the transparency. (That's also how we display >> photos in full-window and fullscreen mode, for example.) I'm not sure an >> image with a lot of transparency would look good with many background >> colors. >> > The note about the color of the padding was just an extra not, > the bug is about Shotwell using "scale to width" rather than adding > padding. Or did you mean that there was an existing ticket for > the "scale to width" issue? If so what was the bug no (I can't find it). > > For example if you download and import this photo and use set as desktop > background, then Shotwell crops the _ball_ out of a basket ball image: > http://www.pe.com/imagesdaily/2008/04-24/lakers24dwba_300.jpg > > Well, to get the buggy effect I guess you need to have "Style == Scale" > set under System::Preferences::Appearence (this is the default setting > for Ubuntu 10.04). So actually, I think what needs to happen is that > when you set the desktop background itself you also need to set the > "style" option and the "solid background color" in the GNOME Appearance > dialog as well (you can probably not get away with just adding the > padding as extra black pixels in the image because then it will look > bad if the user changes resolution so setting the solid bgcolor to > black is more versatile). > Martin, a few points here. First, we actually made no change from 0.5 to 0.6 in the code that sets the desktop background. I believe that the default desktop background style in Ubuntu 10.04 is actually Zoom, not Scale. To see this, create a new user, log in as that user and open System->Preferences->Appearance. The style for all of the predefined background images will be Zoom. (Note that GNOME actually tracks the style for each background image separately.) When you set the desktop background from Shotwell, we attempt to set the display style for the background image to Zoom. We realize that this might not be the right choice for every photo and user, but it does seem to be the GNOME default. The user can always change the display style in System->Preferences->Appearance. We've thought about having Shotwell prompt the user for a display style when setting a background image, but are unsure about whether about that might be more annoying than useful. Finally, I've just realized that we actually have a bug in which Shotwell is not always successful in setting the background style to Zoom; see http://trac.yorba.org/ticket/2172 . Perhaps you were hit by this and were thereby led to believe that we had made some change to our background setting functionality in this release. adam From mnemo at minimum.se Mon Jun 21 19:52:13 2010 From: mnemo at minimum.se (Martin Olsson) Date: Mon, 21 Jun 2010 21:52:13 +0200 Subject: [Shotwell] Call for testing In-Reply-To: <4C1FB8A7.6000003@yorba.org> References: <4C19478E.30103@minimum.se> <4C1A9512.3030902@minimum.se> <4C1FB8A7.6000003@yorba.org> Message-ID: <4C1FC2ED.9050008@minimum.se> On 06/21/2010 09:08 PM, Adam Dingle wrote: > a few points here. First, we actually made no change from 0.5 to 0.6 in > the code that sets the desktop background. I believe that the default > desktop background style in Ubuntu 10.04 is actually Zoom, not Scale. > To see this, create a new user, log in as that user and open > System->Preferences->Appearance. The style for all of the predefined > background images will be Zoom. (Note that GNOME actually tracks the > style for each background image separately.) I'm aware that you didn't change anything this time around but I believe the current behavior is not as good as it could be. You're right about zoom being the default (I meant "zoom" when I said "scale to width" because essentially what "zoom" does is that it scales the image so that it fits the _width_ of the screen. I realize this was very confusing, sorry about that). I also agree that asking for zoom vs scale etc will make things cluttered. What I propose is that Shotwell chooses the "style" setting based on some smarter heuristics. Maybe you will see what I mean if I provide another example. Download this image and set it as desktop background using zoom: http://upload.wikimedia.org/wikipedia/commons/e/e9/A.J._Bowen._Sundance_2007.jpg Since the image is so tall, it just doesn't look good. Especially on wide screens. For example, this is what I see: http://temp.minimum.se/shotwell_other/cropped_portrait.png Using SCALE in this case with explictly set BLACK background color looks better: http://temp.minimum.se/shotwell_other/scale_looks_better.png Granted, some users will want to use "zoom" anyway for certain photos, for example here is another portrait which actually zoom really good in http://temp.minimum.se/shotwell_other/accidentally_looks_really_good.png http://upload.wikimedia.org/wikipedia/commons/d/d1/Portrait_Gandhi.jpg So to conclude; the argument I'm trying to make here is that I believe that for tall photos, using SCALE + explicit black will be what users what more often than using ZOOM. Of course for _all_ photos with landscape orientation (that is width > height), zoom is clearly the right choice. Martin From allison at yorba.org Mon Jun 21 20:14:26 2010 From: allison at yorba.org (Allison Barlow) Date: Mon, 21 Jun 2010 13:14:26 -0700 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: References: Message-ID: Hello! First off, it's great that you want to contribute! Here are three points that should help you on your way. - Just to be clear, we haven't done all our UI development in Glade. If everything works as it should, you should only see two dialogs when Glade opens. - When developing with glade, you must run './configure --enable-build-for-glade' and then 'make' to generate a shared library. We didn't make this as obvious as we should have, so I've just re-written the sw-glade script to check for the shared library it needs. You can update to get the latest version. - Glade gives off a lot of warnings normally, so keep that in mind. It might be helpful to run Glade independently once just to see the default behavior. ajb On Mon, Jun 21, 2010 at 11:10 AM, ZedTuX wrote: > > Hi all, > > > So, as tell in the title, I want to contribute (heum... say try to > contribute, we will see) to implement a new feature. > Before to start anythings I'm browsing code and glade file, and there are > my errors. > > I have found the bash script sw-glade that seems to be the right thing to > start to edit GUI, but when I stat it, I have a lot of exceptions in the > terminal. Glade open even if these exceptions occurred but it only show me > the preferences screen. I imagine that's cause of exception. All concerned > form haven't been loaded. > > Here are a copy/past of exceptions: > http://pastie.org/1013950 > > Other informations: My subversion repo is up-to-date (rev 1839), and > compilation of Shotwell is done. > > > And finally my question: Why don't you use Launchpad for your project ? > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From allison at yorba.org Mon Jun 21 20:18:04 2010 From: allison at yorba.org (Allison Barlow) Date: Mon, 21 Jun 2010 13:18:04 -0700 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: References: Message-ID: Also, which feature were you hoping to implement? :) ajb On Mon, Jun 21, 2010 at 1:14 PM, Allison Barlow wrote: > Hello! > > First off, it's great that you want to contribute! ?Here are three > points that should help you on your way. > > - Just to be clear, we haven't done all our UI development in Glade. > If everything works as it should, you should only see two dialogs when > Glade opens. > > - When developing with glade, you must run './configure > --enable-build-for-glade' and then 'make' to generate a shared > library. ?We didn't make this as obvious as we should have, so I've > just re-written the sw-glade script to check for the shared library it > needs. ?You can update to get the latest version. > > - Glade gives off a lot of warnings normally, so keep that in mind. > It might be helpful to run Glade independently once just to see the > default behavior. > > ajb > > On Mon, Jun 21, 2010 at 11:10 AM, ZedTuX wrote: >> >> Hi all, >> >> >> So, as tell in the title, I want to contribute (heum... say try to >> contribute, we will see) to implement a new feature. >> Before to start anythings I'm browsing code and glade file, and there are >> my errors. >> >> I have found the bash script sw-glade that seems to be the right thing to >> start to edit GUI, but when I stat it, I have a lot of exceptions in the >> terminal. Glade open even if these exceptions occurred but it only show me >> the preferences screen. I imagine that's cause of exception. All concerned >> form haven't been loaded. >> >> Here are a copy/past of exceptions: >> http://pastie.org/1013950 >> >> Other informations: My subversion repo is up-to-date (rev 1839), and >> compilation of Shotwell is done. >> >> >> And finally my question: Why don't you use Launchpad for your project ? >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > From adam at yorba.org Mon Jun 21 21:04:15 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 14:04:15 -0700 Subject: [Shotwell] shotwell doesn't compile with 0.9.2 In-Reply-To: <57575.213.236.208.22.1277107741.squirrel@www.scorpiondata.com> References: <57575.213.236.208.22.1277107741.squirrel@www.scorpiondata.com> Message-ID: <4C1FD3CF.3080001@yorba.org> On 06/21/2010 01:09 AM, Martin Olsson wrote: > Vala git master (and the recently released 0.9.2) no longer compiles > Shotwell git master: > http://trac.yorba.org/ticket/2164 > > --- > > ColorTransformation.vala:35.9-35.33: error: unsupported lvalue in assignment > this = hsv_pixel.to_rgb(); > ^^^^^^^^^^^^^^^^^^^^^^^^^ > Thanks for the heads up, Martin. This has now been fixed in trunk. adam From adam at yorba.org Mon Jun 21 21:13:41 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 21 Jun 2010 14:13:41 -0700 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: References: Message-ID: <4C1FD605.4000700@yorba.org> ZedTux, > And finally my question: Why don't you use Launchpad for your project ? > Any open source project has lots of choices for project hosting, either external (e.g. Launchpad, GNOME, Google Code) or self-hosted (e.g. Trac, Redmine). For now, we're using our own Trac server for Yorba's projects, partly for historical reasons but also partly because it has lots of features we like that aren't necessarily offered by other services - for example, the Timeline view that shows us all recent activity. Of course, no project system is perfect and there's a chance we'll migrate to something else at some point. adam From zedtux at zedroot.org Tue Jun 22 07:34:07 2010 From: zedtux at zedroot.org (ZedTuX ZedR00t) Date: Tue, 22 Jun 2010 09:34:07 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C1FD605.4000700@yorba.org> References: <4C1FD605.4000700@yorba.org> Message-ID: <4C20676F.3000702@zedroot.org> Hello Adam, Okay. I have asked this question because for code submitting, Launchpad (like github) offer very good features. Anyway, I prefer to work with Launchpad an Bazaar, so as I saw an automatic import in Launchpad for Shotwell, I will build my own branch and when I will have finished, I will do a patch or you will merge it your self, if my feature and code are accepted ;) For the timeline feature, you're right. Lauchpad is missing it: A central point where everything happening in code, tickets, etc ... are displayed. I have found a blueprint for it: https://blueprints.launchpad.net/launchpad-foundations/+spec/timeline/ Adam Dingle wrote: > ZedTux, > >> And finally my question: Why don't you use Launchpad for your project ? >> >> > > Any open source project has lots of choices for project hosting, either > external (e.g. Launchpad, GNOME, Google Code) or self-hosted (e.g. Trac, > Redmine). For now, we're using our own Trac server for Yorba's > projects, partly for historical reasons but also partly because it has > lots of features we like that aren't necessarily offered by other > services - for example, the Timeline view that shows us all recent > activity. Of course, no project system is perfect and there's a chance > we'll migrate to something else at some point. > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From zedtux at zedroot.org Tue Jun 22 07:45:08 2010 From: zedtux at zedroot.org (ZedTuX ZedR00t) Date: Tue, 22 Jun 2010 09:45:08 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: References: Message-ID: <4C206A04.1090003@zedroot.org> Hi Allison, First off, big thanks for your quick answer, help and fix ! :) Why don't you done all GUI part with Glade ? I mean, is there a big reason, or just because you don't really like it or anything else ? On my point of view, I prefer to use Glade as much as I can for the GUI part, and just connect callback to my classes. I think I must be clear with all of you on that point if I want to implement something. Well, let me have a try with your help. Wait and see :) So, my feature ! :) In order to found all pictures with a given person As a user I want to be able to define in each pictures how is present on it. And maybe, if all run good, implement library for face recognition. But in a first step, I just want to have the possibility to set who is on the picture, and then have a screen with all faces, select one, and this all that pictures. I have think about a shape that the user can move of the picture, and re-size it, and the name, just under, of that person. I also want to link that person to the address book of Ubuntu ( I don't see any way for Window ? ). If you have any comments, idea, suggestion, etc ... do not hesitate to contact me ! :) Allison Barlow wrote: > Also, which feature were you hoping to implement? :) > > ajb > > On Mon, Jun 21, 2010 at 1:14 PM, Allison Barlow wrote: > >> Hello! >> >> First off, it's great that you want to contribute! Here are three >> points that should help you on your way. >> >> - Just to be clear, we haven't done all our UI development in Glade. >> If everything works as it should, you should only see two dialogs when >> Glade opens. >> >> - When developing with glade, you must run './configure >> --enable-build-for-glade' and then 'make' to generate a shared >> library. We didn't make this as obvious as we should have, so I've >> just re-written the sw-glade script to check for the shared library it >> needs. You can update to get the latest version. >> >> - Glade gives off a lot of warnings normally, so keep that in mind. >> It might be helpful to run Glade independently once just to see the >> default behavior. >> >> ajb >> >> On Mon, Jun 21, 2010 at 11:10 AM, ZedTuX wrote: >> >>> Hi all, >>> >>> >>> So, as tell in the title, I want to contribute (heum... say try to >>> contribute, we will see) to implement a new feature. >>> Before to start anythings I'm browsing code and glade file, and there are >>> my errors. >>> >>> I have found the bash script sw-glade that seems to be the right thing to >>> start to edit GUI, but when I stat it, I have a lot of exceptions in the >>> terminal. Glade open even if these exceptions occurred but it only show me >>> the preferences screen. I imagine that's cause of exception. All concerned >>> form haven't been loaded. >>> >>> Here are a copy/past of exceptions: >>> http://pastie.org/1013950 >>> >>> Other informations: My subversion repo is up-to-date (rev 1839), and >>> compilation of Shotwell is done. >>> >>> >>> And finally my question: Why don't you use Launchpad for your project ? >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> From pdo.smith at gmail.com Tue Jun 22 08:23:42 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 22 Jun 2010 10:23:42 +0200 Subject: [Shotwell] MD5 fields in PhotoTable Message-ID: I see that you store the following MD5 fields in PhotoTable md5 thumbnail_md5 exif_md5 The file md5 is used for detecting photo duplicates but why do you keep the thumbnail_md5 and exif_md5 in PhotoTable? Peter From pdo.smith at gmail.com Tue Jun 22 09:00:49 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 22 Jun 2010 11:00:49 +0200 Subject: [Shotwell] Front end API or DB access? Message-ID: I want to adapt the photo processing front end I wrote for my own photographic workflow to Shotwell. It is written in Python. I pre-process my photos and then submit them to Shotwell. For the moment I plan to integrate with Shotwell by writing the relevant information into the sqlite database and creating the thumbnails. An alternative approach would be for you to provide an API or batch import program which my routine would call. This approach might be best as it would decouple my program from your database implementation details. I would welcome your thoughts on this matter. Peter From brunogirin at gmail.com Tue Jun 22 10:15:34 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 22 Jun 2010 11:15:34 +0100 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C206A04.1090003@zedroot.org> References: <4C206A04.1090003@zedroot.org> Message-ID: <1277201734.1544.19.camel@nuuk> On Tue, 2010-06-22 at 09:45 +0200, ZedTuX ZedR00t wrote: > Hi Allison, > > First off, big thanks for your quick answer, help and fix ! :) > > Why don't you done all GUI part with Glade ? I mean, is there a big > reason, or just because you don't really like it or anything else ? > On my point of view, I prefer to use Glade as much as I can for the GUI > part, and just connect callback to my classes. > I think I must be clear with all of you on that point if I want to > implement something. > > Well, let me have a try with your help. Wait and see :) > > > So, my feature ! :) > > In order to found all pictures with a given person > As a user > I want to be able to define in each pictures how is present on it. > > And maybe, if all run good, implement library for face recognition. > But in a first step, I just want to have the possibility to set who is > on the picture, and then have a screen with all faces, select one, and > this all that pictures. > I have think about a shape that the user can move of the picture, and > re-size it, and the name, just under, of that person. This is ticket 1702: http://trac.yorba.org/ticket/1702 I would split in into 2 parts though: 1. People view: add the view first, similar to the Events view where you can specify who is in the picture, 2. Face recognition: this feature will also have to include a learning mechanism, a bit like the latest iPhoto does so that you can tell it when it got the face right and when it got it wrong. > I also want to link that person to the address book of Ubuntu ( I don't > see any way for Window ? ). That's an interesting feature, it should probably be added to Trac as a new enhancement :-) Bruno From brunogirin at gmail.com Tue Jun 22 10:22:46 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 22 Jun 2010 11:22:46 +0100 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C20676F.3000702@zedroot.org> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> Message-ID: <1277202166.1544.26.camel@nuuk> On Tue, 2010-06-22 at 09:34 +0200, ZedTuX ZedR00t wrote: > Hello Adam, > > Okay. I have asked this question because for code submitting, Launchpad > (like github) offer very good features. > Anyway, I prefer to work with Launchpad an Bazaar, so as I saw an > automatic import in Launchpad for Shotwell, I will build my own branch > and when I will have finished, I will do a patch or you will merge it > your self, if my feature and code are accepted ;) The process I have been using, as an external contributor is: * Assign myself to the ticket (in your case 1702) * Get the code out of SVN trunk, as described in the download source section on this page: http://yorba.org/shotwell/install/ * Implement the feature locally, making sure to run svn update on a regular basis to have the latest changes * Attach the output of svn diff to the ticket I think the important thing is that the work you do be attached to a ticket in Trac so that it doesn't come as a complete surprise when you submit it. Also, having it in Trac means that it's easy to attach your patch to the ticket, irrespective of whether you go the Launchpad or the SVN route. Bruno From pdo.smith at gmail.com Tue Jun 22 10:48:50 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 22 Jun 2010 12:48:50 +0200 Subject: [Shotwell] MD5 fields in PhotoTable In-Reply-To: References: Message-ID: OK, I see the answer in line 697 of BatchImport.vala But why not simply do a full file MD5 all the time? Or is this to save processing time? On Tue, Jun 22, 2010 at 10:23 AM, Peter DO Smith wrote: > I see that you store the following MD5 fields in PhotoTable > md5 > thumbnail_md5 > exif_md5 > > The file md5 is used for detecting photo duplicates but why do you > keep the thumbnail_md5 and exif_md5 ?in PhotoTable? > > Peter > From zedtux at zedroot.org Tue Jun 22 11:10:58 2010 From: zedtux at zedroot.org (ZedTuX ZedR00t) Date: Tue, 22 Jun 2010 13:10:58 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <1277202166.1544.26.camel@nuuk> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> Message-ID: <4C209A42.4000704@zedroot.org> Hi Bruno, and thanks for all your information. Just to be sure to be clear with you, in a first step I will not implement face recognition, but a feature to be able to define who is on the picture manually. I'm ok to work on a copy of the trunk and just put a svn diff in the ticket, but svn (and others) have the feature to create branches. Why shouldn't I create a branch that I maintain myself (merging) to do my work ? Well, thanks for your help ! :) Bruno Girin wrote: > On Tue, 2010-06-22 at 09:34 +0200, ZedTuX ZedR00t wrote: > >> Hello Adam, >> >> Okay. I have asked this question because for code submitting, Launchpad >> (like github) offer very good features. >> Anyway, I prefer to work with Launchpad an Bazaar, so as I saw an >> automatic import in Launchpad for Shotwell, I will build my own branch >> and when I will have finished, I will do a patch or you will merge it >> your self, if my feature and code are accepted ;) >> > > The process I have been using, as an external contributor is: > * Assign myself to the ticket (in your case 1702) > * Get the code out of SVN trunk, as described in the download > source section on this page: http://yorba.org/shotwell/install/ > * Implement the feature locally, making sure to run svn update on > a regular basis to have the latest changes > * Attach the output of svn diff to the ticket > > I think the important thing is that the work you do be attached to a > ticket in Trac so that it doesn't come as a complete surprise when you > submit it. Also, having it in Trac means that it's easy to attach your > patch to the ticket, irrespective of whether you go the Launchpad or the > SVN route. > > Bruno > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From brunogirin at gmail.com Tue Jun 22 11:46:52 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 22 Jun 2010 12:46:52 +0100 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C209A42.4000704@zedroot.org> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> <4C209A42.4000704@zedroot.org> Message-ID: <1277207212.1544.66.camel@nuuk> On Tue, 2010-06-22 at 13:10 +0200, ZedTuX ZedR00t wrote: > Hi Bruno, and thanks for all your information. > > Just to be sure to be clear with you, in a first step I will not > implement face recognition, but a feature to be able to define who is > on the picture manually. > > I'm ok to work on a copy of the trunk and just put a svn diff in the > ticket, but svn (and others) have the feature to create branches. Why > shouldn't I create a branch that I maintain myself (merging) to do my > work ? The reason for this is that version control software generally use one of two models: 1. centralised model like CVS or SVN 2. de-centralised model like git or bzr (Launchpad uses bzr) In model #1, everything is kept in a central repository (in the case of Shotwell that's the Yorba SVN repository) and any update or branch actually affects that repository. This is well suited to situations where you have a core development team or a single organisation that is responsible for maintaining the software. In model #2, there is no central repository (although there is usually a trunk somewhere that holds the "official" version) and every contributor can create his own branch without affecting anyone else. Branches can be merged with one another easily and the software is generally packaged from a well known branch: in the case of Launchpad, the software is packaged from the Launchpad trunk branch. This is well suited to situations like a lot of open source projects where there is no central development team but a group of de-centralised contributors. Having said this, Yorba use model #1 so in order to create a branch in the SVN repository, you would need write access to that repository, which only core developers have the ability to do. Furthermore, merging back in model #1 is more complicated than with model #2 (which is exactly the problem that Linus Torvald tried to solve when he created git). In practice, when dealing with a source control system that uses model #1, it is easier to create patches and let the core team integrate those patches. Now, if Shotwell starts seeing a lot more external contributions, it may be sensible at some point to move to model #2 but for now model #1 is more adapted. I hope this explanation helps and wasn't too confusing :-) Bruno From brunogirin at gmail.com Tue Jun 22 11:56:14 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 22 Jun 2010 12:56:14 +0100 Subject: [Shotwell] MD5 fields in PhotoTable In-Reply-To: References: Message-ID: <1277207774.1544.74.camel@nuuk> On Tue, 2010-06-22 at 12:48 +0200, Peter DO Smith wrote: > OK, I see the answer in line 697 of BatchImport.vala > But why not simply do a full file MD5 all the time? Or is this to save > processing time? Not just processing time, it's for general performance. When you are dealing with photos in the library, the difference is probably negligible. However, when you are dealing with import, you have to take into account that the photograph you import may take a long time to download: a USB connection to a camera is a lot slower than disk access and it would be even worse the day you allow imports from an external service over the network for instance. So by having a thumbnail hash, you only need to load the thumbnail in order to calculate the hash. That way, you can check for duplicates without having to load the whole picture, which could take a very long time for large RAW files (definitely several seconds per image on my Canon EOS 5D and I may have hundreds of them on a 8GB card). And in terms of user experience, it's better to be able to tell users "this photograph has already been imported" before loading it rather than after. Bruno From zedtux at zedroot.org Tue Jun 22 11:57:07 2010 From: zedtux at zedroot.org (ZedTuX ZedR00t) Date: Tue, 22 Jun 2010 13:57:07 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <1277207212.1544.66.camel@nuuk> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> <4C209A42.4000704@zedroot.org> <1277207212.1544.66.camel@nuuk> Message-ID: <4C20A513.2000006@zedroot.org> Yes it help. (Already know how works and you just give me the answer I was waiting for: in order to create a branch in the SVN repository, you would need write access to that repository, which only core developers have the ability to do. Okay, I will do like you told me before and basta. Thanks Bruno Girin wrote: > On Tue, 2010-06-22 at 13:10 +0200, ZedTuX ZedR00t wrote: > >> Hi Bruno, and thanks for all your information. >> >> Just to be sure to be clear with you, in a first step I will not >> implement face recognition, but a feature to be able to define who is >> on the picture manually. >> >> I'm ok to work on a copy of the trunk and just put a svn diff in the >> ticket, but svn (and others) have the feature to create branches. Why >> shouldn't I create a branch that I maintain myself (merging) to do my >> work ? >> > > The reason for this is that version control software generally use one > of two models: > 1. centralised model like CVS or SVN > 2. de-centralised model like git or bzr (Launchpad uses bzr) > > In model #1, everything is kept in a central repository (in the case of > Shotwell that's the Yorba SVN repository) and any update or branch > actually affects that repository. This is well suited to situations > where you have a core development team or a single organisation that is > responsible for maintaining the software. > > In model #2, there is no central repository (although there is usually a > trunk somewhere that holds the "official" version) and every contributor > can create his own branch without affecting anyone else. Branches can be > merged with one another easily and the software is generally packaged > from a well known branch: in the case of Launchpad, the software is > packaged from the Launchpad trunk branch. This is well suited to > situations like a lot of open source projects where there is no central > development team but a group of de-centralised contributors. > > Having said this, Yorba use model #1 so in order to create a branch in > the SVN repository, you would need write access to that repository, > which only core developers have the ability to do. Furthermore, merging > back in model #1 is more complicated than with model #2 (which is > exactly the problem that Linus Torvald tried to solve when he created > git). In practice, when dealing with a source control system that uses > model #1, it is easier to create patches and let the core team integrate > those patches. > > Now, if Shotwell starts seeing a lot more external contributions, it may > be sensible at some point to move to model #2 but for now model #1 is > more adapted. > > I hope this explanation helps and wasn't too confusing :-) > > Bruno > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From keith.m.duncan at gmail.com Tue Jun 22 12:35:14 2010 From: keith.m.duncan at gmail.com (Keith Duncan) Date: Tue, 22 Jun 2010 13:35:14 +0100 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> Message-ID: On 21 June 2010 16:35, Peter DO Smith wrote: > On Mon, Jun 21, 2010 at 5:23 PM, Adam Dingle wrote: > > > > > We plan to implement arbitrary boolean searches at some point; this is > > http://trac.yorba.org/ticket/1587 . Once that's implemented, you'll be > > able to combine criteria in arbitrary ways; > > > The beauty of selecting multiple tags is the speed and simplicity of > the operation. It doesn't do away with the need for a more > comprehensive search. But I am sure a multiple tag selection facility > is the one I would use by far the most often.. > With apologies if Im hijacking the this thread (I am new to the list) , but as its semi-related ... 1. This may already be covered by the planned boolean search, but I think it may also be useful to have the option to search for photos that are untagged and/or perhaps photos that are imported could be auto-assigned a tag (eg current date) (esp perhaps if there is no EXIF data? eg "No-EXIF-photos-imported-YYYY-MM-DD_at_HHMMSS"). 2. Less of an issue(?) - "adding new tags where existing similar tags may exist" As the list of tags grows, I dont want to have to remember if I have the tag "Family Holidays" or "Family holidays", or was it "family holidays" (or even "family", "holidays" or "Holidays - family" etc). Yes I know I could browse the long... list of tags and drag/drop photos to existing tags, but there are other times I might want to quickly perform an "Add Tag" op before checking if anything like it already exists. I think it _may_ be useful if some sort of prompt was given advising of existing similar tag(s) that are nearly the same and then to have the option to use these tags as well as or (more likely) instead of or alternatively create a new substantially different tag. eg instead of adding a new tag "landscape" where an existing tag of "Landscapes" exists, I should be warned/prompted. 3. Related to 2 above, perhaps the option to merge tags/photos could be built into some form of "health status/repair tool" that also offers other functionality (eg photo has gone away - do also you want to update Shotwell). In closing I would like to say that I really like Shotwell - its only recently that I have started using it but I do like what I see. I would echo Peter's earlier comment - the team deserve full marks - keep up the good work. From zedtux at zedroot.org Tue Jun 22 12:41:25 2010 From: zedtux at zedroot.org (ZedTuX ZedR00t) Date: Tue, 22 Jun 2010 14:41:25 +0200 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C20A513.2000006@zedroot.org> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> <4C209A42.4000704@zedroot.org> <1277207212.1544.66.camel@nuuk> <4C20A513.2000006@zedroot.org> Message-ID: <4C20AF75.6020504@zedroot.org> Another question: What about testing ? And can see any pages about it else this empty one: http://trac.yorba.org/wiki/ShotwellTestPlan ZedTuX ZedR00t wrote: > Yes it help. (Already know how works and you just give me the answer I > was waiting for: > > in order to create a branch in > the SVN repository, you would need write access to that repository, > which only core developers have the ability to do. > > Okay, I will do like you told me before and basta. > > Thanks > > Bruno Girin wrote: > >> On Tue, 2010-06-22 at 13:10 +0200, ZedTuX ZedR00t wrote: >> >> >>> Hi Bruno, and thanks for all your information. >>> >>> Just to be sure to be clear with you, in a first step I will not >>> implement face recognition, but a feature to be able to define who is >>> on the picture manually. >>> >>> I'm ok to work on a copy of the trunk and just put a svn diff in the >>> ticket, but svn (and others) have the feature to create branches. Why >>> shouldn't I create a branch that I maintain myself (merging) to do my >>> work ? >>> >>> >> The reason for this is that version control software generally use one >> of two models: >> 1. centralised model like CVS or SVN >> 2. de-centralised model like git or bzr (Launchpad uses bzr) >> >> In model #1, everything is kept in a central repository (in the case of >> Shotwell that's the Yorba SVN repository) and any update or branch >> actually affects that repository. This is well suited to situations >> where you have a core development team or a single organisation that is >> responsible for maintaining the software. >> >> In model #2, there is no central repository (although there is usually a >> trunk somewhere that holds the "official" version) and every contributor >> can create his own branch without affecting anyone else. Branches can be >> merged with one another easily and the software is generally packaged >> from a well known branch: in the case of Launchpad, the software is >> packaged from the Launchpad trunk branch. This is well suited to >> situations like a lot of open source projects where there is no central >> development team but a group of de-centralised contributors. >> >> Having said this, Yorba use model #1 so in order to create a branch in >> the SVN repository, you would need write access to that repository, >> which only core developers have the ability to do. Furthermore, merging >> back in model #1 is more complicated than with model #2 (which is >> exactly the problem that Linus Torvald tried to solve when he created >> git). In practice, when dealing with a source control system that uses >> model #1, it is easier to create patches and let the core team integrate >> those patches. >> >> Now, if Shotwell starts seeing a lot more external contributions, it may >> be sensible at some point to move to model #2 but for now model #1 is >> more adapted. >> >> I hope this explanation helps and wasn't too confusing :-) >> >> Bruno >> >> >> _______________________________________________ >> 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 Jun 22 16:04:58 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 22 Jun 2010 09:04:58 -0700 Subject: [Shotwell] Front end API or DB access? In-Reply-To: References: Message-ID: <4C20DF2A.10500@yorba.org> On 06/22/2010 02:00 AM, Peter DO Smith wrote: > I want to adapt the photo processing front end I wrote for my own > photographic workflow to Shotwell. It is written in Python. I > pre-process my photos and then submit them to Shotwell. For the moment > I plan to integrate with Shotwell by writing the relevant information > into the sqlite database and creating the thumbnails. > > An alternative approach would be for you to provide an API or batch > import program which my routine would call. This approach might be > best as it would decouple my program from your database implementation > details. > > I would welcome your thoughts on this matter. > Peter, we agree that it would be great to have some mechanism that would let your code interact with Shotwell. We're considering three mechanisms, none of which are implemented yet: 1) We could extend Shotwell to have plugins which can add new commands to Shotwell menus and can extend Shotwell with arbitrary functionality, like plugins in other applications such as gedit. This is http://trac.yorba.org/ticket/1603 . 2) We could provide a shared library which your program can call to interact with the Shotwell database. This is http://trac.yorba.org/ticket/1698 . 3) We could provide a D-Bus or REST-based API that allows external programs to interact with the running Shotwell instance. This is http://trac.yorba.org/ticket/1699 . We've made no decisions yet about which of these to implement and when, and would welcome feedback from you and others about which of these you'd find most useful. cheers adam From adam at yorba.org Tue Jun 22 16:17:53 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 22 Jun 2010 09:17:53 -0700 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> Message-ID: <4C20E231.2090208@yorba.org> On 06/22/2010 05:35 AM, Keith Duncan wrote: > >> The beauty of selecting multiple tags is the speed and simplicity of >> the operation. It doesn't do away with the need for a more >> comprehensive search. But I am sure a multiple tag selection facility >> is the one I would use by far the most often.. >> >> > With apologies if Im hijacking the this thread (I am new to the list) , but > as its semi-related ... > No problem - feel free to jump into any discussion around here. :) > 1. This may already be covered by the planned boolean search, but I think it > may also be useful to have the option to search for photos that are untagged > and/or perhaps photos that are imported could be auto-assigned a tag (eg > current date) (esp perhaps if there is no EXIF data? eg > "No-EXIF-photos-imported-YYYY-MM-DD_at_HHMMSS"). > Agreed: these capabilities could be useful. See http://trac.yorba.org/ticket/1609 and http://trac.yorba.org/ticket/1586 . > 2. Less of an issue(?) - "adding new tags where existing similar tags may > exist" > > As the list of tags grows, I dont want to have to remember if I have the > tag "Family Holidays" or "Family holidays", or was it "family holidays" (or > even "family", "holidays" or "Holidays - family" etc). > > Yes I know I could browse the long... list of tags and drag/drop photos to > existing tags, but there are other times I might want to quickly perform an > "Add Tag" op before checking if anything like it already exists. I think > it _may_ be useful if some sort of prompt was given advising of existing > similar tag(s) that are nearly the same and then to have the option to use > these tags as well as or (more likely) instead of or alternatively create a > new substantially different tag. > You're right that if you have lots of tags today, it's hard to see the tags that are similar to a given name. Before long we'd like to implement tag autocompletion (http://trac.yorba.org/ticket/1334) which should help with this: you'll be able to type part of any tag name and possible matches will appear in a dropdown list. > eg instead of adding a new tag "landscape" where an existing tag of > "Landscapes" exists, I should be warned/prompted. > > 3. Related to 2 above, perhaps the option to merge tags/photos could be > built into some form of "health status/repair tool" that also offers other > functionality (eg photo has gone away - do also you want to update > Shotwell). > It's true that it might be convenient to have a command to merge tags. If you would find this useful then feel free to file a ticket for this. We're planning to implement directory monitoring soon (http://trac.yorba.org/ticket/374). Once we have that, Shotwell should automatically notice when photos have gone away so I hope there shouldn't be a need for a manual repair step. > In closing I would like to say that I really like Shotwell - its only > recently that I have started using it but I do like what I see. I would echo > Peter's earlier comment - the team deserve full marks - keep up the good > work. > Thanks! :) adam From pdo.smith at gmail.com Tue Jun 22 16:28:54 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 22 Jun 2010 18:28:54 +0200 Subject: [Shotwell] MD5 fields in PhotoTable In-Reply-To: <1277207774.1544.74.camel@nuuk> References: <1277207774.1544.74.camel@nuuk> Message-ID: Thanks, that makes perfect sense. On Tue, Jun 22, 2010 at 1:56 PM, Bruno Girin wrote: > On Tue, 2010-06-22 at 12:48 +0200, Peter DO Smith wrote: >> OK, I see the answer in line 697 of BatchImport.vala >> But why not simply do a full file MD5 all the time? Or is this to save >> processing time? > > Not just processing time, it's for general performance. When you are > dealing with photos in the library, the difference is probably > negligible. However, when you are dealing with import, you have to take > into account that the photograph you import may take a long time to > download: a USB connection to a camera is a lot slower than disk access > and it would be even worse the day you allow imports from an external > service over the network for instance. > > So by having a thumbnail hash, you only need to load the thumbnail in > order to calculate the hash. That way, you can check for duplicates > without having to load the whole picture, which could take a very long > time for large RAW files (definitely several seconds per image on my > Canon EOS 5D and I may have hundreds of them on a 8GB card). And in > terms of user experience, it's better to be able to tell users "this > photograph has already been imported" before loading it rather than > after. > > Bruno > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Tue Jun 22 16:30:21 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 22 Jun 2010 09:30:21 -0700 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C20AF75.6020504@zedroot.org> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> <4C209A42.4000704@zedroot.org> <1277207212.1544.66.camel@nuuk> <4C20A513.2000006@zedroot.org> <4C20AF75.6020504@zedroot.org> Message-ID: <4C20E51D.3040108@yorba.org> On 06/22/2010 05:41 AM, ZedTuX ZedR00t wrote: > Another question: What about testing ? > And can see any pages about it else this empty one: > http://trac.yorba.org/wiki/ShotwellTestPlan > ZedTuX, at the moment we test Shotwell by exercising all its features manually. We've been meaning to put a list of our manual tests on the Wiki page you found, but haven't quite gotten to that yet. Hopefully soon. We also hope to build up an automated test infrastructure for Shotwell at some point - this is http://trac.yorba.org/ticket/1068 . By the way, you've asked a lot of good questions here. I think we need to expand our wiki and/or Web site to have a bit more information about our development process so you can find out about all this without having to ask. Also hopefully coming soon. cheers adam From allison at yorba.org Tue Jun 22 16:42:28 2010 From: allison at yorba.org (Allison Barlow) Date: Tue, 22 Jun 2010 09:42:28 -0700 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C206A04.1090003@zedroot.org> References: <4C206A04.1090003@zedroot.org> Message-ID: > Why don't you done all GUI part with Glade ? I mean, is there a big reason, > or just because you don't really like it or anything else ? We didn't start off in Glade because the GUI was very simple originally. As it got more complicated, we saw the advantages of using a program like Glade, but we just haven't gotten around to moving everything over yet. As you can see, we've recently started the transition, but we've only moved individual elements as they're modified. ajb From pdo.smith at gmail.com Tue Jun 22 16:46:44 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Tue, 22 Jun 2010 18:46:44 +0200 Subject: [Shotwell] Front end API or DB access? In-Reply-To: References: <4C20DF2A.10500@yorba.org> Message-ID: My votes goes to 2, a shared library, as it should not be necessary for Shotwell to be running when I start my program. A good starting point would be to write a command line version of BatchImport where I could specify a source directory and optionally some tags and a destination event. For example: shotwell_import -d camera|folder -t tag,list -e photo_event On Tue, Jun 22, 2010 at 6:04 PM, Adam Dingle wrote: > On 06/22/2010 02:00 AM, Peter DO Smith wrote: >> I want to adapt the photo processing front end I wrote for my own >> photographic workflow to Shotwell. It is written in Python. I >> pre-process my photos and then submit them to Shotwell. For the moment >> I plan to integrate with Shotwell by writing the relevant information >> into the sqlite database and creating the thumbnails. >> >> An alternative approach would be for you to provide an API or batch >> import program which my routine would call. This approach might be >> best as it would decouple my program from your database implementation >> details. >> >> I would welcome your thoughts on this matter. >> > > Peter, > > we agree that it would be great to have some mechanism that would let > your code interact with Shotwell. ?We're considering three mechanisms, > none of which are implemented yet: > > 1) We could extend Shotwell to have plugins which can add new commands > to Shotwell menus and can extend Shotwell with arbitrary functionality, > like plugins in other applications such as gedit. ?This is > http://trac.yorba.org/ticket/1603 . > > 2) We could provide a shared library which your program can call to > interact with the Shotwell database. ?This is > http://trac.yorba.org/ticket/1698 . > > 3) We could provide a D-Bus or REST-based API that allows external > programs to interact with the running Shotwell instance. ?This is > http://trac.yorba.org/ticket/1699 . > > We've made no decisions yet about which of these to implement and when, > and would welcome feedback from you and others about which of these > you'd find most useful. > > cheers > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From svetoslav.trochev at gmail.com Tue Jun 22 16:49:29 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Tue, 22 Jun 2010 09:49:29 -0700 Subject: [Shotwell] Tags enhancement In-Reply-To: <4C20E231.2090208@yorba.org> References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> <4C20E231.2090208@yorba.org> Message-ID: > We're planning to implement directory monitoring soon > (http://trac.yorba.org/ticket/374). ?Once we have that, Shotwell should > automatically notice when photos have gone away so I hope there > shouldn't be a need for a manual repair step. > > > adam > Adam, are you planning to have this feature enabled/disabled per directory? This is the main reason why I started using Shotwell. Currently I can import (without local copy) my archived photos located on my NAS and I have them in the DB for search, but I am not connected to my NAS at all time. I would hate to see archived photos deleted from my DB at this moment. I read the ticket, but there is nothing about how it is going to work. Where I can read more about it? Thank you, Svetoslav From adam at yorba.org Tue Jun 22 17:13:00 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 22 Jun 2010 10:13:00 -0700 Subject: [Shotwell] Tags enhancement In-Reply-To: References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> <4C20E231.2090208@yorba.org> Message-ID: <4C20EF1C.5050503@yorba.org> On 06/22/2010 09:49 AM, Svetoslav Trochev wrote: >> We're planning to implement directory monitoring soon >> (http://trac.yorba.org/ticket/374). Once we have that, Shotwell should >> automatically notice when photos have gone away so I hope there >> shouldn't be a need for a manual repair step. >> >> >> adam > Adam, are you planning to have this feature enabled/disabled per > directory? This is the main reason why I started using Shotwell. > Currently I can import (without local copy) my archived photos located > on my NAS and I have them in the DB for search, but I am not connected > to my NAS at all time. I would hate to see archived photos deleted > from my DB at this moment. I read the ticket, but there is nothing > about how it is going to work. Where I can read more about it? > > Thank you, > Svetoslav > Svetoslav, we haven't yet designed this feature in detail so there's nothing more to read at this moment. But we're going to start work on 0.7 soon, and directory monitoring is high on our list so we'll be thinking much more about this soon. The use case you described is important. I think we'll either need to (a) detect when a filesystem is offline, in which case we *won't* delete its files from the database even though they are inaccessible, and/or (b) allow the user to enable/disable monitoring per directory (like in Picasa, for example). Still undecided. adam From brunogirin at gmail.com Tue Jun 22 17:25:45 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Tue, 22 Jun 2010 18:25:45 +0100 Subject: [Shotwell] Want to contribute but I have some problems here and a question. In-Reply-To: <4C20E51D.3040108@yorba.org> References: <4C1FD605.4000700@yorba.org> <4C20676F.3000702@zedroot.org> <1277202166.1544.26.camel@nuuk> <4C209A42.4000704@zedroot.org> <1277207212.1544.66.camel@nuuk> <4C20A513.2000006@zedroot.org> <4C20AF75.6020504@zedroot.org> <4C20E51D.3040108@yorba.org> Message-ID: <1277227545.1744.48.camel@nuuk> On Tue, 2010-06-22 at 09:30 -0700, Adam Dingle wrote: > On 06/22/2010 05:41 AM, ZedTuX ZedR00t wrote: > > Another question: What about testing ? > > And can see any pages about it else this empty one: > > http://trac.yorba.org/wiki/ShotwellTestPlan > > > > ZedTuX, > > at the moment we test Shotwell by exercising all its features manually. > We've been meaning to put a list of our manual tests on the Wiki page > you found, but haven't quite gotten to that yet. Hopefully soon. Great :-) We can then simplify the Ubuntu test cases page when we come round to doing it by pointing to the wiki rather than repeat what's there. And that would also prevent the Ubuntu ones from going stale. Bruno From topher at t1kdev.com Tue Jun 22 17:53:21 2010 From: topher at t1kdev.com (Topher) Date: Tue, 22 Jun 2010 13:53:21 -0400 (EDT) Subject: [Shotwell] crash issue Message-ID: Hey there, I'm trying Shotwell for the first time today, and I can get a consistent crash. First my system: Dell E6400 running Arch Linux. I installed with pacman, not from scratch. It runs fine, I imported all my pictures. When I choose one to publish, it brings up a box that says I'm not logged into Flickr. I click to log in, it brings up a box that looks like it wants to load Flickr's page, and I get this, followed by shotwell dying completely (note at the very end it talks about Java after giving me a new prompt). Any ideas? [topher at sheldon ~]$ shotwell *** glibc detected *** shotwell: free(): invalid pointer: 0x09b93da0 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c7b1)[0xb5d0b7b1] /lib/libc.so.6(+0x6d52b)[0xb5d0c52b] /lib/libc.so.6(cfree+0x6d)[0xb5d101cd] /usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb5e2cd16] /usr/lib/libglib-2.0.so.0(g_strfreev+0x20)[0xb5e481e0] /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so(NP_Initialize+0x761)[0xac925ad1] /usr/lib/libwebkit-1.0.so.2(+0x75ee0a)[0xb6dede0a] /usr/lib/libwebkit-1.0.so.2(+0x75eee4)[0xb6dedee4] /usr/lib/libwebkit-1.0.so.2(+0x51c4d9)[0xb6bab4d9] /usr/lib/libwebkit-1.0.so.2(+0x516329)[0xb6ba5329] /usr/lib/libwebkit-1.0.so.2(+0x51704d)[0xb6ba604d] /usr/lib/libwebkit-1.0.so.2(+0x75e5f0)[0xb6ded5f0] /usr/lib/libwebkit-1.0.so.2(+0x5137e5)[0xb6ba27e5] /usr/lib/libwebkit-1.0.so.2(+0x49762b)[0xb6b2662b] /usr/lib/libwebkit-1.0.so.2(+0x512c54)[0xb6ba1c54] /usr/lib/libwebkit-1.0.so.2(+0x512caf)[0xb6ba1caf] /usr/lib/libwebkit-1.0.so.2(+0x1a5e17)[0xb6834e17] /usr/lib/libwebkit-1.0.so.2(+0xbdf561)[0xb726e561] /usr/lib/libwebkit-1.0.so.2(+0x861e65)[0xb6ef0e65] /usr/lib/libwebkit-1.0.so.2(+0x862313)[0xb6ef1313] /usr/lib/libwebkit-1.0.so.2(+0x860b05)[0xb6eefb05] [0xb424c78d] /usr/lib/libwebkit-1.0.so.2(+0x869d62)[0xb6ef8d62] /usr/lib/libwebkit-1.0.so.2(+0x935b64)[0xb6fc4b64] /usr/lib/libwebkit-1.0.so.2(+0x1c3665)[0xb6852665] /usr/lib/libwebkit-1.0.so.2(+0x1c3d19)[0xb6852d19] /usr/lib/libwebkit-1.0.so.2(+0x1d9e47)[0xb6868e47] /usr/lib/libwebkit-1.0.so.2(+0x3ba328)[0xb6a49328] /usr/lib/libwebkit-1.0.so.2(+0x3bf970)[0xb6a4e970] /usr/lib/libwebkit-1.0.so.2(+0x3c097b)[0xb6a4f97b] /usr/lib/libwebkit-1.0.so.2(+0x3c3e7e)[0xb6a52e7e] /usr/lib/libwebkit-1.0.so.2(+0x3c4926)[0xb6a53926] /usr/lib/libwebkit-1.0.so.2(+0x424016)[0xb6ab3016] /usr/lib/libwebkit-1.0.so.2(+0x424687)[0xb6ab3687] /usr/lib/libwebkit-1.0.so.2(+0x7b2372)[0xb6e41372] /usr/lib/libwebkit-1.0.so.2(+0x41fdb7)[0xb6aaedb7] /usr/lib/libwebkit-1.0.so.2(+0x40fcc5)[0xb6a9ecc5] /usr/lib/libwebkit-1.0.so.2(+0x41f19b)[0xb6aae19b] /usr/lib/libwebkit-1.0.so.2(+0x43abf9)[0xb6ac9bf9] /usr/lib/libwebkit-1.0.so.2(+0x44b75e)[0xb6ada75e] /usr/lib/libwebkit-1.0.so.2(+0x43b1e0)[0xb6aca1e0] /usr/lib/libwebkit-1.0.so.2(+0x44a1a8)[0xb6ad91a8] /usr/lib/libwebkit-1.0.so.2(+0x799961)[0xb6e28961] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXED+0x88)[0xb5ee3ba8] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2)[0xb5eca252] /usr/lib/libgobject-2.0.so.0(+0x18d70)[0xb5ed9d70] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7fe)[0xb5ee280e] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0xb5ee29b6] /usr/lib/libsoup-2.4.so.1(soup_message_got_chunk+0x36)[0xb62a99e6] /usr/lib/libsoup-2.4.so.1(+0x2ad3c)[0xb62add3c] /usr/lib/libsoup-2.4.so.1(+0x2ba2b)[0xb62aea2b] /usr/lib/libsoup-2.4.so.1(+0x2c377)[0xb62af377] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x7c)[0xb5ee312c] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2)[0xb5eca252] /usr/lib/libgobject-2.0.so.0(+0x18d70)[0xb5ed9d70] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7fe)[0xb5ee280e] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0xb5ee29b6] /usr/lib/libsoup-2.4.so.1(+0x3916d)[0xb62bc16d] /usr/lib/libglib-2.0.so.0(+0x7ec7b)[0xb5e69c7b] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1d2)[0xb5e25f72] /usr/lib/libglib-2.0.so.0(+0x3b750)[0xb5e26750] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x18b)[0xb5e26dfb] /usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_run+0x1bf)[0xb63750ef] ======= Memory map: ======== 08048000-081ac000 r-xp 00000000 08:06 792986 /usr/bin/shotwell 081ac000-081ae000 rw-p 00164000 08:06 792986 /usr/bin/shotwell 09201000-09ba2000 rw-p 00000000 00:00 0 [heap] a9740000-a9801000 r-xp 00000000 08:06 790673 /usr/lib/libasound.so.2.0.0 a9801000-a9805000 rw-p 000c1000 08:06 790673 /usr/lib/libasound.so.2.0.0 a9805000-a9912000 r-xp 00000000 08:06 794801 /usr/lib/libnss3.so a9912000-a9916000 rw-p 0010c000 08:06 794801 /usr/lib/libnss3.so a9916000-a9917000 rw-p 00000000 00:00 0 a9917000-a9939000 r-xp 00000000 08:06 794796 /usr/lib/libsmime3.so a9939000-a993b000 rw-p 00022000 08:06 794796 /usr/lib/libsmime3.so a993b000-a9967000 r-xp 00000000 08:06 794797 /usr/lib/libssl3.so a9967000-a9969000 rw-p 0002c000 08:06 794797 /usr/lib/libssl3.so a9969000-a9ab5000 r-xp 00000000 08:06 4616765 /usr/lib/xulrunner-1.9.2/libmozjs.so a9ab5000-a9abc000 rw-p 0014c000 08:06 4616765 /usr/lib/xulrunner-1.9.2/libmozjs.so a9abc000-a9abd000 rw-p 00000000 00:00 0 a9abd000-a9b33000 r-xp 00000000 08:06 4616745 /usr/lib/xulrunner-1.9.2/libsqlite3.so a9b33000-a9b35000 rw-p 00076000 08:06 4616745 /usr/lib/xulrunner-1.9.2/libsqlite3.so a9b35000-a9b65000 r-xp 00000000 08:06 794462 /usr/lib/libnspr4.so a9b65000-a9b66000 rw-p 00030000 08:06 794462 /usr/lib/libnspr4.so a9b66000-a9b68000 rw-p 00000000 00:00 0 a9b68000-aa73b000 r-xp 00000000 08:06 4616740 /usr/lib/xulrunner-1.9.2/libxul.so aa73b000-aa820000 rw-p 00bd3000 08:06 4616740 /usr/lib/xulrunner-1.9.2/libxul.so aa820000-aa833000 rw-p 00000000 00:00 0 aa833000-aa8fc000 r-xp 00000000 08:06 3681052 /usr/lib/openoffice/basis-link/ure-link/lib/libstlport_gcc.so aa8fc000-aa8ff000 rw-p 000c9000 08:06 3681052 /usr/lib/openoffice/basis-link/ure-link/lib/libstlport_gcc.so aa8ff000-aaa40000 rw-p 00000000 00:00 0 aaa40000-aaa43000 r-xp 00000000 08:06 793743 /usr/lib/libxcb-atom.so.1.0.0 aaa43000-aaa44000 rw-p 00002000 08:06 793743 /usr/lib/libxcb-atom.so.1.0.0 aaa44000-aaa46000 r-xp 00000000 08:06 793745 /usr/lib/libxcb-event.so.1.0.0 aaa46000-aaa47000 rw-p 00001000 08:06 793745 /usr/lib/libxcb-event.so.1.0.0 aaa47000-aaa4e000 r-xp 00000000 08:06 795681 /usr/lib/libstartup-notification-1.so.0.0.0 aaa4e000-aaa4f000 rw-p 00007000 08:06 795681 /usr/lib/libstartup-notification-1.so.0.0.0 aaa4f000-aae5f000 rw-p 00000000 00:00 0 aae5f000-aaef5000 r-xp 00000000 08:06 796015 /usr/lib/libaspell.so.15.1.4 aaef5000-aaef9000 rw-p 00095000 08:06 796015 /usr/lib/libaspell.so.15.1.4 aaef9000-aaefd000 rw-p 00000000 00:00 0 aaefd000-aaefe000 ---p 00000000 00:00 0 aaefe000-ab7fe000 rw-p 00000000 00:00 0 ab7fe000-ab7ff000 ---p 00000000 00:00 0 ab7ff000-abfff000 rw-p 00000000 00:00 0 abfff000-ac000000 ---p 00000000 00:00 0 ac000000-ac800000 rw-p 00000000 00:00 0 ac800000-ac891000 rw-p 00000000 00:00 0 ac891000-ac900000 ---p 00000000 00:00 0 ac900000-ac902000 r-xp 00000000 08:06 793742 /usr/lib/libxcb-aux.so.0.0.0 ac902000-ac903000 rw-p 00001000 08:06 793742 /usr/lib/libxcb-aux.so.0.0.0 ac903000-ac918000 r-xp 00000000 08:06 794798 /usr/lib/libnssutil3.so ac918000-ac91b000 rw-p 00015000 08:06 794798 /usr/lib/libnssutil3.so ac91b000-ac94b000 r-xp 00000000 08:06 1326530 /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so ac94b000-ac94c000 rw-p 0002f000 08:06 1326530 /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so ac94c000-ac98d000 r-xp 00000000 08:06 794058 /usr/lib/libhunspell-1.2.so.0.0.0 ac98d000-ac991000 rw-p 00041000 08:06 794058 /usr/lib/libhunspell-1.2.so.0.0.0 ac991000-acc8b000 rw-p 00000000 00:00 0 acc8b000-acc8e000 r-xp 00000000 08:06 794460 /usr/lib/libplc4.so acc8e000-acc8f000 rw-p 00002000 08:06 794460 /usr/lib/libplc4.so acc8f000-acc92000 r-xp 00000000 08:06 4616744 /usr/lib/xulrunner-1.9.2/libxpcom.so acc92000-acc93000 rw-p 00002000 08:06 4616744 /usr/lib/xulrunner-1.9.2/libxpcom.so accb1000-accb6000 r-xp 00000000 08:06 3678073 /usr/lib/openoffice/program/libnpsoplugin.so accb6000-accb7000 rw-p 00004000 08:06 3678073 /usr/lib/openoffice/program/libnpsoplugin.so accb7000-accb9000 rw-p 00000000 00:00 0 accb9000-accce000 r-xp 00000000 08:06 2365484 /usr/lib/mozilla/plugins/gecko-mediaplayer.so accce000-acccf000 rw-p 00015000 08:06 2365484 /usr/lib/mozilla/plugins/gecko-mediaplayer.so acccf000-accd8000 r-xp 00000000 08:06 1325976 /usr/lib/enchant/libenchant_hspell.so accd8000-accda000 rw-p 00008000 08:06 1325976 /usr/lib/enchant/libenchant_hspell.so accda000-accfa000 rw-p 00000000 00:00 0 accfa000-accfe000 r-xp 00000000 08:06 85 /lib/libnss_dns-2.12.so accfe000-accff000 r--p 00004000 08:06 85 /lib/libnss_dns-2.12.so accff000-acd00000 rw-p 00005000 08:06 85 /lib/libnss_dns-2.12.so acd00000-acdf9000 rw-p 00000000 00:00 0 acdf9000-ace00000 ---p 00000000 00:00 0 ace00000-ace02000 r-xp 00000000 08:06 794463 /usr/lib/libplds4.so ace02000-ace03000 rw-p 00001000 08:06 794463 /usr/lib/libplds4.so ace03000-ace63000 rw-s 00000000 00:04 210599946 /SYSV00000000 (deleted) ace63000-ace67000 r-xp 00000000 08:06 789374 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so ace67000-ace68000 rw-p 00003000 08:06 789374 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so ace69000-acec9000 rw-s 00000000 00:04 210501635 /SYSV00000000 (deleted) acec9000-acf55000 r--p 00000000 08:06 921898 /usr/share/fonts/TTF/DejaVuSans-Bold.ttf acf55000-acfed000 r--p 00000000 08:06 921885 /usr/share/fonts/TTF/DejaVuSans.ttf acfed000-acfee000 r--s 00000000 08:06 921327 /home/topher/.fontconfig/14a1b5a3746cb4930e0dbdbc836653bf-le32d4.cache-3 acfee000-acfef000 r--s 00000000 08:06 921326 /home/topher/.fontconfig/0eb49658fa6cf8a9de97a34d99a5923c-le32d4.cache-3 acfef000-acff0000 r--s 00000000 08:06 921325 /home/topher/.fontconfig/abdae58b88afa31f7cdcb0a62b1d5bfc-le32d4.cache-3Aborted [topher at sheldon ~]$ java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (ArchLinux-6.b18_1.8-1-i686) OpenJDK Server VM (build 14.0-b16, mixed mode) From adam at yorba.org Tue Jun 22 18:04:05 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 22 Jun 2010 11:04:05 -0700 Subject: [Shotwell] GUI for Shotwell In-Reply-To: <10279633-7DAB-4656-87F4-9AE59FBD4EB2@gmail.com> References: <10279633-7DAB-4656-87F4-9AE59FBD4EB2@gmail.com> Message-ID: <4C20FB15.1060101@yorba.org> On 06/22/2010 09:50 AM, Tor L?vskogen Bollingmo wrote: > Hei fra Norge! > > I'm a norwegian designer wanting to do some work for the FOSS community. I read about Shotwell replacing F-Spot in 'Maverick', took a look at your website and team ? and wondered if you guys would have someone like me desiging and working on the user interface design, and the user experience part of Shotwell? > > Would love to help. Mail me back with something specific to do, or/and I could look at the application as a whole, and give some constructive feedback from a design point of view. > Tor, Hei fra San Francisco! :) Thanks for your interest in helping out with Shotwell's user interface and/or user experience. Of course we'd be interested in your constructive feedback for the application as a whole. We also have various open tickets for general visual improvements, and we'd be happy to receive feedback on these ideas and/or actual graphic designs we could use for these: http://trac.yorba.org/ticket/295 (icons in sidebar) http://trac.yorba.org/ticket/318 (support GNOME color themes) http://trac.yorba.org/ticket/971 (make color sliders more visually intuitive) http://trac.yorba.org/ticket/1148 (improve Publish icon) http://trac.yorba.org/ticket/1578 (UI icons should follow GNOME style, not Human (Ubuntu)) http://trac.yorba.org/ticket/1614 (put images at ends of zoom sliders) http://trac.yorba.org/ticket/2019 (in Preferences dialog, use colored squares rather than "white" and "black") Thanks again! adam From lucas at yorba.org Tue Jun 22 18:15:59 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 22 Jun 2010 11:15:59 -0700 Subject: [Shotwell] crash issue In-Reply-To: References: Message-ID: Hi Topher, Shotwell uses the WebKit framework to create a programmatically-controlled browser environment when it runs the login interactions for Facebook and Flickr. Put more simply, when you get ready to sign in to Facebook or Flickr, Shotwell effectively runs a mini web browser to show you the login pages. Just as full-size web browsers can have plugins (to display Flash videos or Java applets, for example), so can WebKit. Apparently, one of the WebKit plugins installed on your system is the IcedTea runtime plugin. You can see that Shotwell failed attempting to load this plugin by the presence of this line in the stack trace you provided: > /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so(NP_Initialize+0x761)[0xac925ad1] IcedTea is a Red Hat project that aims to produce a completely free Java VM & JDK. Clearly, it has problems with WebKit on your system. I'd recommend trying the following steps to fix the problem: 1. if you don't need Java runtime support, remove IcedTea completely. 2. Upgrade IcedTea to the latest version; this may mean building and installing it from source. 3. Replace IcedTea with the genuine Sun JDK & VM Thanks for your interest in Shotwell! Take care, Lucas From topher at t1kdev.com Tue Jun 22 18:44:00 2010 From: topher at t1kdev.com (Topher) Date: Tue, 22 Jun 2010 14:44:00 -0400 (EDT) Subject: [Shotwell] crash issue In-Reply-To: References: Message-ID: On Tue, 22 Jun 2010, Lucas Beeler wrote: > Hi Topher, > > ? Shotwell uses the WebKit?framework to create a?programmatically-controlled > browser environment when it runs the login interactions for Facebook and > Flickr. Put more simply, when you get ready to sign in to Facebook or > Flickr, Shotwell effectively runs a mini web browser to show you the login > pages. Just as full-size web browsers can have plugins (to display Flash > videos or Java applets, for example), so can WebKit. Apparently, one of the > WebKit plugins installed on your system is the IcedTea runtime plugin. You > can see that Shotwell failed attempting to load this plugin by the presence > of this line in the stack trace you provided: > >/usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so(NP_Initialize+0x7 > 61)[0xac925ad1] > > IcedTea is a Red Hat project that aims to produce a completely free Java VM > & JDK. Clearly, it has problems with WebKit on your system. I'd recommend > trying the following steps to fix the problem: > > 1. if you don't need Java runtime support, remove IcedTea completely. > 2. Upgrade IcedTea to the latest version; this may mean building and > installing it from source. > 3. Replace IcedTea with the genuine Sun JDK & VM > Thanks for your interest in Shotwell! Alrighty, I removed icedtea and now when I get to the same point as before it segfaults. :( No other reporting, just [topher at sheldon ~]$ shotwell Segmentation fault Are there any debug flags I could pass it on startup? Thanks for the quick response before, I really appreciate it. :) Topher From lucas at yorba.org Tue Jun 22 19:05:25 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 22 Jun 2010 12:05:25 -0700 Subject: [Shotwell] crash issue In-Reply-To: References: Message-ID: Hi Topher, Interestingly, we saw a segfault at the same point during our development of the Flickr publishing feature. It was fixed by installing a newer version of WebKit. Curiously, what version of WebKit are you running? Note that you can figure this out by entering the command: pkg-config --modversion webkit-1.0 in a terminal window. Thanks, Lucas From topher at t1kdev.com Tue Jun 22 19:10:36 2010 From: topher at t1kdev.com (Topher) Date: Tue, 22 Jun 2010 15:10:36 -0400 (EDT) Subject: [Shotwell] crash issue In-Reply-To: References: Message-ID: On Tue, 22 Jun 2010, Lucas Beeler wrote: > Hi Topher, > ?? Interestingly, we saw a segfault at the same point during our development > of the Flickr publishing feature. It was fixed by installing a newer version > of WebKit. Curiously, what version of WebKit are you running? Note that you > can figure this out by entering the command: > > pkg-config --modversion webkit-1.0 > > > in a terminal window. [topher at sheldon ~]$ pkg-config --modversion webkit-1.0 1.2.1 From lucas at yorba.org Tue Jun 22 19:30:29 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 22 Jun 2010 12:30:29 -0700 Subject: [Shotwell] crash issue In-Reply-To: References: Message-ID: Hi Topher, I have created a ticket for the issue you reported here: http://trac.yorba.org/ticket/2183 . We'll look into it, but right now it is a medium-priority matter because this appears to be an Arch Linux-specific problem. One thing you may wish to do is to attempt to build and install WebKit from source, since it seems that's where the problem is. Take care, Lucas From pdo.smith at gmail.com Wed Jun 23 06:17:03 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Wed, 23 Jun 2010 08:17:03 +0200 Subject: [Shotwell] Tags enhancement In-Reply-To: <4C20EF1C.5050503@yorba.org> References: <1277120270.1570.30.camel@nuuk> <4C1F83DD.9000704@yorba.org> <4C20E231.2090208@yorba.org> <4C20EF1C.5050503@yorba.org> Message-ID: On Tue, Jun 22, 2010 at 7:13 PM, Adam Dingle wrote: > On 06/22/2010 09:49 AM, Svetoslav Trochev wrote: >>> We're planning to implement directory monitoring soon >>> (http://trac.yorba.org/ticket/374). ?Once we have that, Shotwell should >>> automatically notice when photos have gone away so I hope there >>> shouldn't be a need for a manual repair step. >>> >>> >>> adam >> Adam, are you planning to have this feature enabled/disabled per >> directory? This is the main reason why I started using Shotwell. >> Currently I can import (without local copy) my archived photos located >> on my NAS and I have them in the DB for search, but I am not connected >> to my NAS at all time. I would hate to see archived photos deleted >> from my DB at this moment. I read the ticket, but there is nothing >> about how it is going to work. Where I can read more about it? >> >> Thank you, >> Svetoslav >> > > Svetoslav, > > we haven't yet designed this feature in detail so there's nothing more > to read at this moment. ?But we're going to start work on 0.7 soon, and > directory monitoring is high on our list so we'll be thinking much more > about this soon. ?The use case you described is important. ?I think > we'll either need to (a) detect when a filesystem is offline, in which > case we *won't* delete its files from the database even though they are > inaccessible, and/or (b) allow the user to enable/disable monitoring per > directory (like in Picasa, for example). ?Still undecided. > Adam, this is an important issue. Twice my photos were deleted from Picasa for this very reason. I would suggest (a) above and (c) a switch to disable monitoring plus (d) a refresh button to manually scan for folder changes. Peter From allison at yorba.org Wed Jun 23 16:27:20 2010 From: allison at yorba.org (Allison Barlow) Date: Wed, 23 Jun 2010 09:27:20 -0700 Subject: [Shotwell] Shotwell 0.6 Documentation Message-ID: Hello folks! We've just finished the documentation for Shotwell 0.6! Take a look if you like and let us know if you have any feedback: http://trac.yorba.org/wiki/UsingShotwell0.6 ajb From svetoslav.trochev at gmail.com Wed Jun 23 17:44:11 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Wed, 23 Jun 2010 10:44:11 -0700 Subject: [Shotwell] Shotwell 0.6 Documentation In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 9:27 AM, Allison Barlow wrote: > Hello folks! > > We've just finished the documentation for Shotwell 0.6! > > Take a look if you like and let us know if you have any feedback: > http://trac.yorba.org/wiki/UsingShotwell0.6 > > ajb > _______________________________________________ Hi Allison, In "Tags" section I would recommend to move the "Image 6" between 2nd and 3rd paragraph. it has focus on "Tags ? Remove Tag "[name]" from Photos..." not on Tags ? Delete Tag "[name]". As result it could be a bit confusing for somebody. Svetoslav From svetoslav.trochev at gmail.com Wed Jun 23 17:58:53 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Wed, 23 Jun 2010 10:58:53 -0700 Subject: [Shotwell] Shotwell 0.6 Documentation In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 9:27 AM, Allison Barlow wrote: > Hello folks! > > We've just finished the documentation for Shotwell 0.6! > > Take a look if you like and let us know if you have any feedback: > http://trac.yorba.org/wiki/UsingShotwell0.6 > > ajb > _______________________________________________ Also we are missing Image 12 in "Publishing" section; From svetoslav.trochev at gmail.com Wed Jun 23 18:02:25 2010 From: svetoslav.trochev at gmail.com (Svetoslav Trochev) Date: Wed, 23 Jun 2010 11:02:25 -0700 Subject: [Shotwell] Shotwell 0.6 Documentation In-Reply-To: References: Message-ID: On Wed, Jun 23, 2010 at 10:58 AM, Svetoslav Trochev wrote: > On Wed, Jun 23, 2010 at 9:27 AM, Allison Barlow wrote: >> Hello folks! >> >> We've just finished the documentation for Shotwell 0.6! >> >> Take a look if you like and let us know if you have any feedback: >> http://trac.yorba.org/wiki/UsingShotwell0.6 >> >> ajb >> _______________________________________________ > > Also we are missing Image 12 in "Publishing" section; > Disregard this one. Now I can see the Image. Sorry. From baldakkl at gmail.com Thu Jun 24 09:09:59 2010 From: baldakkl at gmail.com (Lorenzo Baldacchini) Date: Thu, 24 Jun 2010 11:09:59 +0200 Subject: [Shotwell] Bibble5 in raw editor menu Message-ID: > On 06/16/2010 03:18 PM, Lorenzo Baldacchini wrote: >> Hi guys, >> I have encountered a small problem with the last svn version of shotwell. >> In the preferences menu, where I have to choose the external raw >> editor, it doesn't make me choose Bibble5, which is, obviously, >> installed on my system. >> In the menu there are the other raw editors (ufraw, darktable and >> rawstudio) but not Bibble5. >> I tried to reinstall both bibble than shotwell, but the situation >> doesn't change. >> I would suggest to add a voice >> "use a personal command" to choose whatever one wants (like for >> example in preferred application for gnome). >> Thank you very much for the great work that you are doing. >> Lorenzo >> > > Lorenzo, > > thanks for your suggestion. Today, Shotwell allows you to choose any > external editor which has registered itself as handling the MIME types > that represent images. In other words, Shotwell lets you choose any > editor which shows up in the "Open With" context menu when you right > click the image file in Nautilus. We agree that it would be nice to be > able to choose other editors as well - we have a ticket for this at > http://trac.yorba.org/ticket/2014 . This won't make 0.6, but hopefully > we'll get to this before too long. > > adam Hi guys, also with the last svn version bibble5 doesn't appear in the menu for choosing the raw editor. I found a workaround to use this program: I renamed the file darktable in /usr/bin (which is the editor chosen in the menu of shotwell) and I created a file sh which launch bibble5, called darktable. Now it works, but I still don't understand why bibble5 doesn't appear in the menu. Anyway thanks again for the great job that you are doing with this software Lorenzo From adam at yorba.org Thu Jun 24 16:05:51 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 24 Jun 2010 09:05:51 -0700 Subject: [Shotwell] Bibble5 in raw editor menu In-Reply-To: References: Message-ID: <4C23825F.9010208@yorba.org> On 06/24/2010 02:09 AM, Lorenzo Baldacchini wrote: >> >> thanks for your suggestion. Today, Shotwell allows you to choose any >> external editor which has registered itself as handling the MIME types >> that represent images. In other words, Shotwell lets you choose any >> editor which shows up in the "Open With" context menu when you right >> click the image file in Nautilus. We agree that it would be nice to be >> able to choose other editors as well - we have a ticket for this at >> http://trac.yorba.org/ticket/2014 . This won't make 0.6, but hopefully >> we'll get to this before too long. >> >> adam >> > Hi guys, also with the last svn version bibble5 doesn't appear in the menu > for choosing the raw editor. > I found a workaround to use this program: I renamed the file darktable in > /usr/bin (which is the editor chosen in the menu of shotwell) and I created > a file sh which launch bibble5, called darktable. > Now it works, but I still don't understand why bibble5 doesn't appear in the > menu. > Lorenzo, OK - here's a more detailed explanation. In Nautilus, find any one of your raw photos (for example, a .cr2 file if you're using a recent Canon camera) and right click it. You'll see a menu that contains an Open With submenu. Now look in that submenu. You'll see various programs that can open RAW files - for example, GIMP, gThumb and Image Viewer (= Eye of GNOME) will all be there if you have them installed. You will probably not see Bibble 5 in the list. When each image program is installed, it is responsible for registering itself as being able to handle RAW photos. GIMP, gThumb and Eye of GNOME are all performing that registration correctly, and so they show up both in Nautilus's Open With submenu and also in Shotwell's list of available RAW editors. Bibble 5 is failing to perform this registration. You should contact the Bibble 5 authors and tell them that Bibble should register itself in this way. (You might want to forward them this email.) As I mentioned before, we do have an open ticket (http://trac.yorba.org/ticket/2014) to allow Shotwell users to choose any program at all for external editing, not only those that are registered as handling image files. But that has not been implemented for 0.6, which means you'll need to use your workaround to use Bibble 5 with Shotwell 0.6. If we do implement that ticket for Shotwell 0.7 then you'll be able to choose Bibble 5 directly in that version of Shotwell. I hope this explanation helps. Let me know if you have more questions. Thanks! adam From marcelcoding at googlemail.com Thu Jun 24 16:38:52 2010 From: marcelcoding at googlemail.com (Marcel Stimberg) Date: Thu, 24 Jun 2010 18:38:52 +0200 Subject: [Shotwell] Bibble5 in raw editor menu In-Reply-To: <4C23825F.9010208@yorba.org> References: <4C23825F.9010208@yorba.org> Message-ID: Hi Adam, sorry to step in but I think the issue might be a bit more subtle: Bibble5 *is* registering itself for raw files, in fact it shows up as the default application after install. The bibble5.desktop file contains the line MimeType=image/x-canon-crw;image/x-canon-cr2;image/x-sony-arw;image/x-nikon-nef;image/x-olympus-orf;image/x-pentax-pef;image/x-adobe-dng;image/tiff;image/x-raw;application/x-bibble5; But I'm a bit confused, is this MimeType in the desktop file the only information about supported mime types? I'm asking because the corresponding line in ufraw.desktop only mentions: MimeType=application/x-ufraw;image/x-dcraw i.e. not even contains image/x-canon-cr2 but shows up in the menu for my canon .CR2 raw files... Marcel From adam at yorba.org Thu Jun 24 17:02:35 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 24 Jun 2010 10:02:35 -0700 Subject: [Shotwell] Bibble5 in raw editor menu In-Reply-To: References: <4C23825F.9010208@yorba.org> Message-ID: <4C238FAB.6020706@yorba.org> On 06/24/2010 09:38 AM, Marcel Stimberg wrote: > Hi Adam, > sorry to step in but I think the issue might be a bit more subtle: > Bibble5 *is* registering itself for raw files, in fact it shows up as > the default application after install. The bibble5.desktop file > contains the line > MimeType=image/x-canon-crw;image/x-canon-cr2;image/x-sony-arw;image/x-nikon-nef;image/x-olympus-orf;image/x-pentax-pef;image/x-adobe-dng;image/tiff;image/x-raw;application/x-bibble5; > Oops - you're absolutely right. I just installed Bibble5 and it does indeed show up as the default application after install, but is not in Shotwell's list of available RAW editors. Similarly, GIMP should show up in Shotwell's RAW editor list (at least if I've installed the UFRaw GIMP plugin) but does not. So I believe this is a Shotwell bug. I've filed a ticket at http://trac.yorba.org/ticket/2194 . There may still be a chance we can solve this for the impending 0.6 release. > But I'm a bit confused, is this MimeType in the desktop file the only > information about supported mime types? I'm asking because the > corresponding line in ufraw.desktop only mentions: > MimeType=application/x-ufraw;image/x-dcraw > > i.e. not even contains image/x-canon-cr2 but shows up in the menu for > my canon .CR2 raw files... > Good question. Perhaps image/x-dcraw implies image/x-canon-cr2 somehow, but I don't know more about this. Perhaps one of the Shotwell coders can say more about this. adam From lutimdale at yahoo.com Thu Jun 24 19:00:02 2010 From: lutimdale at yahoo.com (Lu Timdale) Date: Thu, 24 Jun 2010 12:00:02 -0700 (PDT) Subject: [Shotwell] Import Suggestions Message-ID: <159712.55396.qm@web33702.mail.mud.yahoo.com> > - Import should be file system based (organize by folder) and this should be configurable. > Pictures/2010/2010-01-01 New Year's Eve/ > or > Pictures/2010/01/New Year's Eve > or whatever format a user wants. > I cannot stress how important this is. This is required for archival purposes. You should not need Shotwell 10 years from now to be able to view your organized photos. I should also be able to import my pictures, organize them, and be able to browse them intelligently in the file manager. > Completely agreed. This is http://trac.yorba.org/ticket/1597 . I hope we can make this happen before too long. .... Here are my usage scenarios and thoughts for import: A. BASIC IMPORT + FILE SYSTEM RENAME 1) Import from a camera to a customizable date based structure such as /Pictures/2010/2010-01-01/2010-01-01 001.jpg My preference is above since it keeps the file names short and makes them distinct. When I pick and choose photos, there is no overlap with DSC0001.jpg appearing 5 times. 2) File system: the next step is to rename only the folder at the file system level to something like /Pictures/2010/2010-01-01 New Year's/ 3) the files are not renamed, they would stay as 2010-01-01 001.jpg 4) reopen Shotwell, photos are reindexed in the background based on new structure (watched folders) Thoughts: this is a crude approach, but must be supported as you cannot prevent users from changing filenames or directories from the filesystem. Shotwell does the heavy lifting of the initial renaming of files and organizing in the file structure. The good thing about this approach is that when using multiple cameras, it still works, by doing all the imports from all cameras first and then renaming the folders afterwards. Pictures from 2 cameras for same event are in same folder. B. RENAME IN APP DURINGIMPORT This is how Windows 7 Live photo gallery handles it. It is very interesting. 1) Import is started 2) Pictures are sorted and grouped based on date (they actually do a time interval in hours between shots) on screen in import window. Nothing has been imported yet. 3) Each "event" is given a name. They have an issue with how they implement this in that only thumbnails are shown in one very small size, which makes figuring out naming sometimes difficult. 4) files are imported based on date and event name to a structure such as /Pictures/2010/2010-01-01 New Years/2010-01-01 New Years 001.jpg Thoughts: This works really nicely... your picture files not only have unique names, but descriptive text which can be searchable on filesystem. If you copy 10 files to share with someone, there's no guesswork as to what's in those files and they are sorted by date by virtue of natural name sorting. WOW! The import doesn't work when you have 2 cameras though. You are forced to name events multiple times, often with different names. Hmmm. C. RENAME FOLDER IN APP AFTER IMPORT The import would be done first same as in A for both Cameras, but the one folder that all the pictures (from one event) went into is renamed within the app . So we go from /Pictures/2010/2010-01-01/2010-01-01 001.jpg (from camera 1) /Pictures/2010/2010-01-01/2010-01-01 002.jpg (from camera 2) to /Pictures/2010/2010-01-01 New Years/2010-01-01 001.jpg (from camera 1) /Pictures/2010/2010-01-01 New Years/2010-01-01 002.jpg (from camera 2) Ideally, the this would affect the filenames as well. So it would be: /Pictures/2010/2010-01-01 New Years/2010-01-01 New Years 001.jpg (from camera 1) /Pictures/2010/2010-01-01 New Years/2010-01-01 New Years 002.jpg (from camera 2) Simple, but effective approach. D. MERGE FOLDERS IN APP AFTER IMPORT To fix B's failings, it would be ideal to merge multiple folders within the app and the folder and filenames would be changed to reflect the new event name. 1) Import is done based on A or B's approach with files being either named /Pictures/2010/2010-01-01/ /Pictures/2010/2010-01-01 New Years/ 2) folders are merged. Select 2 folders, merge files. The first folder's name is used (a prompt possibly asks for new folder name) 3) files are merged together and naming is updated to follow the folder convention appending 001.jpg, 002.jpg, etc. So, there are several things to consider on import - custom folder structure - custom renaming of files to be unique across library (however original filenames should be supported too eg. DSC0001.jpg) - renaming of files to be descriptive and match folder naming - renaming of folders/files from within app - app being aware of renaming of folders/files in filesystem (as in watched folders) - merging folders from same events, but different cameras that ended up in different folders Hopefully this gives some food for thought. This problem is difficult to implement well when giving consideration to all above points. Thank you. Lu Timdale lutimdale at yahoo.com From adam at yorba.org Thu Jun 24 21:51:36 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 24 Jun 2010 14:51:36 -0700 Subject: [Shotwell] Bibble5 in raw editor menu In-Reply-To: <4C238FAB.6020706@yorba.org> References: <4C23825F.9010208@yorba.org> <4C238FAB.6020706@yorba.org> Message-ID: <4C23D368.6090400@yorba.org> On 06/24/2010 10:02 AM, Adam Dingle wrote: > On 06/24/2010 09:38 AM, Marcel Stimberg wrote: >> Hi Adam, >> sorry to step in but I think the issue might be a bit more subtle: >> Bibble5 *is* registering itself for raw files, in fact it shows up as >> the default application after install. The bibble5.desktop file >> contains the line >> MimeType=image/x-canon-crw;image/x-canon-cr2;image/x-sony-arw;image/x-nikon-nef;image/x-olympus-orf;image/x-pentax-pef;image/x-adobe-dng;image/tiff;image/x-raw;application/x-bibble5; >> > > Oops - you're absolutely right. I just installed Bibble5 and it does > indeed show up as the default application after install, but is not in > Shotwell's list of available RAW editors. Similarly, GIMP should show > up in Shotwell's RAW editor list (at least if I've installed the UFRaw > GIMP plugin) but does not. So I believe this is a Shotwell bug. I've > filed a ticket at http://trac.yorba.org/ticket/2194 . There may still > be a chance we can solve this for the impending 0.6 release. An update: I'm happy to report we've now fixed the bug in trunk , so Bibble5 *will* show up the list of RAW editors in the upcoming 0.6 release. Thanks very much to Lorenzo and Marcel for pointing this out. adam From pdo.smith at gmail.com Fri Jun 25 08:59:52 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 10:59:52 +0200 Subject: [Shotwell] Import Suggestions In-Reply-To: <159712.55396.qm@web33702.mail.mud.yahoo.com> References: <159712.55396.qm@web33702.mail.mud.yahoo.com> Message-ID: On Thu, Jun 24, 2010 at 9:00 PM, Lu Timdale wrote: >> - Import should be file system based (organize by folder) and this > should be configurable. >> Pictures/2010/2010-01-01 New Year's Eve/ >> or >> Pictures/2010/01/New Year's Eve >> or whatever format a user wants. >> I cannot stress how important this is. ?This is > required for archival purposes. ?You should not need Shotwell 10 years > from now to be able to view your organized photos. ?I should also be > able to import my pictures, organize them, and be able to browse them > intelligently in the file manager. >> > > Completely > agreed. ?This is http://trac.yorba.org/ticket/1597 . ?I hope > we > can make this happen before too long. > > ?So, there are several things to consider on import > - custom folder structure > - custom renaming of files to be unique across library (however original filenames should be supported too eg. DSC0001.jpg) > - renaming of files to be descriptive and match folder naming > - renaming of folders/files from within app > - app being aware of renaming of folders/files in filesystem (as in watched folders) > - merging folders from same events, but different cameras that ended up in different folders > Yes, the folder structure is important and configurable would be ideal. Presently the import folder structure is year --> month ---> day ---> file_name I describe the folder structure I use below so that you can appreciate the differing needs of photographers. year-month --> year-month-001.jpg and year-month --> DNG ---> year-month-001.DNG i.e. I have one folder for each month containing the jpegs and a sub-folder containing the RAW files. A sub-folder for each day seems excessively complex but might be useful for very busy photographers. The photos are renamed year-month-001.jpg and year-month-001.DNG so that when I view the photo I can always find the file location by inspecting the file name. Note that I keep the RAW files in a subfolder separate from the converted jpegs. Peter From pdo.smith at gmail.com Fri Jun 25 09:22:14 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 11:22:14 +0200 Subject: [Shotwell] Calling Ufraw Message-ID: I notice that when I import DNG photos from my camera that Shotwell invisibly converts the photo from RAW, presumably by calling Ufraw in batch mode. I seem to remember an earlier posting requesting this behaviour. The problem is that, for me at least, it seems better to display Ufraw first. This allows me to choose various settings, such as black point, exposure level, wavelet denoise, saturation, conversion curve etc, etc, that can then be used for subsequent photos in that batch. You might want to consider building a similar idea into Shotwell Peter From pdo.smith at gmail.com Fri Jun 25 09:58:14 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 11:58:14 +0200 Subject: [Shotwell] Shotwell command line Message-ID: I note from an earlier posting that Shotwell can invoke different photo libraries by using the following command shotwell -d ~/.library_name This seems to me to be a very powerful option and I wonder if you could not build this into the Shotwell gui, under, for example, the File menu entry? The facility to have different libraries of photos would be very valuable to me. I also note that this is not described in the new documentation. I think it should be included. There does seem to be a bug though. If I run shotwell -d library_name I get this error ** ERROR **: AppDirs.vala:39: Operation not supported aborting... Aborted It seems I must enter shotwell -d ~/library_name which seems unnecessarily restrictive Peter From pdo.smith at gmail.com Fri Jun 25 10:13:38 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 12:13:38 +0200 Subject: [Shotwell] Launching external editor Message-ID: After having imported DNG files from my camera I tried to launch an external editor "Open with external editor" and got the following error Unable to launch editor: Size of Exif JPEG segment is larger than 65535 bytes. However if I open with RAW editor it launches Ufraw and everything works properly. Gimp is set as my image editor and it is registered in my copy of Ubuntu (10.04) I am using today's svn trunk Peter From pdo.smith at gmail.com Fri Jun 25 10:17:10 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 12:17:10 +0200 Subject: [Shotwell] Launching external editor In-Reply-To: References: Message-ID: I should have added that if, with a normal jpeg file, I choose the option "Open with external editor" it works properly and gimp loads the file. On Fri, Jun 25, 2010 at 12:13 PM, Peter DO Smith wrote: > After having imported DNG files from my camera I tried to launch an > external editor "Open with external editor" and got the following > error > > Unable to launch editor: Size of Exif JPEG segment is larger than 65535 bytes. > > However if I open with RAW editor it launches Ufraw and everything > works properly. Gimp is set as my image editor and it is registered in > my copy of Ubuntu (10.04) > I am using today's svn trunk > > Peter > From pdo.smith at gmail.com Fri Jun 25 10:27:53 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 12:27:53 +0200 Subject: [Shotwell] Import file types Message-ID: I note that Shotwell cannot import tiff files? This would be handy to have. Also the documentation does not say what import file types are allowed or not allowed. Peter From pdo.smith at gmail.com Fri Jun 25 10:38:37 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 12:38:37 +0200 Subject: [Shotwell] Dragging photos into event view Message-ID: If I drag an unregistered photo (from nautilus) into an event view (after having clicked on a given event) the photo imports but I am thrown back into the general photo view and the photo has disappeared somewhere into the photo library. This is somewhat counter-intuitive as I would expect to remain in that event view and to see the photo appear in that event. After all I can drag photos from one event into another event (very nice feature by the way) Peter From pdo.smith at gmail.com Fri Jun 25 10:49:45 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Fri, 25 Jun 2010 12:49:45 +0200 Subject: [Shotwell] F11 full screen view Message-ID: The rotate shortcut keys [ ] do not work in the F11 full screen view (they work in the other views) From brunogirin at gmail.com Fri Jun 25 11:43:23 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 25 Jun 2010 12:43:23 +0100 Subject: [Shotwell] Import Suggestions In-Reply-To: References: <159712.55396.qm@web33702.mail.mud.yahoo.com> Message-ID: <1277466203.21606.5.camel@Nokia-N900-42-11> ----- Original message ----- > On Thu, Jun 24, 2010 at 9:00 PM, Lu Timdale wrote: > > > - Import should be file system based (organize by folder) and this > > should be configurable. > > > Pictures/2010/2010-01-01 New Year's Eve/ > > > or > > > Pictures/2010/01/New Year's Eve > > > or whatever format a user wants. > > > I cannot stress how important this is. ?This is > > required for archival purposes. ?You should not need Shotwell 10 years > > from now to be able to view your organized photos. ?I should also be > > able to import my pictures, organize them, and be able to browse them > > intelligently in the file manager. > > > > > > > Completely > > agreed. ?This is http://trac.yorba.org/ticket/1597 . ?I hope > > we > > can make this happen before too long. > > > > > ?So, there are several things to consider on import > > - custom folder structure > > - custom renaming of files to be unique across library (however original > > filenames should be supported too eg. DSC0001.jpg) - renaming of files to be > > descriptive and match folder naming - renaming of folders/files from within app > > - app being aware of renaming of folders/files in filesystem (as in watched > > folders) - merging folders from same events, but different cameras that ended > > up in different folders > > > > Yes, the folder structure is important and configurable would be ideal. > Presently the import folder structure? is > > year --> month ---> day ---> file_name > > I describe the folder structure I use below so that you can appreciate > the differing needs of photographers. > > year-month --> year-month-001.jpg > and > year-month --> DNG ---> year-month-001.DNG > > i.e. I have one folder for each month containing the jpegs and a > sub-folder containing the RAW files. A sub-folder for each day seems > excessively complex but might be useful for very busy photographers. Well it depends. As you say, different people have different needs. Even though I am an amateur and take nowhere as many pictures as a pro, I can have periods when I take several hundred pictures a day, especially when travelling. For instance, a 2 month sailing and rail trip I did a few years ago resulted in thousands of pictures. So for me the default Shotwell file layout works better. I think we all agree that making it configurable is the key. Bruno From brunogirin at gmail.com Fri Jun 25 11:48:40 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 25 Jun 2010 12:48:40 +0100 Subject: [Shotwell] Import file types In-Reply-To: References: Message-ID: <1277466520.21606.11.camel@Nokia-N900-42-11> ----- Original message ----- > I note that Shotwell cannot import tiff files? This would be handy to have. That's ticket #601: http://trac.yorba.org/ticket/601 > Also the documentation does not say what import file types are allowed > or not allowed. Agreed, that would be good to add. Bruno From adam at yorba.org Fri Jun 25 15:44:27 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 08:44:27 -0700 Subject: [Shotwell] Calling Ufraw In-Reply-To: References: Message-ID: <4C24CEDB.8000908@yorba.org> Peter, On 06/25/2010 02:22 AM, Peter DO Smith wrote: > I notice that when I import DNG photos from my camera that Shotwell > invisibly converts the photo from RAW, presumably by calling Ufraw in > batch mode. > Shotwell does not call UFRaw or require it to be installed. Shotwell converts photos from RAW using the libraw library (see http://www.libraw.org/), which is a wrapper around the same dcraw engine used by UFRaw. > I seem to remember an earlier posting requesting this behaviour. > The problem is that, for me at least, it seems better to display Ufraw > first. This allows me to choose various settings, such as black point, > exposure level, wavelet denoise, saturation, conversion curve etc, > etc, that can then be used for subsequent photos in that batch. > You might want to consider building a similar idea into Shotwell > Shotwell's RAW support is limited in the upcoming 0.6 release. Today, Shotwell can convert each RAW file to a JPEG for display, and can also open RAW photos in an external editor. At some point we'd like to build RAW adjustment capabilities directly into Shotwell; then you'll be able to choose the kinds of settings you mention in Shotwell without having to launch an external program. At that point I also hope we'll make it possible to apply a single setting to a group of photos. This sort of RAW editing is probably a few releases away, however. adam From adam at yorba.org Fri Jun 25 16:00:06 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 09:00:06 -0700 Subject: [Shotwell] Shotwell command line In-Reply-To: References: Message-ID: <4C24D286.3080807@yorba.org> On 06/25/2010 02:58 AM, Peter DO Smith wrote: > I note from an earlier posting that Shotwell can invoke different > photo libraries by using the following command > > shotwell -d ~/.library_name > > This seems to me to be a very powerful option and I wonder if you > could not build this into the Shotwell gui, under, for example, the > File menu entry? > That's a reasonable suggestion. I've added a ticket at http://trac.yorba.org/ticket/2211 . > The facility to have different libraries of photos would be very valuable to me. > > I also note that this is not described in the new documentation. I > think it should be included. > Good point. I've just added it to the 0.6 documentation. > There does seem to be a bug though. > If I run > shotwell -d library_name > I get this error > ** ERROR **: AppDirs.vala:39: Operation not supported > aborting... > Aborted > > It seems I must enter > shotwell -d ~/library_name > > which seems unnecessarily restrictive > > True. I've filed a bug at http://trac.yorba.org/ticket/2210 . adam From adam at yorba.org Fri Jun 25 16:05:58 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 09:05:58 -0700 Subject: [Shotwell] Launching external editor In-Reply-To: References: Message-ID: <4C24D3E6.4040308@yorba.org> On 06/25/2010 03:13 AM, Peter DO Smith wrote: > After having imported DNG files from my camera I tried to launch an > external editor "Open with external editor" and got the following > error > > Unable to launch editor: Size of Exif JPEG segment is larger than 65535 bytes. > > However if I open with RAW editor it launches Ufraw and everything > works properly. Gimp is set as my image editor and it is registered in > my copy of Ubuntu (10.04) > I am using today's svn trunk > Peter, thanks for the bug report. We'd like to see a DNG file that is causing this problem. You can't send a DNG to this mailing list, but can you upload one of your DNG files to a file sharing service (search Google for [file hosting] to see a list of various free services) and post the URL here? Thanks - adam From adam at yorba.org Fri Jun 25 16:13:24 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 09:13:24 -0700 Subject: [Shotwell] Import file types In-Reply-To: References: Message-ID: <4C24D5A4.90107@yorba.org> Peter, On 06/25/2010 03:27 AM, Peter DO Smith wrote: > I note that Shotwell cannot import tiff files? This would be handy to have. > Agreed. We have a ticket for this at http://trac.yorba.org/ticket/601 . > Also the documentation does not say what import file types are allowed > or not allowed. > Actually the 0.6 documentation at http://trac.yorba.org/wiki/UsingShotwell0.6 already says this: Currently, Shotwell can import JPEG, PNG, and RAW photo files. Now I've just added this sentence to make things clearer: Shotwell does not yet support other graphics format such as BMP, GIF and TIFF. adam From adam at yorba.org Fri Jun 25 16:19:41 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 09:19:41 -0700 Subject: [Shotwell] F11 full screen view In-Reply-To: References: Message-ID: <4C24D71D.6000704@yorba.org> On 06/25/2010 03:49 AM, Peter DO Smith wrote: > The rotate shortcut keys [ ] do not work in the F11 full screen view > (they work in the other views) > True. We have a ticket for this at http://trac.yorba.org/ticket/324 . I hope we can address this for 0.7. adam From adam at yorba.org Fri Jun 25 16:48:06 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 09:48:06 -0700 Subject: [Shotwell] Dragging photos into event view In-Reply-To: References: Message-ID: <4C24DDC6.40607@yorba.org> On 06/25/2010 03:38 AM, Peter DO Smith wrote: > If I drag an unregistered photo (from nautilus) into an event view > (after having clicked on a given event) the photo imports but I am > thrown back into the general photo view and the photo has disappeared > somewhere into the photo library. > > This is somewhat counter-intuitive as I would expect to remain in that > event view and to see the photo appear in that event. After all I can > drag photos from one event into another event (very nice feature by > the way) > Peter, thanks for the suggestion that Shotwell could allow dragging photos from Nautilus into events directly. I've created a ticket at http://trac.yorba.org/ticket/2212 . adam From adam at yorba.org Fri Jun 25 18:28:33 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 11:28:33 -0700 Subject: [Shotwell] Final call for testing before 0.6 Message-ID: <4C24F551.2050609@yorba.org> Shotwell friends and fans, We've made a number of changes (some small, some not so small) to the Shotwell trunk since our last call for testing early last week. We're currently fixing the last few known issues and are planning to release Shotwell 0.6 next week. The release will be very similar to the current trunk code. For all of you who are interested in Shotwell 0.6, now would be a great time to test the trunk more to make sure we haven't missed anything important. The following features are new in Shotwell 0.6 and so it would be especially useful to try these out: * Basic RAW support * Image zooming * PNG support * Importing and exporting captions and tags via EXIF, IPTC, and XMP * Edit with external editor * Trash folder * User-specified library directory * Preferences dialog Full documentation for the new release is available at http://trac.yorba.org/wiki/UsingShotwell0.6 . If you're interested, follow the directions here for getting the source and building it: http://www.yorba.org/shotwell/install/#source If you find bugs or issues -- anything that seems odd -- please feel free to report them here on the mailing list or via our Trac ticketing system at: http://trac.yorba.org/ Thanks, and looking forward to the 0.6 release! adam From bengt at thuree.com Fri Jun 25 18:47:13 2010 From: bengt at thuree.com (Bengt Thuree) Date: Fri, 25 Jun 2010 20:47:13 +0200 Subject: [Shotwell] Final call for testing before 0.6 In-Reply-To: <4C24F551.2050609@yorba.org> References: <4C24F551.2050609@yorba.org> Message-ID: <1277491633.26583.6.camel@lappis> Hi First, much appreciating the fast development and high quality code you guys are producing. Just wondering when Shotwell will handle Ratings (Import, Filter, Assign, Export), as well as Location tags. In essence all the tags that F-Spot handles today? Is this planned for 0.7 or? Would probably be a good idea to get import existing tags from an F-Spot database working earlier rather than later, or? /Bengt On Fri, 2010-06-25 at 11:28 -0700, Adam Dingle wrote: > Shotwell friends and fans, > > We've made a number of changes (some small, some not so small) to the > Shotwell trunk since our last call for testing early last week. We're > currently fixing the last few known issues and are planning to release > Shotwell 0.6 next week. The release will be very similar to the current > trunk code. > > For all of you who are interested in Shotwell 0.6, now would be a great > time to test the trunk more to make sure we haven't missed anything > important. The following features are new in Shotwell 0.6 and so it > would be especially useful to try these out: > > * Basic RAW support > * Image zooming > * PNG support > * Importing and exporting captions and tags via EXIF, IPTC, and XMP > * Edit with external editor > * Trash folder > * User-specified library directory > * Preferences dialog > > Full documentation for the new release is available at > http://trac.yorba.org/wiki/UsingShotwell0.6 . > > If you're interested, follow the directions here for getting the source > and building it: > > http://www.yorba.org/shotwell/install/#source > > If you find bugs or issues -- anything that seems odd -- please feel > free to report them here on the mailing list or via our Trac ticketing > system at: > > http://trac.yorba.org/ > > Thanks, and looking forward to the 0.6 release! > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- With Regards Bengt Thuree bengt at thuree.com From brunogirin at gmail.com Fri Jun 25 20:26:08 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 25 Jun 2010 21:26:08 +0100 Subject: [Shotwell] Final call for testing before 0.6 In-Reply-To: <1277491633.26583.6.camel@lappis> References: <4C24F551.2050609@yorba.org> <1277491633.26583.6.camel@lappis> Message-ID: <1277497568.5455.7.camel@nuuk> On Fri, 2010-06-25 at 20:47 +0200, Bengt Thuree wrote: > Hi > > First, much appreciating the fast development and high quality code you > guys are producing. > > Just wondering when Shotwell will handle Ratings (Import, Filter, > Assign, Export), as well as Location tags. > In essence all the tags that F-Spot handles today? > Is this planned for 0.7 or? Adam will confirm but AFAIK, the feature set for 0.7 hasn't been decided yet, although all of the above are high on the list. > Would probably be a good idea to get import existing tags from an F-Spot > database working earlier rather than later, or? I'm working on that at the moment, with the aim to have a working solution for 0.7. I am also aware that it will require a fair amount of testing so the earlier I have some working code the better. Bruno From adam at yorba.org Fri Jun 25 20:48:53 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 25 Jun 2010 13:48:53 -0700 Subject: [Shotwell] Final call for testing before 0.6 In-Reply-To: <1277497568.5455.7.camel@nuuk> References: <4C24F551.2050609@yorba.org> <1277491633.26583.6.camel@lappis> <1277497568.5455.7.camel@nuuk> Message-ID: <4C251635.3050007@yorba.org> On 06/25/2010 01:26 PM, Bruno Girin wrote: > On Fri, 2010-06-25 at 20:47 +0200, Bengt Thuree wrote: > >> Hi >> >> First, much appreciating the fast development and high quality code you >> guys are producing. >> >> Just wondering when Shotwell will handle Ratings (Import, Filter, >> Assign, Export), as well as Location tags. >> In essence all the tags that F-Spot handles today? >> Is this planned for 0.7 or? >> > Adam will confirm but AFAIK, the feature set for 0.7 hasn't been decided > yet, although all of the above are high on the list. > Bruno is correct: we haven't chosen the 0.7 feature set yet but all of the above are strong candidates. I think users migrating from F-Spot will reasonably want to keep all their ratings and tags in Shotwell, and I think these features are important for that reason. adam From pdo.smith at gmail.com Sat Jun 26 12:21:33 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Sat, 26 Jun 2010 14:21:33 +0200 Subject: [Shotwell] Launching external editor In-Reply-To: <4C24D3E6.4040308@yorba.org> References: <4C24D3E6.4040308@yorba.org> Message-ID: OK, here is an example of a file that causes the problem: http://www.mediafire.com/file/jzng3zz0qto/IMGP8875.DNG It seems to happen with all my DNG files. Peter On Fri, Jun 25, 2010 at 6:05 PM, Adam Dingle wrote: > On 06/25/2010 03:13 AM, Peter DO Smith wrote: >> >> After having imported DNG files from my camera I tried to launch an >> external editor "Open with external editor" and got the following >> error >> >> Unable to launch editor: Size of Exif JPEG segment is larger than 65535 >> bytes. >> >> However if I open with RAW editor it launches Ufraw and everything >> works properly. Gimp is set as my image editor and it is registered in >> my copy of Ubuntu (10.04) >> I am using today's svn trunk >> > > Peter, > > thanks for the bug report. ?We'd like to see a DNG file that is causing this > problem. ?You can't send a DNG to this mailing list, but can you upload one > of your DNG files to a file sharing service (search Google for [file > hosting] to see a list of various free services) and post the URL here? > ?Thanks - > > adam > > From lucas at yorba.org Tue Jun 29 01:57:17 2010 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 28 Jun 2010 18:57:17 -0700 Subject: [Shotwell] Shotwell 0.6.0 - a digital photo manager for the GNOME desktop Message-ID: Yorba has released Shotwell 0.6.0, a major update to our digital photo manager. This release is packed with new features, including: * Basic support for RAW images, including import support for all common formats like CR2 and DNG * Full support for working with PNG images * Users can now zoom into photos to reveal latent detail * A new preferences dialog * Users can now open photos in an external editor, such as the GIMP, from within Shotwell * Photo tags and titles are imported and exported automatically via XMP and IPTC metadata * A new photo trash can * Numerous bug fixes and improved language support We highly recommend that all Shotwell users upgrade. Yorba would like to thank all of our bug testers and translators, without whom this release would not have been possible. You can download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ or grab a binary for Ubuntu Karmic or Lucid via Yorba's Launchpad PPA at: https://launchpad.net/~yorba/+archive/ppa -- Lucas Beeler From sebastianporta at gmail.com Tue Jun 29 15:31:57 2010 From: sebastianporta at gmail.com (Sebastian Porta) Date: Tue, 29 Jun 2010 12:31:57 -0300 Subject: [Shotwell] Icons in the sidebar Message-ID: Hello, everyone. First of all, I love the work that you all did for Shotwell. I really like the interface and the speed of the program. I have a little request, tough. Could you put icons in the sidebar for each categorie? I made a quick mockup using some icons (16x16) from elementary but you could use them for any theme that have the following icons "mimetypes/image" (Photos), "apps/evolution-calendar" or "apps/gnome-calendar" (Events) and "places/user-trash-full" (Trash). For the Tags, I use the one from "F-Spot" and change the color, so I guess you have to make one. Here's the mockup; http://dl.dropbox.com/u/113489/Shotwell.png I'm also put some shadow in the photos, just to see how it looks :) Regards -- Seba (AKA spg76) http://www.ubuntu-ar.org From adam at yorba.org Wed Jun 30 18:54:55 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 30 Jun 2010 11:54:55 -0700 Subject: [Shotwell] Icons in the sidebar In-Reply-To: References: Message-ID: <4C2B92FF.5020209@yorba.org> Sebastian, On 06/29/2010 08:31 AM, Sebastian Porta wrote: > Hello, everyone. > First of all, I love the work that you all did for Shotwell. I really like > the interface and the speed of the program. > Thanks! > I have a little request, tough. Could you put icons in the sidebar for each > categorie? We've considered this; this is http://trac.yorba.org/ticket/295 . > I made a quick mockup using some icons (16x16) from elementary > but you could use them for any theme that have the following icons > "mimetypes/image" (Photos), "apps/evolution-calendar" or > "apps/gnome-calendar" (Events) and "places/user-trash-full" (Trash). For the > Tags, I use the one from "F-Spot" and change the color, so I guess you have > to make one. Here's the mockup; http://dl.dropbox.com/u/113489/Shotwell.png > I'm also put some shadow in the photos, just to see how it looks :) > Thanks for the mockup. This looks promising, though I've never seen a GNOME application that has the dropdown triangles on the right side where you've put them. And to my knowledge we can't make the GNOME tree control act that way, so to implement that we might need to use a custom control, which might not work well with different themes. Do you think you could put together a mockup that has the triangles on the left, where they are in Shotwell today? By the way, we've also considered drop shadows - this is http://trac.yorba.org/ticket/1304 . :) adam From allison at yorba.org Wed Jun 30 21:54:10 2010 From: allison at yorba.org (Allison Barlow) Date: Wed, 30 Jun 2010 14:54:10 -0700 Subject: [Shotwell] Shotwell 0.6.1 - a digital photo organizer for the GNOME desktop Message-ID: Yorba has released Shotwell 0.6.1, an update to our digital photo organizer. This release includes important fixes and translation updates. It's highly recommended that all users upgrade. This release includes the following: * New Lithuanian and Serbian translations * Updated Italian and Spanish translations * More zooming shortcuts (* and / on numeric keypad) * Photos emptied from trash no longer reappear * Shotwell no longer offers to delete photos that failed to import from a camera * other minor fixes Download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ Binaries for Ubuntu Lucid and Maverick will soon be available at Yorba's Launchpad PPA: https://launchpad.net/~yorba/+archive/ppa Cheers, -- Allison Barlow