From pierrick.legall at gmail.com Fri Oct 1 21:34:23 2010 From: pierrick.legall at gmail.com (Pierrick LE GALL) Date: Fri, 1 Oct 2010 23:34:23 +0200 Subject: [Shotwell] publish photos to Piwigo Message-ID: Hello Shotwell Mailing List, I'm working on the Piwigo project, http://piwigo.org : Piwigo is an opensource (GPL) photo gallery software for the web. Some Piwigo users are asking for a publish option from Shotwell to Piwigo and I would be glad to help anyone with Vala/Shotwell skills! So if you're interested and think Piwigo deserves a publish connector in Shotwell, please tell me. Bye -- Pierrick LE GALL From brunogirin at gmail.com Sat Oct 2 16:44:19 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sat, 02 Oct 2010 17:44:19 +0100 Subject: [Shotwell] Some thought about Shotwell In-Reply-To: References: <4CA1F0EF.4020400@centrum.cz> Message-ID: <1286037859.5737.19.camel@nuuk> On Thu, 2010-09-30 at 15:32 -0700, Jim Nelson wrote: > Hello Stanislav, > > I've been thinking quite a bit about reorganizing the Shotwell code base, > mostly because (a) the number of files in a single directory is growing to > an unmanageable number, even for someone (like me) who knows the code base > in and out, and (b) to make it more approachable for outside contributors. > > I think you're bringing up some other points that are also worth > considering. To take them apart as separate questions: > > 1. Directory organization (which is what I've been thinking about) > 2. Source file naming conventions > 3. Class-per-file question (implied by #2) > 4. Namespaces (which I've been thinking about as well) > > To address each of these: > > 1. We're in agreement here, and looking over Rhythmbox's code, I see > parallels in what I've been pondering and how they sort things. This is > something I would definitely like to do with Shotwell's code base. > > 2. I'm seeing some variations on source file names depending on the project: > > * Rhythmbox uses a variant of the mechanism you're speaking of (i.e. > metadata/rb-metadata-common.c) > * The Vala compiler uses another (ccode/valaccodecomment.vala). > * Rygel uses Rhythmbox-style naming (ui/rygel-preferences-dialog.vala) > * F-Spot uses the C#/Java naming style (Imaging/JpegFile.cs) > * pitivi uses something similar, although not CamelCased > (ui/propertyeditor.py) > > Note that none of these strictly follow the GTK naming convention > (gtk/gtkbutton.c). > > What the above list tells me is that the jury is still out on an "official" > naming convention, especially in terms of non-C languages, with the one > exception that the filenames should be all lowercase (unless it's > Mono/C#/Java). > > You say that when valac runs it should look like a GNOME module written in > pure C. I'm not sure I agree with that. When you run valac in its default > mode, it deletes the .c files after compiling and linking. In a larger > project, yes, we keep them around to speed up compilation time (as well as > to examine them for debugging/performance reasons), but they are not useful > as "source" code -- no one should be editing them, and patching them > downstream would be dangerous territory. If we're going to rethink our > source naming convention, I feel it should be, above all else, consistent > and intuitive for Vala coders. I don't feel our naming should be a slave to > the .c files produced. Totally agree. The naming should make it easy for Vala coders so that new contributors can find their way around easily. > > If I was using Vala to produce a GObject library, then yes, that's more > compelling. (When we produce header files for plug-ins, that would be a > place we think about it -- I'm just not sure we want to let our yet-to-be > coded plug-in architecture dictate filenames everywhere else.) Agreed too. Although, I'm curious: what would be the difference between an organisation that is easy for Vala coders and one that makes it easy for C coders? Also I suspect that any GObject library written in Vala should be usable as a Vala library so can't be too far from the standard Vala practice. > > 3. One thing that is true for GTK, Rhythmbox, Vala, and Rygel is a strict > one-class-per-file organization. There are hundreds of classes in Shotwell, > and I don't think putting each and every one in a separate file is doing a > service to developers. (For example, we have 34 Command subclasses for the > undo/redo system. Some are 13 lines long.) I do think many of our files > have grown too large and should be broken up to keep the chunks small. > We've done a good job keeping UI code away from implementation code, it's > just a matter of separating the files appropriately in directories. > Breaking up the files into smaller chunks makes a lot of sense too. One way to do it is to go for a one class per file organisation by default and have exceptions for cases where a set of classes actually make sense together. If I look at the F-Spot import code, it would make a lot of sense to have one file per class for the top level interfaces and core classes but group the database classes together so that each file includes the main table class plus all the related behaviour classes as they only make sense together. So when you decide to re-organise the code, please tell me and I'll re-organise the F-Spot import code accordingly. > > 4. Namespaces are something else I'm considering -- making each subdirectory > a namespace makes logical sense to me, and means the code reflects the > logical organization of the source files. Plus, there's a cool Vala feature > -- the "internal" keyword -- that we can start taking advantage of with > well-thought-out namespacing. Namespaces are a great feature. It's the default way that Java operates and my experience with Java is that it helps tremendously in making the code clearer, especially when the name space naming convention follows the directory structure and logical organisation of the files. My ?0.02 Bruno From khj at be.cs.appstate.edu Sun Oct 3 17:08:31 2010 From: khj at be.cs.appstate.edu (Kenneth Jacker) Date: Sun, 03 Oct 2010 13:08:31 -0400 Subject: [Shotwell] F-Spot Import - Change Dir Name? Message-ID: <87lj6fxkz4.fsf@be.cs.appstate.edu> [ Ubuntu 10.04.1; shotwell-0.7.2 ] When I first ran 'shotwell', I choose the "import from F-Spot" option. All my prior pictures and tags were then available. But, all the photos are still under the old "../Pictures/F-Spot/" directory. I want to now get rid of F-Spot. My obsessive/compulsive nature would like the path to all my photos now be "../Pictures/Shotwell/" ... corresponding to my new setup and application. Does anyone know how I might this change? Thanks, -- Prof Kenneth H Jacker khj at cs.appstate.edu Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA From mahfiaz at gmail.com Sun Oct 3 17:52:01 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Sun, 03 Oct 2010 20:52:01 +0300 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <87lj6fxkz4.fsf@be.cs.appstate.edu> References: <87lj6fxkz4.fsf@be.cs.appstate.edu> Message-ID: <1286128321.25309.23.camel@antiloop> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: > [ Ubuntu 10.04.1; shotwell-0.7.2 ] > > When I first ran 'shotwell', I choose the "import from F-Spot" option. > All my prior pictures and tags were then available. > > But, all the photos are still under the old "../Pictures/F-Spot/" > directory. I want to now get rid of F-Spot. > > My obsessive/compulsive nature would like the path to all my photos now > be "../Pictures/Shotwell/" ... corresponding to my new setup and > application. > > Does anyone know how I might this change? > > > Thanks, http://trac.yorba.org/ticket/2485 See this ticket. If this is implemented in a smart[1] way, you could simply rename your F-spot directory to Shotwell, then relocate one file and everything would be fine. [1] By smart I mean Shotwell would assume it could have been directory change and would apply the directory change to other missing images as well, where applicable. Somewhere was talk about automatic relocating as well, but unfortunately I cannot find the ticket. Mattias From hendry.michael at gmail.com Sun Oct 3 22:10:37 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Sun, 03 Oct 2010 23:10:37 +0100 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <1286128321.25309.23.camel@antiloop> References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> Message-ID: <1286143837.1719.28.camel@Linley6> On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: > ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: > > [ Ubuntu 10.04.1; shotwell-0.7.2 ] > > > > When I first ran 'shotwell', I choose the "import from F-Spot" option. > > All my prior pictures and tags were then available. > > > > But, all the photos are still under the old "../Pictures/F-Spot/" > > directory. I want to now get rid of F-Spot. > > > > My obsessive/compulsive nature would like the path to all my photos now > > be "../Pictures/Shotwell/" ... corresponding to my new setup and > > application. > > > > Does anyone know how I might this change? > > > > > > Thanks, > > http://trac.yorba.org/ticket/2485 > See this ticket. If this is implemented in a smart[1] way, you could > simply rename your F-spot directory to Shotwell, then relocate one file > and everything would be fine. > > [1] By smart I mean Shotwell would assume it could have been directory > change and would apply the directory change to other missing images as > well, where applicable. > > > Somewhere was talk about automatic relocating as well, but unfortunately > I cannot find the ticket. > > > Mattias > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell This is a concern of mine, but in the more general case of a reorganisation of my image files and the directories that contain them. I have just imported > 21000 images, using links to the files rather than copying all the files, and in future I may well wish to change the directory structure that the images are contained in - e.g. to merge directories containing only a few images, or to move the whole tree to a new disc when the current one fails or gets filled up. Jim Nelson has confirmed that Shotwell will lose track of these files, and they'd have to be reimported and have all the tags restored - a tedious process, and likely to introduce errors. He tells me that additional features are to be introduced in version 0.8, which will attempt to find "lost" files and re-associate them with the database. This sounds like a time-consuming process (but for the computer, not its operator!), and I wonder if it would be more elegantly done by providing a file manager within Shotwell itself - it would then "know" where the files had gone, and could make adjustments to the database with this knowledge. Michael From brunogirin at gmail.com Sun Oct 3 22:24:20 2010 From: brunogirin at gmail.com (Bruno Girin) Date: Sun, 03 Oct 2010 23:24:20 +0100 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <1286143837.1719.28.camel@Linley6> References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> Message-ID: <1286144660.5010.5.camel@nuuk> On Sun, 2010-10-03 at 23:10 +0100, Michael Hendry wrote: [snip] > > This sounds like a time-consuming process (but for the computer, not its > operator!), and I wonder if it would be more elegantly done by providing > a file manager within Shotwell itself - it would then "know" where the > files had gone, and could make adjustments to the database with this > knowledge. I think there is already a ticket to add a folder view, which would provide some level of file handling, although I can't find it right now. However, that would not solve the original problem. Once things that could be done, now that Shotwell has the ability to change the path of the picture folder, would be to provide an option to copy all the files from the old folder to the new one when that happens. Bruno From fvhemert at gmail.com Sat Oct 2 06:02:19 2010 From: fvhemert at gmail.com (teek) Date: Fri, 1 Oct 2010 23:02:19 -0700 (PDT) Subject: [Shotwell] Handling RAW Files in Shotwell In-Reply-To: <4C69D6A0.1060004@yorba.org> References: <4C69D6A0.1060004@yorba.org> Message-ID: <1285999339097-23251.post@talk.nabble.com> Great that you already have a ticket for this as I have the same problem. Imo it can also be solved by appliying a filter on file type, I would just like to ignore the .cr2 files in my library, but then again, the solution you are proposing is more elegant (maybe with a toggle switch for only cr2, only jpg or both so you can compare). I love shotwell by the way, very nice already and extremely promissing... one of my dreams for the future is that this will also be able to replace lightroom with batch raw conversion and some nice sliders for sharpness and so on :) Thanx for the great software, its my most used application at the moment. Oh, one more thing, it would be nice to hide photo's from slideshows only, so you see them in the library (maybe with a red cross at the top right or something, in the same way you can hide powerpoint slides) but not when you give a show to your friends who are only interested in a selection of you 1000+ vacations photos.... -- View this message in context: http://shotwell.3510.www.nabble.com/Shotwell-Handling-RAW-Files-in-Shotwell-tp21346p23251.html Sent from the Shotwell mailing list archive at Nabble.com. From take at nerd.fi Mon Oct 4 10:13:32 2010 From: take at nerd.fi (Take) Date: Mon, 04 Oct 2010 13:13:32 +0300 Subject: [Shotwell] Shotwell removed some photos In-Reply-To: References: <4CA05028.7080304@nerd.fi> <4CA05AA5.7070801@nerd.fi> Message-ID: <4CA9A8CC.4050804@nerd.fi> On 09/27/2010 10:14 PM, Jim Nelson wrote: > First, Shotwell will never delete a master/original file without the user's > consent. Even then, Shotwell will move the master to the desktop trash Well, $something deleted those files, but unfortunately at this point it's pretty much impossible to figure out what happened on this case. I have been way too busy to try to replicate this, so all I have is an experiment. Anyways, I imported photos via remote system (NFS-access), and this has been working just fine, shotwell said that it imported XX photos and everything seemed to go trough just fine. The result is however that the files are missing. > Still, Shotwell won't do this without asking the user first. So, unless > there's some other step here, I don't believe Shotwell has deleted the file. Just to be sure: 1. Open shotwell with laptop which has /media/Photo and ~/.shotwell on NFS -mount 2. Import photos from SD-card 3. Wait (forever) for import to complete 4. Machine was up and running for few hours after that for web browsing etc various tasks 5. Shutdown laptop 6. Open shotwell at workstation (NFS-server) ...? -> Missing files > directory on your server. Are you sharing that directory with multiple > instances of Shotwell? That could be a big problem, especially if those > multiple instances are running at the same time. The Shotwell private > directory wasn't designed for this kind of usage. I am sharing it with multiple "instances" to maintain database sync, but if I try to access database with multiple clients it'll fail due to locked database. So, it's impossible to start multiple instances at the same time, and even if this is potentially dangerous, it allows usage from multiple computers. However, there's a lots of issues with this, so usability is something between unusable and poor, specially over ethernet/wlan link. -- Take From khj at be.cs.appstate.edu Mon Oct 4 14:44:23 2010 From: khj at be.cs.appstate.edu (Kenneth Jacker) Date: Mon, 04 Oct 2010 10:44:23 -0400 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <1286128321.25309.23.camel@antiloop> ("Mattias =?utf-8?Q?P?= =?utf-8?Q?=C3=B5ldaru=22's?= message of "Sun, 03 Oct 2010 20:52:01 +0300") References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> Message-ID: <87y6aevwzc.fsf@be.cs.appstate.edu> Thank you Mattias, Michael, and Bruno for your comments. Since there doesn't appear any way to do this currently, I decided to "work with my compulsions" and just leave everything under ../Pictures/F-Spot. Maybe I can "fix things" later ... Thanks again for your help! -Kenneth From ktenney at gmail.com Mon Oct 4 16:26:36 2010 From: ktenney at gmail.com (Kent Tenney) Date: Mon, 4 Oct 2010 11:26:36 -0500 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <1286143837.1719.28.camel@Linley6> References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> Message-ID: On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry wrote: > On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: >> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: >> > [ Ubuntu 10.04.1; ?shotwell-0.7.2 ] >> > >> > When I first ran 'shotwell', I choose the "import from F-Spot" option. >> > All my prior pictures and tags were then available. >> > >> > But, all the photos are still under the old "../Pictures/F-Spot/" >> > directory. ?I want to now get rid of F-Spot. >> > >> > My obsessive/compulsive nature would like the path to all my photos now >> > be "../Pictures/Shotwell/" ... corresponding to my new setup and >> > application. >> > >> > Does anyone know how I might this change? >> > >> > >> > Thanks, >> >> http://trac.yorba.org/ticket/2485 >> See this ticket. If this is implemented in a smart[1] way, you could >> simply rename your F-spot directory to Shotwell, then relocate one file >> and everything would be fine. >> >> [1] By smart I mean Shotwell would assume it could have been directory >> change and would apply the directory change to other missing images as >> well, where applicable. >> >> >> Somewhere was talk about automatic relocating as well, but unfortunately >> I cannot find the ticket. >> >> >> Mattias >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > This is a concern of mine, but in the more general case of a > reorganisation of my image files and the directories that contain them. > > I have just imported > 21000 images, using links to the files rather > than copying all the files, and in future I may well wish to change the > directory structure that the images are contained in - e.g. to merge > directories containing only a few images, or to move the whole tree to a > new disc when the current one fails or gets filled up. > > Jim Nelson has confirmed that Shotwell will lose track of these files, > and they'd have to be reimported and have all the tags restored - a > tedious process, and likely to introduce errors. He tells me that > additional features are to be introduced in version 0.8, which will > attempt to find "lost" files and re-associate them with the database. > > This sounds like a time-consuming process (but for the computer, not its > operator!), and I wonder if it would be more elegantly done by providing > a file manager within Shotwell itself - it would then "know" where the > files had gone, and could make adjustments to the database with this > knowledge. Other apps I've used have a "relocate" feature which allows replacing a portion of the filename path. Given "/home/me/my/old/path/2010-09/" containing files or directories, I could ask that "/home/me/my/old/path" in a filename path would be changed to "/mnt/cdrom/" or "/usr/local/photos/" or some such. Thanks, Kent > > Michael > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Mon Oct 4 18:38:52 2010 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 4 Oct 2010 11:38:52 -0700 Subject: [Shotwell] publish photos to Piwigo In-Reply-To: References: Message-ID: Hi Pierrick, We're happy to hear that Piwigo users are interested in publishing from Shotwell! That said, adding additional publishing services isn't likely a priority for us for at least the next release of Shotwell. However, if you or someone else on the Piwigo team is interested in a Piwigo connector for Shotwell, we'd be glad to accept a patch! Vala isn't a particularly hard language to learn, especially if you already have experience with another modern, object-oriented language like Java or C#. What's more, now that the architecture of Shotwell's publishing subsystem has settled down, writing a web connector for Shotwell isn't terribly difficult. If you're curious to see what it would entail, check out the "Photo Publishing" section of the Shotwell Architecture Overview at http://trac.yorba.org/wiki/ShotwellArchPhotoPublishing and read the "Publishing is Ready for Prime-time" post on the Yorba blog at http://www.yorba.org/blog/lucas/2010/06/publishing-is-ready-for-prime-time.html. Cheers, Lucas From jim at yorba.org Mon Oct 4 18:42:54 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 4 Oct 2010 11:42:54 -0700 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> Message-ID: The ticket that Michael (and others) is referring to is this one: http://trac.yorba.org/ticket/2476 In the Shotwell 0.7, there's a startup scan to verify all the files backing your photo objects in the library are present. If the file is missing, the photo is moved to the "Missing Files" page (which is only visible if there are missing files). In 0.8, we've extended this feature to attempt to locate renamed files. If you rename a single photo or rename a subdirectory they are stored in (i.e. ~/Pictures/F-Spot -> ~/Pictures/Shotwell), the startup scan will discover the change and associate the renamed files with their old photo objects. An additional feature (http://trac.yorba.org/ticket/2478) will scan unknown files in the library directory (which is set in the Preferences dialog) and auto-import them into the library. We plan on both of these being optional in 0.8 ( http://trac.yorba.org/ticket/2492). Now, these features have a key limitation: They only work inside the library directory. If you've linked photos from an external directory, Shotwell will *not* scan that directory for renamed files or auto-import from there. This is something we may do in the future; we're taking baby steps with this functionality. This why 0.8 doesn't solve Michael's problem but will solve Mattias and Kenneth's, because they're asking for changes inside the library directory be reflected in Shotwell. We could offer a "Locate Photo" option, as suggested by Kent, but in the case of 21,000 photos, it's not so simple. (We could offer a "Mass Locate Photo", but there's a lot of possibilities, and therefore pitfalls, with that kind of feature.) A re-scan feature would simply do what we're doing at startup; a better solution is active monitoring of the library, which is under consideration: http://trac.yorba.org/ticket/374 Finally, regarding Michael's concern about the tediousness of the scan: Yes, it can be time-consuming, but as you said, it's time-consuming for the app, not the user. We're working hard to make the scan as unobtrusive to the user as possible. Fortunately in the normal use-case, all we're doing is verifying the file exists (by checking the modification date and file size), which are low-impact operations. And because it happens in the background, the user shouldn't be stopped from immediately starting work. -- Jim On Mon, Oct 4, 2010 at 9:26 AM, Kent Tenney wrote: > On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry > wrote: > > On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: > >> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: > >> > [ Ubuntu 10.04.1; shotwell-0.7.2 ] > >> > > >> > When I first ran 'shotwell', I choose the "import from F-Spot" option. > >> > All my prior pictures and tags were then available. > >> > > >> > But, all the photos are still under the old "../Pictures/F-Spot/" > >> > directory. I want to now get rid of F-Spot. > >> > > >> > My obsessive/compulsive nature would like the path to all my photos > now > >> > be "../Pictures/Shotwell/" ... corresponding to my new setup and > >> > application. > >> > > >> > Does anyone know how I might this change? > >> > > >> > > >> > Thanks, > >> > >> http://trac.yorba.org/ticket/2485 > >> See this ticket. If this is implemented in a smart[1] way, you could > >> simply rename your F-spot directory to Shotwell, then relocate one file > >> and everything would be fine. > >> > >> [1] By smart I mean Shotwell would assume it could have been directory > >> change and would apply the directory change to other missing images as > >> well, where applicable. > >> > >> > >> Somewhere was talk about automatic relocating as well, but unfortunately > >> I cannot find the ticket. > >> > >> > >> Mattias > >> > >> _______________________________________________ > >> Shotwell mailing list > >> Shotwell at lists.yorba.org > >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > This is a concern of mine, but in the more general case of a > > reorganisation of my image files and the directories that contain them. > > > > I have just imported > 21000 images, using links to the files rather > > than copying all the files, and in future I may well wish to change the > > directory structure that the images are contained in - e.g. to merge > > directories containing only a few images, or to move the whole tree to a > > new disc when the current one fails or gets filled up. > > > > Jim Nelson has confirmed that Shotwell will lose track of these files, > > and they'd have to be reimported and have all the tags restored - a > > tedious process, and likely to introduce errors. He tells me that > > additional features are to be introduced in version 0.8, which will > > attempt to find "lost" files and re-associate them with the database. > > > > This sounds like a time-consuming process (but for the computer, not its > > operator!), and I wonder if it would be more elegantly done by providing > > a file manager within Shotwell itself - it would then "know" where the > > files had gone, and could make adjustments to the database with this > > knowledge. > > Other apps I've used have a "relocate" feature which allows replacing a > portion of the filename path. > > Given "/home/me/my/old/path/2010-09/" containing files or directories, > > I could ask that "/home/me/my/old/path" in a filename path > would be changed to "/mnt/cdrom/" or "/usr/local/photos/" > > or some such. > > Thanks, > Kent > > > > > Michael > > > > > > > > _______________________________________________ > > 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 plg at piwigo.org Mon Oct 4 18:48:53 2010 From: plg at piwigo.org (Pierrick LE GALL) Date: Mon, 4 Oct 2010 20:48:53 +0200 Subject: [Shotwell] publish photos to Piwigo In-Reply-To: References: Message-ID: Hi Lucas, Thank you for answering! I read your blog post and Piwigo provides a REST interface for photo uploading (that is already used in Digikam for example). At technical level I think Piwigo ready to receive Shotwell HTTP requests! If anyone reading this list is interested in writing such a publishing service, don't hesitate to tell me so. If I start working on a Shotwell publish service for Piwigo, I'll drop a message on this list :-) (to ask for help or just to get feedback). Cheers, -- Pierrick Le Gall On Mon, Oct 4, 2010 at 8:38 PM, Lucas Beeler wrote: > Hi Pierrick, > > We're happy to hear that Piwigo users are interested in publishing > from Shotwell! That said, adding additional publishing services isn't > likely a priority for us for at least the next release of Shotwell. > However, if you or someone else on the Piwigo team is interested in a > Piwigo connector for Shotwell, we'd be glad to accept a patch! Vala > isn't a particularly hard language to learn, especially if you already > have experience with another modern, object-oriented language like > Java or C#. What's more, now that the architecture of Shotwell's > publishing subsystem has settled down, writing a web connector for > Shotwell isn't terribly difficult. If you're curious to see what it > would entail, check out the "Photo Publishing" section of the > Shotwell Architecture Overview at > http://trac.yorba.org/wiki/ShotwellArchPhotoPublishing and read the > "Publishing is Ready for Prime-time" post on the Yorba blog at > http://www.yorba.org/blog/lucas/2010/06/publishing-is-ready-for-prime-time.html. > > Cheers, > Lucas > From maciej.rumianowski at gmail.com Mon Oct 4 19:26:47 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Mon, 04 Oct 2010 21:26:47 +0200 Subject: [Shotwell] search box enhancement Message-ID: <1286220407.1645.73.camel@maciej-netbook> Hi all, Firstly I would like to say thank you for a great software which is Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer Event on FOSDEM when I spoke with Adam:) This year on my University I have to do an individual project. I have spoken with my teacher and I can do what i want. So I have chosen Shotwell and I am thinking about an enhancement to implement. I thought about search box http://trac.yorba.org/ticket/80, but I am open for other options. I have one semester for my project (until end of January), and I should fit in that time span. About search box: Things that should be searchable are - tags, events, dates, titles, image metadata, other data (possibility to easily add new things to be searched for). Searches should be view aware. Search box should nicely integrate with the Shotwell's UI. Search box should have suggestions based on previous and possible searches. Search box shouldn't impact Shotwell's speed. Interested in your opinions. Cheers, Maciek From ingo.steiner at gmx.net Mon Oct 4 19:50:28 2010 From: ingo.steiner at gmx.net (Ingo Steiner) Date: Mon, 04 Oct 2010 21:50:28 +0200 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> Message-ID: <4CAA3004.1070107@gmx.net> On 04.10.2010 20:42, Jim Nelson wrote: > The ticket that Michael (and others) is referring to is this one: > http://trac.yorba.org/ticket/2476 > > In the Shotwell 0.7, there's a startup scan to verify all the files backing > your photo objects in the library are present. If the file is missing, the > photo is moved to the "Missing Files" page (which is only visible if there > are missing files). > > In 0.8, we've extended this feature to attempt to locate renamed files. If > you rename a single photo or rename a subdirectory they are stored in (i.e. > ~/Pictures/F-Spot -> ~/Pictures/Shotwell), the startup scan will discover > the change and associate the renamed files with their old photo objects. > > An additional feature (http://trac.yorba.org/ticket/2478) will scan unknown > files in the library directory (which is set in the Preferences dialog) and > auto-import them into the library. > > We plan on both of these being optional in 0.8 ( > http://trac.yorba.org/ticket/2492). > > Now, these features have a key limitation: They only work inside the library > directory. If you've linked photos from an external directory, Shotwell > will *not* scan that directory for renamed files or auto-import from there. > This is something we may do in the future; we're taking baby steps with this > functionality. This why 0.8 doesn't solve Michael's problem but will solve > Mattias and Kenneth's, because they're asking for changes inside the library > directory be reflected in Shotwell. > > We could offer a "Locate Photo" option, as suggested by Kent, but in the > case of 21,000 photos, it's not so simple. (We could offer a "Mass Locate > Photo", but there's a lot of possibilities, and therefore pitfalls, with > that kind of feature.) A re-scan feature would simply do what we're doing > at startup; a better solution is active monitoring of the library, which is > under consideration: http://trac.yorba.org/ticket/374 > > Finally, regarding Michael's concern about the tediousness of the scan: Yes, > it can be time-consuming, but as you said, it's time-consuming for the app, > not the user. We're working hard to make the scan as unobtrusive to the > user as possible. Fortunately in the normal use-case, all we're doing is > verifying the file exists (by checking the modification date and file size), > which are low-impact operations. And because it happens in the background, > the user shouldn't be stopped from immediately starting work. > > -- Jim I only started using Shotwell 0.7.2 on Ubuntu-Lucid-amd64 recently. My thanks to the team developing this great piece of software! I want to append another "feature request" which IMHO fits to this issue: I have my photo collection stored remotely on a NAS which I usually mount with nfs4 on my PC. This mount is not permanent, only on demand. The database of course is stored locally on my PC. All works perfectly when the nfs4 share is available. I even can umount the share with all thumbnails remaining visible and I can even browse through them. However when the nfs4 share is not available when starting Shotwell, all thumbnails shortly appear and when Shotwell is up, all "Events" are cleared out and no thumbnail preview is available (local database of course is available). Is there any possibility to view and browse the thumbnails even if the photo data are not accessible. Of course editing or opening in nautilus cannot be performed under this condition. Technically it should not be a big issue, as all the thumbnails are stored locally in the database together with the link to the photo itself (except the data to which the link points). This would allow to just scan the whole database to check or search for a photo without editing. Best regards, Ingo > > On Mon, Oct 4, 2010 at 9:26 AM, Kent Tenney wrote: > >> On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry >> wrote: >>> On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: >>>> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: >>>>> [ Ubuntu 10.04.1; shotwell-0.7.2 ] >>>>> >>>>> When I first ran 'shotwell', I choose the "import from F-Spot" option. >>>>> All my prior pictures and tags were then available. >>>>> >>>>> But, all the photos are still under the old "../Pictures/F-Spot/" >>>>> directory. I want to now get rid of F-Spot. >>>>> >>>>> My obsessive/compulsive nature would like the path to all my photos >> now >>>>> be "../Pictures/Shotwell/" ... corresponding to my new setup and >>>>> application. >>>>> >>>>> Does anyone know how I might this change? >>>>> >>>>> >>>>> Thanks, >>>> >>>> http://trac.yorba.org/ticket/2485 >>>> See this ticket. If this is implemented in a smart[1] way, you could >>>> simply rename your F-spot directory to Shotwell, then relocate one file >>>> and everything would be fine. >>>> >>>> [1] By smart I mean Shotwell would assume it could have been directory >>>> change and would apply the directory change to other missing images as >>>> well, where applicable. >>>> >>>> >>>> Somewhere was talk about automatic relocating as well, but unfortunately >>>> I cannot find the ticket. >>>> >>>> >>>> Mattias >>>> >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell at lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> This is a concern of mine, but in the more general case of a >>> reorganisation of my image files and the directories that contain them. >>> >>> I have just imported > 21000 images, using links to the files rather >>> than copying all the files, and in future I may well wish to change the >>> directory structure that the images are contained in - e.g. to merge >>> directories containing only a few images, or to move the whole tree to a >>> new disc when the current one fails or gets filled up. >>> >>> Jim Nelson has confirmed that Shotwell will lose track of these files, >>> and they'd have to be reimported and have all the tags restored - a >>> tedious process, and likely to introduce errors. He tells me that >>> additional features are to be introduced in version 0.8, which will >>> attempt to find "lost" files and re-associate them with the database. >>> >>> This sounds like a time-consuming process (but for the computer, not its >>> operator!), and I wonder if it would be more elegantly done by providing >>> a file manager within Shotwell itself - it would then "know" where the >>> files had gone, and could make adjustments to the database with this >>> knowledge. >> >> Other apps I've used have a "relocate" feature which allows replacing a >> portion of the filename path. >> >> Given "/home/me/my/old/path/2010-09/" containing files or directories, >> >> I could ask that "/home/me/my/old/path" in a filename path >> would be changed to "/mnt/cdrom/" or "/usr/local/photos/" >> >> or some such. >> >> Thanks, >> Kent >> >>> >>> Michael >>> >>> >>> >>> _______________________________________________ >>> 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 > -- ____________________________________________________________________ In a world without walls and fences we don't need windows and gates. From jim at yorba.org Mon Oct 4 21:35:30 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 4 Oct 2010 14:35:30 -0700 Subject: [Shotwell] publish photos to Piwigo In-Reply-To: References: Message-ID: I've made a ticket for this: http://trac.yorba.org/ticket/2639 -- Jim On Mon, Oct 4, 2010 at 11:48 AM, Pierrick LE GALL wrote: > Hi Lucas, > > Thank you for answering! I read your blog post and Piwigo provides a > REST interface for photo uploading (that is already used in Digikam > for example). At technical level I think Piwigo ready to receive > Shotwell HTTP requests! > > If anyone reading this list is interested in writing such a publishing > service, don't hesitate to tell me so. If I start working on a > Shotwell publish service for Piwigo, I'll drop a message on this list > :-) (to ask for help or just to get feedback). > > Cheers, > > -- > Pierrick Le Gall > > On Mon, Oct 4, 2010 at 8:38 PM, Lucas Beeler wrote: > > Hi Pierrick, > > > > We're happy to hear that Piwigo users are interested in publishing > > from Shotwell! That said, adding additional publishing services isn't > > likely a priority for us for at least the next release of Shotwell. > > However, if you or someone else on the Piwigo team is interested in a > > Piwigo connector for Shotwell, we'd be glad to accept a patch! Vala > > isn't a particularly hard language to learn, especially if you already > > have experience with another modern, object-oriented language like > > Java or C#. What's more, now that the architecture of Shotwell's > > publishing subsystem has settled down, writing a web connector for > > Shotwell isn't terribly difficult. If you're curious to see what it > > would entail, check out the "Photo Publishing" section of the > > Shotwell Architecture Overview at > > http://trac.yorba.org/wiki/ShotwellArchPhotoPublishing and read the > > "Publishing is Ready for Prime-time" post on the Yorba blog at > > > http://www.yorba.org/blog/lucas/2010/06/publishing-is-ready-for-prime-time.html > . > > > > Cheers, > > Lucas > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Mon Oct 4 21:54:28 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 4 Oct 2010 14:54:28 -0700 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: <4CAA3004.1070107@gmx.net> References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> <4CAA3004.1070107@gmx.net> Message-ID: When your photos are not available (NFS not mounted), they should be available in the "Missing Files" page. Are they not there? -- Jim On Mon, Oct 4, 2010 at 12:50 PM, Ingo Steiner wrote: > On 04.10.2010 20:42, Jim Nelson wrote: > > The ticket that Michael (and others) is referring to is this one: > > http://trac.yorba.org/ticket/2476 > > > > In the Shotwell 0.7, there's a startup scan to verify all the files > backing > > your photo objects in the library are present. If the file is missing, > the > > photo is moved to the "Missing Files" page (which is only visible if > there > > are missing files). > > > > In 0.8, we've extended this feature to attempt to locate renamed files. > If > > you rename a single photo or rename a subdirectory they are stored in > (i.e. > > ~/Pictures/F-Spot -> ~/Pictures/Shotwell), the startup scan will discover > > the change and associate the renamed files with their old photo objects. > > > > An additional feature (http://trac.yorba.org/ticket/2478) will scan > unknown > > files in the library directory (which is set in the Preferences dialog) > and > > auto-import them into the library. > > > > We plan on both of these being optional in 0.8 ( > > http://trac.yorba.org/ticket/2492). > > > > Now, these features have a key limitation: They only work inside the > library > > directory. If you've linked photos from an external directory, Shotwell > > will *not* scan that directory for renamed files or auto-import from > there. > > This is something we may do in the future; we're taking baby steps with > this > > functionality. This why 0.8 doesn't solve Michael's problem but will > solve > > Mattias and Kenneth's, because they're asking for changes inside the > library > > directory be reflected in Shotwell. > > > > We could offer a "Locate Photo" option, as suggested by Kent, but in the > > case of 21,000 photos, it's not so simple. (We could offer a "Mass > Locate > > Photo", but there's a lot of possibilities, and therefore pitfalls, with > > that kind of feature.) A re-scan feature would simply do what we're > doing > > at startup; a better solution is active monitoring of the library, which > is > > under consideration: http://trac.yorba.org/ticket/374 > > > > Finally, regarding Michael's concern about the tediousness of the scan: > Yes, > > it can be time-consuming, but as you said, it's time-consuming for the > app, > > not the user. We're working hard to make the scan as unobtrusive to the > > user as possible. Fortunately in the normal use-case, all we're doing is > > verifying the file exists (by checking the modification date and file > size), > > which are low-impact operations. And because it happens in the > background, > > the user shouldn't be stopped from immediately starting work. > > > > -- Jim > > I only started using Shotwell 0.7.2 on Ubuntu-Lucid-amd64 recently. My > thanks to the team developing this great piece of software! > > I want to append another "feature request" which IMHO fits to this issue: > > I have my photo collection stored remotely on a NAS which I usually > mount with nfs4 on my PC. This mount is not permanent, only on demand. > The database of course is stored locally on my PC. > > All works perfectly when the nfs4 share is available. I even can umount > the share with all thumbnails remaining visible and I can even browse > through them. > > However when the nfs4 share is not available when starting Shotwell, all > thumbnails shortly appear and when Shotwell is up, all "Events" are > cleared out and no thumbnail preview is available (local database of > course is available). > > Is there any possibility to view and browse the thumbnails even if the > photo data are not accessible. Of course editing or opening in nautilus > cannot be performed under this condition. Technically it should not be a > big issue, as all the thumbnails are stored locally in the database > together with the link to the photo itself (except the data to which the > link points). This would allow to just scan the whole database to check > or search for a photo without editing. > > Best regards, > Ingo > > > > > > On Mon, Oct 4, 2010 at 9:26 AM, Kent Tenney wrote: > > > >> On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry < > hendry.michael at gmail.com> > >> wrote: > >>> On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: > >>>> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: > >>>>> [ Ubuntu 10.04.1; shotwell-0.7.2 ] > >>>>> > >>>>> When I first ran 'shotwell', I choose the "import from F-Spot" > option. > >>>>> All my prior pictures and tags were then available. > >>>>> > >>>>> But, all the photos are still under the old "../Pictures/F-Spot/" > >>>>> directory. I want to now get rid of F-Spot. > >>>>> > >>>>> My obsessive/compulsive nature would like the path to all my photos > >> now > >>>>> be "../Pictures/Shotwell/" ... corresponding to my new setup and > >>>>> application. > >>>>> > >>>>> Does anyone know how I might this change? > >>>>> > >>>>> > >>>>> Thanks, > >>>> > >>>> http://trac.yorba.org/ticket/2485 > >>>> See this ticket. If this is implemented in a smart[1] way, you could > >>>> simply rename your F-spot directory to Shotwell, then relocate one > file > >>>> and everything would be fine. > >>>> > >>>> [1] By smart I mean Shotwell would assume it could have been directory > >>>> change and would apply the directory change to other missing images as > >>>> well, where applicable. > >>>> > >>>> > >>>> Somewhere was talk about automatic relocating as well, but > unfortunately > >>>> I cannot find the ticket. > >>>> > >>>> > >>>> Mattias > >>>> > >>>> _______________________________________________ > >>>> Shotwell mailing list > >>>> Shotwell at lists.yorba.org > >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > >>> > >>> This is a concern of mine, but in the more general case of a > >>> reorganisation of my image files and the directories that contain them. > >>> > >>> I have just imported > 21000 images, using links to the files rather > >>> than copying all the files, and in future I may well wish to change the > >>> directory structure that the images are contained in - e.g. to merge > >>> directories containing only a few images, or to move the whole tree to > a > >>> new disc when the current one fails or gets filled up. > >>> > >>> Jim Nelson has confirmed that Shotwell will lose track of these files, > >>> and they'd have to be reimported and have all the tags restored - a > >>> tedious process, and likely to introduce errors. He tells me that > >>> additional features are to be introduced in version 0.8, which will > >>> attempt to find "lost" files and re-associate them with the database. > >>> > >>> This sounds like a time-consuming process (but for the computer, not > its > >>> operator!), and I wonder if it would be more elegantly done by > providing > >>> a file manager within Shotwell itself - it would then "know" where the > >>> files had gone, and could make adjustments to the database with this > >>> knowledge. > >> > >> Other apps I've used have a "relocate" feature which allows replacing a > >> portion of the filename path. > >> > >> Given "/home/me/my/old/path/2010-09/" containing files or directories, > >> > >> I could ask that "/home/me/my/old/path" in a filename path > >> would be changed to "/mnt/cdrom/" or "/usr/local/photos/" > >> > >> or some such. > >> > >> Thanks, > >> Kent > >> > >>> > >>> Michael > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > ____________________________________________________________________ > In a world without walls and fences we don't need windows and gates. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Mon Oct 4 22:01:12 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 4 Oct 2010 15:01:12 -0700 Subject: [Shotwell] Some thought about Shotwell In-Reply-To: <1286037859.5737.19.camel@nuuk> References: <4CA1F0EF.4020400@centrum.cz> <1286037859.5737.19.camel@nuuk> Message-ID: On Sat, Oct 2, 2010 at 9:44 AM, Bruno Girin wrote: > On Thu, 2010-09-30 at 15:32 -0700, Jim Nelson wrote: > > Agreed too. Although, I'm curious: what would be the difference between > an organisation that is easy for Vala coders and one that makes it easy > for C coders? Also I suspect that any GObject library written in Vala > should be usable as a Vala library so can't be too far from the standard > Vala practice. > > I guess what I'm keying off here is the name of the file matching the name of the class inside of it. Because classes are such priority objects in languages like Vala, it makes sense to me that the filename would match them case-wise. However, seeing that other Vala projects don't do it this way, I'm not saying this is the only way to do it. I'm not even seeing a "standard" Vala naming practice yet. I guess my larger point was, because Vala isn't C, I don't feel we should simply be imitating GNOME C conventions. But if we think it through and it makes sense, I'm not against them either. > One way to do it is to go for a one class per file organisation by > default and have exceptions for cases where a set of classes actually > make sense together. > I suspect that's the scheme I'll go for when the time comes. > Namespaces are a great feature. It's the default way that Java operates > and my experience with Java is that it helps tremendously in making the > code clearer, especially when the name space naming convention follows > the directory structure and logical organisation of the files. > I agree, their package scheme does go a long way to keeping things tidy. If we can clean things up, create a natural and unsurprising consistency in naming, and stick to the policy moving forward, I think we'll be in good shape. -- Jim From ingo.steiner at gmx.net Tue Oct 5 10:36:04 2010 From: ingo.steiner at gmx.net (Ingo Steiner) Date: Tue, 05 Oct 2010 12:36:04 +0200 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> <4CAA3004.1070107@gmx.net> Message-ID: <4CAAFF94.7050903@gmx.net> On 04.10.2010 23:54, Jim Nelson wrote: > When your photos are not available (NFS not mounted), they should be > available in the "Missing Files" page. Are they not there? > > -- Jim Oh thanks and sorry for not finding out myselfs! Of course all thumbnails can be browsed under "Missing Files", Ingo > On Mon, Oct 4, 2010 at 12:50 PM, Ingo Steiner > wrote: > > On 04.10.2010 20:42, Jim Nelson wrote: > > The ticket that Michael (and others) is referring to is this one: > > http://trac.yorba.org/ticket/2476 > > > > In the Shotwell 0.7, there's a startup scan to verify all the > files backing > > your photo objects in the library are present. If the file is > missing, the > > photo is moved to the "Missing Files" page (which is only visible > if there > > are missing files). > > > > In 0.8, we've extended this feature to attempt to locate renamed > files. If > > you rename a single photo or rename a subdirectory they are stored > in (i.e. > > ~/Pictures/F-Spot -> ~/Pictures/Shotwell), the startup scan will > discover > > the change and associate the renamed files with their old photo > objects. > > > > An additional feature (http://trac.yorba.org/ticket/2478) will > scan unknown > > files in the library directory (which is set in the Preferences > dialog) and > > auto-import them into the library. > > > > We plan on both of these being optional in 0.8 ( > > http://trac.yorba.org/ticket/2492). > > > > Now, these features have a key limitation: They only work inside > the library > > directory. If you've linked photos from an external directory, > Shotwell > > will *not* scan that directory for renamed files or auto-import > from there. > > This is something we may do in the future; we're taking baby steps > with this > > functionality. This why 0.8 doesn't solve Michael's problem but > will solve > > Mattias and Kenneth's, because they're asking for changes inside > the library > > directory be reflected in Shotwell. > > > > We could offer a "Locate Photo" option, as suggested by Kent, but > in the > > case of 21,000 photos, it's not so simple. (We could offer a > "Mass Locate > > Photo", but there's a lot of possibilities, and therefore > pitfalls, with > > that kind of feature.) A re-scan feature would simply do what > we're doing > > at startup; a better solution is active monitoring of the library, > which is > > under consideration: http://trac.yorba.org/ticket/374 > > > > Finally, regarding Michael's concern about the tediousness of the > scan: Yes, > > it can be time-consuming, but as you said, it's time-consuming for > the app, > > not the user. We're working hard to make the scan as unobtrusive > to the > > user as possible. Fortunately in the normal use-case, all we're > doing is > > verifying the file exists (by checking the modification date and > file size), > > which are low-impact operations. And because it happens in the > background, > > the user shouldn't be stopped from immediately starting work. > > > > -- Jim > > I only started using Shotwell 0.7.2 on Ubuntu-Lucid-amd64 recently. My > thanks to the team developing this great piece of software! > > I want to append another "feature request" which IMHO fits to this > issue: > > I have my photo collection stored remotely on a NAS which I usually > mount with nfs4 on my PC. This mount is not permanent, only on demand. > The database of course is stored locally on my PC. > > All works perfectly when the nfs4 share is available. I even can umount > the share with all thumbnails remaining visible and I can even browse > through them. > > However when the nfs4 share is not available when starting Shotwell, all > thumbnails shortly appear and when Shotwell is up, all "Events" are > cleared out and no thumbnail preview is available (local database of > course is available). > > Is there any possibility to view and browse the thumbnails even if the > photo data are not accessible. Of course editing or opening in nautilus > cannot be performed under this condition. Technically it should not be a > big issue, as all the thumbnails are stored locally in the database > together with the link to the photo itself (except the data to which the > link points). This would allow to just scan the whole database to check > or search for a photo without editing. > > Best regards, > Ingo > > > > > > On Mon, Oct 4, 2010 at 9:26 AM, Kent Tenney > wrote: > > > >> On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry > > > >> wrote: > >>> On Sun, 2010-10-03 at 20:52 +0300, Mattias P?ldaru wrote: > >>>> ?hel kenal p?eval, P, 2010-10-03 kell 13:08, kirjutas Kenneth > Jacker: > >>>>> [ Ubuntu 10.04.1; shotwell-0.7.2 ] > >>>>> > >>>>> When I first ran 'shotwell', I choose the "import from F-Spot" > option. > >>>>> All my prior pictures and tags were then available. > >>>>> > >>>>> But, all the photos are still under the old "../Pictures/F-Spot/" > >>>>> directory. I want to now get rid of F-Spot. > >>>>> > >>>>> My obsessive/compulsive nature would like the path to all my > photos > >> now > >>>>> be "../Pictures/Shotwell/" ... corresponding to my new setup and > >>>>> application. > >>>>> > >>>>> Does anyone know how I might this change? > >>>>> > >>>>> > >>>>> Thanks, > >>>> > >>>> http://trac.yorba.org/ticket/2485 > >>>> See this ticket. If this is implemented in a smart[1] way, you > could > >>>> simply rename your F-spot directory to Shotwell, then relocate > one file > >>>> and everything would be fine. > >>>> > >>>> [1] By smart I mean Shotwell would assume it could have been > directory > >>>> change and would apply the directory change to other missing > images as > >>>> well, where applicable. > >>>> > >>>> > >>>> Somewhere was talk about automatic relocating as well, but > unfortunately > >>>> I cannot find the ticket. > >>>> > >>>> > >>>> Mattias > >>>> > >>>> _______________________________________________ > >>>> Shotwell mailing list > >>>> Shotwell at lists.yorba.org > >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > >>> > >>> This is a concern of mine, but in the more general case of a > >>> reorganisation of my image files and the directories that > contain them. > >>> > >>> I have just imported > 21000 images, using links to the files rather > >>> than copying all the files, and in future I may well wish to > change the > >>> directory structure that the images are contained in - e.g. to merge > >>> directories containing only a few images, or to move the whole > tree to a > >>> new disc when the current one fails or gets filled up. > >>> > >>> Jim Nelson has confirmed that Shotwell will lose track of these > files, > >>> and they'd have to be reimported and have all the tags restored - a > >>> tedious process, and likely to introduce errors. He tells me that > >>> additional features are to be introduced in version 0.8, which will > >>> attempt to find "lost" files and re-associate them with the > database. > >>> > >>> This sounds like a time-consuming process (but for the computer, > not its > >>> operator!), and I wonder if it would be more elegantly done by > providing > >>> a file manager within Shotwell itself - it would then "know" > where the > >>> files had gone, and could make adjustments to the database with this > >>> knowledge. > >> > >> Other apps I've used have a "relocate" feature which allows > replacing a > >> portion of the filename path. > >> > >> Given "/home/me/my/old/path/2010-09/" containing files or > directories, > >> > >> I could ask that "/home/me/my/old/path" in a filename path > >> would be changed to "/mnt/cdrom/" or "/usr/local/photos/" > >> > >> or some such. > >> > >> Thanks, > >> Kent > >> > >>> > >>> Michael > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > ____________________________________________________________________ > In a world without walls and fences we don't need windows and gates. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -- ____________________________________________________________________ In a world without walls and fences we don't need windows and gates. From khj at be.cs.appstate.edu Tue Oct 5 14:26:28 2010 From: khj at be.cs.appstate.edu (Kenneth Jacker) Date: Tue, 05 Oct 2010 10:26:28 -0400 Subject: [Shotwell] F-Spot Import - Change Dir Name? In-Reply-To: (Jim Nelson's message of "Mon, 4 Oct 2010 11:42:54 -0700") References: <87lj6fxkz4.fsf@be.cs.appstate.edu> <1286128321.25309.23.camel@antiloop> <1286143837.1719.28.camel@Linley6> Message-ID: <87r5g4iuln.fsf@be.cs.appstate.edu> jim> In 0.8, we've extended this feature to attempt to locate renamed jim> files. If you rename a single photo or rename a subdirectory jim> they are stored in (i.e. ~/Pictures/F-Spot -> ~/Pictures/Shotwell), jim> the startup scan will discover the change and associate the jim> renamed files with their old photo objects. That sounds like *exactly* what I need ... :-) I'll just wait until v0.8 is released, and make the dir change. Thanks! -Kenneth From adam at yorba.org Tue Oct 5 20:43:21 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 05 Oct 2010 13:43:21 -0700 Subject: [Shotwell] search box enhancement In-Reply-To: <1286220407.1645.73.camel@maciej-netbook> References: <1286220407.1645.73.camel@maciej-netbook> Message-ID: <4CAB8DE9.4030803@yorba.org> Maciek, yes, it was nice to meet you at FOSDEM and I'm glad we've been able to stay in touch after that. I'm glad you're interested in contributing to Shotwell. I think that the search box might be a bit ambitious as a first contribution, however. We're currently planning to implement a search box in the Shotwell 0.9 time frame and I think the search box will be a major feature for that release. It will replace the existing rating filter icon on the Shotwell toolbar, since you'll be able to use the search box to filter by rating, name and more as you suggested. The design of the search box is still undetermined, but may involve some delicate user interface tradeoffs and the core Shotwell team will be highly involved in making those. I think that any of the following projects would be challenging, but still approachable enough to attack in one semester: - slideshow transitions (http://trac.yorba.org/ticket/1081) - straighten photo (http://trac.yorba.org/ticket/61) - use pictures as screensaver (http://trac.yorba.org/ticket/1112) - printing improvements (http://trac.yorba.org/ticket/1188, http://trac.yorba.org/ticket/1189) - export to Gallery (http://trac.yorba.org/ticket/1585) - upload video to YouTube (http://trac.yorba.org/ticket/1589) - export slideshow to video (http://trac.yorba.org/ticket/1590) - border fade effects (http://trac.yorba.org/ticket/1914) - support .bmp and .gif images (http://trac.yorba.org/ticket/2154) - publish to Blogger (http://trac.yorba.org/ticket/2522) - Piwigo publishing (http://trac.yorba.org/ticket/2639) Would any of these be of interest to you? You could certainly look through the Shotwell ticket list for other ideas as well. adam On 10/04/2010 12:26 PM, Maciej Rumianowski wrote: > Hi all, > > Firstly I would like to say thank you for a great software which is > Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer > Event on FOSDEM when I spoke with Adam:) > > This year on my University I have to do an individual project. I have > spoken with my teacher and I can do what i want. So I have chosen > Shotwell and I am thinking about an enhancement to implement. > > I thought about search box http://trac.yorba.org/ticket/80, but I am > open for other options. I have one semester for my project (until end of > January), and I should fit in that time span. > > About search box: > Things that should be searchable are - tags, events, dates, titles, > image metadata, other data (possibility to easily add new things to be > searched for). Searches should be view aware. Search box should nicely > integrate with the Shotwell's UI. Search box should have suggestions > based on previous and possible searches. Search box shouldn't impact > Shotwell's speed. > > Interested in your opinions. > > Cheers, > Maciek > > From maciej.rumianowski at gmail.com Tue Oct 5 21:22:47 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Tue, 05 Oct 2010 23:22:47 +0200 Subject: [Shotwell] search box enhancement In-Reply-To: <4CAB8DE9.4030803@yorba.org> References: <1286220407.1645.73.camel@maciej-netbook> <4CAB8DE9.4030803@yorba.org> Message-ID: <1286313767.5642.49.camel@maciej-netbook> Adam, I didn't realise that it so huge. My ambition is really big, because Shotwell will be my first open-source project that I contribute into the code. I find "publish to Blogger (http://trac.yorba.org/ticket/2522)" and "Piwigo publishing (http://trac.yorba.org/ticket/2639)" interesting. In some of my applications I thought about publishing to such things as Blogger. Blogger is more known in Poland so I would like to work on it. I have forwarded the list of topics to my friends on University and maybe some of them will also work on Shotwell:) Cheers, Maciek Dnia 2010-10-05, wto o godzinie 13:43 -0700, Adam Dingle pisze: > Maciek, > > yes, it was nice to meet you at FOSDEM and I'm glad we've been able to > stay in touch after that. > > I'm glad you're interested in contributing to Shotwell. I think that > the search box might be a bit ambitious as a first contribution, > however. We're currently planning to implement a search box in the > Shotwell 0.9 time frame and I think the search box will be a major > feature for that release. It will replace the existing rating filter > icon on the Shotwell toolbar, since you'll be able to use the search box > to filter by rating, name and more as you suggested. The design of the > search box is still undetermined, but may involve some delicate user > interface tradeoffs and the core Shotwell team will be highly involved > in making those. > > I think that any of the following projects would be challenging, but > still approachable enough to attack in one semester: > > - slideshow transitions (http://trac.yorba.org/ticket/1081) > - straighten photo (http://trac.yorba.org/ticket/61) > - use pictures as screensaver (http://trac.yorba.org/ticket/1112) > - printing improvements (http://trac.yorba.org/ticket/1188, > http://trac.yorba.org/ticket/1189) > - export to Gallery (http://trac.yorba.org/ticket/1585) > - upload video to YouTube (http://trac.yorba.org/ticket/1589) > - export slideshow to video (http://trac.yorba.org/ticket/1590) > - border fade effects (http://trac.yorba.org/ticket/1914) > - support .bmp and .gif images (http://trac.yorba.org/ticket/2154) > - publish to Blogger (http://trac.yorba.org/ticket/2522) > - Piwigo publishing (http://trac.yorba.org/ticket/2639) > > Would any of these be of interest to you? You could certainly look > through the Shotwell ticket list for other ideas as well. > > adam > > On 10/04/2010 12:26 PM, Maciej Rumianowski wrote: > > Hi all, > > > > Firstly I would like to say thank you for a great software which is > > Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer > > Event on FOSDEM when I spoke with Adam:) > > > > This year on my University I have to do an individual project. I have > > spoken with my teacher and I can do what i want. So I have chosen > > Shotwell and I am thinking about an enhancement to implement. > > > > I thought about search box http://trac.yorba.org/ticket/80, but I am > > open for other options. I have one semester for my project (until end of > > January), and I should fit in that time span. > > > > About search box: > > Things that should be searchable are - tags, events, dates, titles, > > image metadata, other data (possibility to easily add new things to be > > searched for). Searches should be view aware. Search box should nicely > > integrate with the Shotwell's UI. Search box should have suggestions > > based on previous and possible searches. Search box shouldn't impact > > Shotwell's speed. > > > > Interested in your opinions. > > > > Cheers, > > Maciek > > > > > From plg at piwigo.org Tue Oct 5 21:53:44 2010 From: plg at piwigo.org (Pierrick LE GALL) Date: Tue, 5 Oct 2010 23:53:44 +0200 Subject: [Shotwell] search box enhancement In-Reply-To: <1286313767.5642.49.camel@maciej-netbook> References: <1286220407.1645.73.camel@maciej-netbook> <4CAB8DE9.4030803@yorba.org> <1286313767.5642.49.camel@maciej-netbook> Message-ID: Hi Maciej, On Tue, Oct 5, 2010 at 11:22 PM, Maciej Rumianowski wrote: > I find "publish to Blogger (http://trac.yorba.org/ticket/2522)" and > "Piwigo publishing (http://trac.yorba.org/ticket/2639)" interesting. Piwigo is available in Polish language and Piwigo has a website in Polish on http://pl.piwigo.org but coding is mainly done in English. Don't hesitate to ask if you have questions related to Piwigo API for uploading photos! Cheers, -- Pierrick LE GALL, http://piwigo.org From adam at yorba.org Wed Oct 6 14:34:41 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 06 Oct 2010 07:34:41 -0700 Subject: [Shotwell] search box enhancement In-Reply-To: <1286313767.5642.49.camel@maciej-netbook> References: <1286220407.1645.73.camel@maciej-netbook> <4CAB8DE9.4030803@yorba.org> <1286313767.5642.49.camel@maciej-netbook> Message-ID: <4CAC8901.2030709@yorba.org> Maciek, On 10/05/2010 02:22 PM, Maciej Rumianowski wrote: > Adam, > > I didn't realise that it so huge. My ambition is really big, because > Shotwell will be my first open-source project that I contribute into the > code. Glad you're feeling ambitious. :) > I find "publish to Blogger (http://trac.yorba.org/ticket/2522)" and > "Piwigo publishing (http://trac.yorba.org/ticket/2639)" interesting. In > some of my applications I thought about publishing to such things as > Blogger. > Blogger is more known in Poland so I would like to work on it. That sounds great. Feel free to set yourself as the owner of the Blogger ticket so that others will realize that someone is working on it. > I have forwarded the list of topics to my friends on University and > maybe some of them will also work on Shotwell:) Great - I hope you can recruit an army of Polish students to help develop our various features! :) adam > Dnia 2010-10-05, wto o godzinie 13:43 -0700, Adam Dingle pisze: >> Maciek, >> >> yes, it was nice to meet you at FOSDEM and I'm glad we've been able to >> stay in touch after that. >> >> I'm glad you're interested in contributing to Shotwell. I think that >> the search box might be a bit ambitious as a first contribution, >> however. We're currently planning to implement a search box in the >> Shotwell 0.9 time frame and I think the search box will be a major >> feature for that release. It will replace the existing rating filter >> icon on the Shotwell toolbar, since you'll be able to use the search box >> to filter by rating, name and more as you suggested. The design of the >> search box is still undetermined, but may involve some delicate user >> interface tradeoffs and the core Shotwell team will be highly involved >> in making those. >> >> I think that any of the following projects would be challenging, but >> still approachable enough to attack in one semester: >> >> - slideshow transitions (http://trac.yorba.org/ticket/1081) >> - straighten photo (http://trac.yorba.org/ticket/61) >> - use pictures as screensaver (http://trac.yorba.org/ticket/1112) >> - printing improvements (http://trac.yorba.org/ticket/1188, >> http://trac.yorba.org/ticket/1189) >> - export to Gallery (http://trac.yorba.org/ticket/1585) >> - upload video to YouTube (http://trac.yorba.org/ticket/1589) >> - export slideshow to video (http://trac.yorba.org/ticket/1590) >> - border fade effects (http://trac.yorba.org/ticket/1914) >> - support .bmp and .gif images (http://trac.yorba.org/ticket/2154) >> - publish to Blogger (http://trac.yorba.org/ticket/2522) >> - Piwigo publishing (http://trac.yorba.org/ticket/2639) >> >> Would any of these be of interest to you? You could certainly look >> through the Shotwell ticket list for other ideas as well. >> >> adam >> >> On 10/04/2010 12:26 PM, Maciej Rumianowski wrote: >>> Hi all, >>> >>> Firstly I would like to say thank you for a great software which is >>> Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer >>> Event on FOSDEM when I spoke with Adam:) >>> >>> This year on my University I have to do an individual project. I have >>> spoken with my teacher and I can do what i want. So I have chosen >>> Shotwell and I am thinking about an enhancement to implement. >>> >>> I thought about search box http://trac.yorba.org/ticket/80, but I am >>> open for other options. I have one semester for my project (until end of >>> January), and I should fit in that time span. >>> >>> About search box: >>> Things that should be searchable are - tags, events, dates, titles, >>> image metadata, other data (possibility to easily add new things to be >>> searched for). Searches should be view aware. Search box should nicely >>> integrate with the Shotwell's UI. Search box should have suggestions >>> based on previous and possible searches. Search box shouldn't impact >>> Shotwell's speed. >>> >>> Interested in your opinions. >>> >>> Cheers, >>> Maciek >>> >>> > From pdo.smith at gmail.com Wed Oct 6 18:34:22 2010 From: pdo.smith at gmail.com (Peter DO Smith) Date: Wed, 6 Oct 2010 20:34:22 +0200 Subject: [Shotwell] Panorama feature/plugin for Shotwell Message-ID: Has a panorama feature/plugin been considered for Shotwell? Something along the lines of Hugin? I have been using Hugin to stitch together photos into panoramas. While it is undoubtedly a most capable tool for creating panoramas its user interface design is difficult, counterintuitive and counterproductive. I think it is time that the elegant simplicity of the Shotwell approach was brought to bear on the problem of constructing panoramas. I think this would be a natural companion to Shotwell. Peter From adam at yorba.org Wed Oct 6 21:23:01 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 06 Oct 2010 14:23:01 -0700 Subject: [Shotwell] Panorama feature/plugin for Shotwell In-Reply-To: References: Message-ID: <4CACE8B5.3010308@yorba.org> On 10/06/2010 11:34 AM, Peter DO Smith wrote: > Has a panorama feature/plugin been considered for Shotwell? Something along > the lines of Hugin? Yes: see http://trac.yorba.org/ticket/2466 . > I have been using Hugin to stitch together photos into panoramas. While it > is undoubtedly a most capable tool for creating panoramas its user interface > design is difficult, counterintuitive and counterproductive. I think it is > time that the elegant simplicity of the Shotwell approach was brought to > bear on the problem of constructing panoramas. > I think this would be a natural companion to Shotwell. Agreed. Patches welcome! :) adam From scolex at centrum.cz Thu Oct 7 15:05:16 2010 From: scolex at centrum.cz (Stanislav Nowak) Date: Thu, 07 Oct 2010 17:05:16 +0200 Subject: [Shotwell] Some thought about Shotwell In-Reply-To: References: <4CA1F0EF.4020400@centrum.cz> Message-ID: <4CADE1AC.4060601@centrum.cz> Hi, Dne 1.10.2010 00:32, Jim Nelson napsal(a): > > Hello Stanislav, > > > > I've been thinking quite a bit about reorganizing the Shotwell code base, > > mostly because (a) the number of files in a single directory is growing to > > an unmanageable number, even for someone (like me) who knows the code base > > in and out, and (b) to make it more approachable for outside contributors. > > > > I think you're bringing up some other points that are also worth > > considering. To take them apart as separate questions: > > > > 1. Directory organization (which is what I've been thinking about) > > 2. Source file naming conventions > > 3. Class-per-file question (implied by #2) > > 4. Namespaces (which I've been thinking about as well) > > > > To address each of these: > > > > 1. We're in agreement here, and looking over Rhythmbox's code, I see > > parallels in what I've been pondering and how they sort things. This is > > something I would definitely like to do with Shotwell's code base. Great :) > > > > 2. I'm seeing some variations on source file names depending on the project: > > > > * Rhythmbox uses a variant of the mechanism you're speaking of (i.e. > > metadata/rb-metadata-common.c) > > * The Vala compiler uses another (ccode/valaccodecomment.vala). > > * Rygel uses Rhythmbox-style naming (ui/rygel-preferences-dialog.vala) > > * F-Spot uses the C#/Java naming style (Imaging/JpegFile.cs) > > * pitivi uses something similar, although not CamelCased > > (ui/propertyeditor.py) > > > > Note that none of these strictly follow the GTK naming convention > > (gtk/gtkbutton.c). > > > > What the above list tells me is that the jury is still out on an "official" > > naming convention, especially in terms of non-C languages, with the one > > exception that the filenames should be all lowercase (unless it's > > Mono/C#/Java). > > > > You say that when valac runs it should look like a GNOME module written in > > pure C. I'm not sure I agree with that. When you run valac in its default > > mode, it deletes the .c files after compiling and linking. In a larger > > project, yes, we keep them around to speed up compilation time (as well as > > to examine them for debugging/performance reasons), but they are not useful > > as "source" code -- no one should be editing them, and patching them > > downstream would be dangerous territory. If we're going to rethink our > > source naming convention, I feel it should be, above all else, consistent > > and intuitive for Vala coders. I don't feel our naming should be a slave to > > the .c files produced. I'm sorry I make myself very unclear at point. All I wanted to say is that from my point of view is Vala some kind of syntactic sugar to C and gobject library. I only mean to propose to stay with C+goblect conventions as much as possible and prefer them over Java/C#/Mone conventions. I agree with all statements that you have written here. > > > > If I was using Vala to produce a GObject library, then yes, that's more > > compelling. (When we produce header files for plug-ins, that would be a > > place we think about it -- I'm just not sure we want to let our yet-to-be > > coded plug-in architecture dictate filenames everywhere else.) > > > > 3. One thing that is true for GTK, Rhythmbox, Vala, and Rygel is a strict > > one-class-per-file organization. There are hundreds of classes in Shotwell, > > and I don't think putting each and every one in a separate file is doing a > > service to developers. (For example, we have 34 Command subclasses for the > > undo/redo system. Some are 13 lines long.) Maybe you are using too much classes in shotwell -- just kidding :) It's very common to create separate class for every domain of functionality in Java/C#/Mono. But it is't that common in C+GObject world. There are 3 reasons that comes to my mind: I. In C there are no classes and functionality is provided by functions organized in files according to their domain. C+GObject inherited this usage. II. Writing new class in GObject requires lots of dull work. This is not problem in Vala :) III. Maybe there are some performance issues. Allocating new class is expensive. As for your example I would create separate directory and let each class to have it's own file. To have single file for each class should not be problem if the files are well organized in directories. I do think many of our files > > have grown too large and should be broken up to keep the chunks small. > > We've done a good job keeping UI code away from implementation code, it's > > just a matter of separating the files appropriately in directories. Great -- the code reogranization should go very smooth. Maybe I would consider to prepeare some testsuits. > > Breaking up the files into smaller chunks makes a lot of sense too. > > > > 4. Namespaces are something else I'm considering -- making each subdirectory > > a namespace makes logical sense to me, and means the code reflects the > > logical organization of the source files. Plus, there's a cool Vala feature > > -- the "internal" keyword -- that we can start taking advantage of with > > well-thought-out namespacing. > > Agree on that. > > These are my thoughts today. Things are still jelling. If you (or anyone) > > would like to jump in with comments or suggestions, by all means. > > > > -- Jim > > Stanislav Nowak > > > > On Tue, Sep 28, 2010 at 6:43 AM, Stanislav Nowak wrote: > > >> >> First of all I would like to thanks you for creating this application. I >> >> was very excited when I firstly launch it. Gnome was missing feature >> >> rich photo manager for long time and I must admit that I never liked >> >> f-spot. >> >> >> >> I have some remark about source code. >> >> Although Vala's syntax is very similar to Java or C# I think that >> >> sourcefile organization should not follow Java or C# way as I felt it in >> >> your project. In my opinion when you run valac over Vala project the >> >> result should look like as gnome module written purely in c. >> >> What does it mean for Shotwell? Please separate library and application >> >> (UI) code to individual directories. For example like in Rhythmbox, they >> >> have shell directory for UI, rhytmdb for data, widgets, sources and so >> >> on. Leave one class per file. Follow gnome sourcefile name convention. >> >> This is very often in format "directory-classname". In sourcefiles use >> >> "namespace" keyword - it should save your work. For example file: >> >> >> >> \shotwelldb >> >> shotwelldb-import.vala >> >> >> >> will include: >> >> namespace Shotwelldb { >> >> class Import : ... >> >> //some code >> >> } >> >> >> >> >> >> I like the way that is used by Cannonical in their Unity project: >> >> http://bazaar.launchpad.net/~unity-team/unity/trunk/files >> >> >> >> >> >> I know it's lot of boring labor. But I think I will help shotwell to fit >> >> more in gnome environment and it should be more convenient for gnome >> >> developer. Maybe its an good idea to try push project to gnome git - at >> >> will gain more love and care :) >> >> >> >> There are only humble recommendations that I believe will help the >> >> project to grow. For me is very difficult to orient in shotwells code >> >> organization, mostly because library and application functions are mixed. >> >> >> >> I have some ideas about GUI and usability I will try to write them latter. >> >> >> >> Yours, >> >> Stanislav Nowak >> >> _______________________________________________ >> >> Shotwell mailing list >> >> Shotwell at lists.yorba.org >> >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > > From maciej.rumianowski at gmail.com Sun Oct 10 21:05:26 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Sun, 10 Oct 2010 23:05:26 +0200 Subject: [Shotwell] Publish photos to Blogger Message-ID: <1286744726.3376.27.camel@maciej-netbook> http://trac.yorba.org/ticket/2522 The idea is to publish photos directly to Blogger with as little steps as possible. It should extend actual Web Picassa publishing functionality with addition of simple text editing. It should be something like Web Picassa to Blogger. For more than one photo there should be options to specify position, alignment, composition (in a row or column). Photos are always inserted at the beginning of a post. Of course there should be a possibility to move them around while text editing. Simple text editing means: bold, italic, font color, link, quotation ? just the same way as Web Picassa does. I don't think there should be an option to edit pure HTML. More advanced editing can be done on Blogger. Photos can be published or saved as a draft in Blogger. Does someone have different view, additional thoughts? Cheers, Maciek --------------------------------------------------------------------------------------------------- Maciej Rumianowski 221203 wydzia? Elektryczny kierunek Informatyka rumianom at ee.pw.edu.pl From lucas at yorba.org Mon Oct 11 18:34:48 2010 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 11 Oct 2010 11:34:48 -0700 Subject: [Shotwell] IDE and Flickr feature In-Reply-To: <4CA0FC3C.5050704@auf.org> References: <4CA0BF79.7000401@odaeus.co.uk> <4CA0C965.9000107@yorba.org> <4CA0FC3C.5050704@auf.org> Message-ID: Hi Ndimby, Allowing users to access Flickr's organizational features (sets, groups, etc.) through the Shotwell publishing interface sounds like a reasonable suggestion, so I've ticketed it here: http://trac.yorba.org/ticket/2660. Regards, Lucas From Michael at Schievelbein.com Tue Oct 12 04:31:16 2010 From: Michael at Schievelbein.com (schievelbein) Date: Mon, 11 Oct 2010 21:31:16 -0700 (PDT) Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <4C80A4DA.4020305@nerd.fi> References: <4C80A4DA.4020305@nerd.fi> Message-ID: <1286857876070-23884.post@talk.nabble.com> So my question is; Why not do both? If you store the IPTC data in the file if format supports and then write the same data to the XMP file, you will have the speed of reading the XMP for the initial view, plus the portability of the IPTC data. If you add a 'Syncronize button, those of use that do a lot of file transferring and manipulation of tags can make sure they are in alignment on a regular basis. I am using Shotwell for genealogy photos for over 30,000 people in my database. Many of the picture have many tags and I regularly export them out to DVDs for other people to view and use. If we can get these tags all figured out and working with GRAMPS, we will have a solution that the Windows people could only dream of. -- View this message in context: http://shotwell.3510.www.nabble.com/Shotwell-Shotwell-over-NFS-shared-access-tp22144p23884.html Sent from the Shotwell mailing list archive at Nabble.com. From Michael at Schievelbein.com Tue Oct 12 04:41:49 2010 From: Michael at Schievelbein.com (schievelbein) Date: Mon, 11 Oct 2010 21:41:49 -0700 (PDT) Subject: [Shotwell] Up next: Shotwell 0.8 In-Reply-To: <4C746299.7070604@yorba.org> References: <4C746299.7070604@yorba.org> Message-ID: <1286858509832-23885.post@talk.nabble.com> Short and to the point: Thank you for all of your work on this project and keep it up. -- View this message in context: http://shotwell.3510.www.nabble.com/Shotwell-Up-next-Shotwell-0-8-tp21655p23885.html Sent from the Shotwell mailing list archive at Nabble.com. From nekohayo at gmail.com Tue Oct 12 03:16:25 2010 From: nekohayo at gmail.com (Jeff Fortin) Date: Mon, 11 Oct 2010 23:16:25 -0400 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. Message-ID: <1286853385.754.16.camel@kusanagi> Hi, I like what I'm seeing with Shotwell so far. Here's some feedback on 0.7.x if the following items weren't pointed out already: First and foremost, I think there definitely should be a way to "delete" events, or assign photos to "no event". Importing a folder of ~1000 "miscellaneous" photos collected over a year creates about 30-50 events, which is a bit ridiculous; it defeats the purpose of events matching actual events and not "days", so I'd really like a way to unassign photos from events to get a better bird-eye's view of the "important" pictures among the mess. * In other words, there are some rare times where I indeed photograph "events" (more than 20 pictures in a day; a wedding or party for example), but most of the time it's a few random shots scattered around the week. * Multiply that by 10 years, and it's too tedious to use Shotwell rather than simply using folders in Nautilus. This is the main reason currently holding me back from using Shotwell over my photo collection (~19 000 photos). Secondly, the rotation doesn't seem to save the rotation info inside the images themselves afaict, because viewing them with nautilus or eye-of-gnome afterwards, they are still in their original orientation. Third, if you merge events that span multiple months, they will incorrectly be classified as belonging to one month in particular. I'm not sure how to handle this, but I guess I wanted to report this problem nonetheless. Fourth, there should probably be a "go back" button and shortcut keys (ex: backspace/alt+left/escape) to go back to the previous view (go back from a photo to its event, from the event to the month, from the month to the year, etc.). And finally, I'd like to be able to do advanced searches on the library with various criteria (ex: "from december 2004 to march 2007" AND tags "foo", "bar" AND has "baz" in its name/event name/folder name/etc. AND rating is ==None or >=4). I'm guessing this feature was already requested and filed in the bug tracker, but I thought I'd write it in this mail just in case. Sorry that I am not filing bugs, I am allergic to Trac. (please reply-to-all so I can be c.c.'ed) From jim at yorba.org Tue Oct 12 19:06:32 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 12 Oct 2010 12:06:32 -0700 Subject: [Shotwell] Shotwell over NFS + shared access In-Reply-To: <1286857876070-23884.post@talk.nabble.com> References: <4C80A4DA.4020305@nerd.fi> <1286857876070-23884.post@talk.nabble.com> Message-ID: What you're describing is a distinct possibility. If we were to move to storing metadata in a sidecar file, you're right, there's nothing saying we couldn't store the metadata (all or a subset of it) in the master file as well. -- Jim On Mon, Oct 11, 2010 at 9:31 PM, schievelbein wrote: > > So my question is; Why not do both? > If you store the IPTC data in the file if format supports and then write > the > same data to the XMP file, you will have the speed of reading the XMP for > the initial view, plus the portability of the IPTC data. If you add a > 'Syncronize button, those of use that do a lot of file transferring and > manipulation of tags can make sure they are in alignment on a regular > basis. > > I am using Shotwell for genealogy photos for over 30,000 people in my > database. Many of the picture have many tags and I regularly export them > out to DVDs for other people to view and use. If we can get these tags all > figured out and working with GRAMPS, we will have a solution that the > Windows people could only dream of. > -- > View this message in context: > http://shotwell.3510.www.nabble.com/Shotwell-Shotwell-over-NFS-shared-access-tp22144p23884.html > Sent from the Shotwell mailing list archive at Nabble.com. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue Oct 12 19:26:37 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 12 Oct 2010 12:26:37 -0700 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: <1286853385.754.16.camel@kusanagi> References: <1286853385.754.16.camel@kusanagi> Message-ID: Hello! Hi, I like what I'm seeing with Shotwell so far. > Good to hear. > > First and foremost, I think there definitely should be a way to "delete" > events, or assign photos to "no event". Importing a folder of ~1000 > "miscellaneous" photos collected over a year creates about 30-50 events, > which is a bit ridiculous; it defeats the purpose of events matching > actual events and not "days", so I'd really like a way to unassign > photos from events to get a better bird-eye's view of the "important" > pictures among the mess. > This has been ticketed: http://trac.yorba.org/ticket/2665 > * Multiply that by 10 years, and it's too tedious to use Shotwell rather > than simply using folders in Nautilus. This is the main reason currently > holding me back from using Shotwell over my photo collection (~19 000 > photos). > > One thing that has been requested in the past several times is for Shotwell to display photos organized by their location on disk: http://trac.yorba.org/ticket/1594 > Secondly, the rotation doesn't seem to save the rotation info inside the > images themselves afaict, because viewing them with nautilus or > eye-of-gnome afterwards, they are still in their original orientation. > > Shotwell is a non-destructive editor. Rotation, color enhancement, cropping, etc. are all stored in its database and applied on-the-fly to the photo. This has certain advantages over destructive or generational editing. If you want to have a photo that's been transformed, you need to export it. But we are considering saving the rotation directly to the master: http://trac.yorba.org/ticket/2330 Also note that some photo apps don't respect the orientation EXIF field, which is how Shotwell (and many other apps) perform rotations. Thus, even if you do export the file, those apps will still display it incorrectly. (One example is the GNOME desktop image.) This ticket summarizes where Shotwell and these other apps stand today: http://trac.yorba.org/ticket/2581 However, some people would like for Shotwell to store all their transformations on disk. This is something we're considering for a future release: http://trac.yorba.org/ticket/1798 > Third, if you merge events that span multiple months, they will > incorrectly be classified as belonging to one month in particular. I'm > not sure how to handle this, but I guess I wanted to report this problem > nonetheless. > > Events are classified by the earliest photo in the event. We had to pick one (we didn't want to show the same event in multiple locations on the tree). > Fourth, there should probably be a "go back" button and shortcut keys > (ex: backspace/alt+left/escape) to go back to the previous view (go back > from a photo to its event, from the event to the month, from the month > to the year, etc.). > > We do already have some notion of "go back" when you're viewing a photo. If you press Escape, you'll go to the view you were in when you double-clicked the image. Are you suggesting something beyond this? > And finally, I'd like to be able to do advanced searches on the library > with various criteria (ex: "from december 2004 to march 2007" AND tags > "foo", "bar" AND has "baz" in its name/event name/folder name/etc. AND > rating is ==None or >=4). I'm guessing this feature was already > requested and filed in the bug tracker, but I thought I'd write it in > this mail just in case. > This is definitely something we've heard a lot of requests for: http://trac.yorba.org/ticket/1587 Thanks for your ideas. Please feel free to keep airing them here! -- Jim From maciej.rumianowski at gmail.com Tue Oct 12 19:59:50 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Tue, 12 Oct 2010 21:59:50 +0200 Subject: [Shotwell] XML-RPC and Wordpress Message-ID: <1286913590.1945.91.camel@maciej-netbook> Hi all, Has Shotwell any support for xml-rpc? I have found that publishing to Wordpress is done differently from Blogger. REST support is provided only by Third-party plugins. So if I want to add Wordpress support do I have to add xml-rpc to Shotwell? Cheers, Maciek From jim at yorba.org Tue Oct 12 20:12:51 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 12 Oct 2010 13:12:51 -0700 Subject: [Shotwell] XML-RPC and Wordpress In-Reply-To: <1286913590.1945.91.camel@maciej-netbook> References: <1286913590.1945.91.camel@maciej-netbook> Message-ID: We currently don't have any publishing modules that use XML-RPC. If you wanted to publish directly to Wordpress, that would need to be made available. There is probably a library out there (perhaps many) that can do this. I believe libsoup has some support built-in as well. That would be the way to do (rather than write your own routines in Vala). If you're serious about moving forward on this, I recommend reading http://trac.yorba.org/wiki/ShotwellArchitectureOverview (especially http://trac.yorba.org/wiki/ShotwellArchPhotoPublishing) and adding a ticket for this to our Trac server at http://trac.yorba.org so we can track progress. Thanks! -- Jim On Tue, Oct 12, 2010 at 12:59 PM, Maciej Rumianowski < maciej.rumianowski at gmail.com> wrote: > Hi all, > > Has Shotwell any support for xml-rpc? > I have found that publishing to Wordpress is done differently from > Blogger. REST support is provided only by Third-party plugins. > > So if I want to add Wordpress support do I have to add xml-rpc to > Shotwell? > > Cheers, > Maciek > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Tue Oct 12 20:12:50 2010 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 12 Oct 2010 13:12:50 -0700 Subject: [Shotwell] XML-RPC and Wordpress In-Reply-To: <1286913590.1945.91.camel@maciej-netbook> References: <1286913590.1945.91.camel@maciej-netbook> Message-ID: Hi Maciek, The entire Shotwell publishing subsystem is built around REST. The pre-defined transaction objects for probing endpoints, transporting multi-part encoded binary data, delivering structured information, etc., all assume a REST endpoint. So if you wanted to add Wordpress support, well, you'd have to re-write much of the Shotwell publishing subsystem so that it also supported XML-RPC. This isn't an easy task, but it's not impossible either. However, because it would involve a substantial amount of design work, we at Yorba would have to be deeply involved from the beginning. With that in mind, I don't think we have the time and resources to do this for Shotwell 0.8. That said, this may be possible for Shotwell 0.9 or later. Cheers, Lucas From ingo.steiner at gmx.net Tue Oct 12 20:20:38 2010 From: ingo.steiner at gmx.net (Ingo Steiner) Date: Tue, 12 Oct 2010 22:20:38 +0200 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: References: <1286853385.754.16.camel@kusanagi> Message-ID: <4CB4C316.4060805@gmx.net> On 12.10.2010 21:26, Jim Nelson wrote: > Hello! > > Hi, I like what I'm seeing with Shotwell so far. My congratulations as well, have immediately scrapped f-spot - THANKS! >> First and foremost, I think there definitely should be a way to "delete" >> events, or assign photos to "no event". Importing a folder of ~1000 >> "miscellaneous" photos collected over a year creates about 30-50 events, >> which is a bit ridiculous; it defeats the purpose of events matching >> actual events and not "days", so I'd really like a way to unassign >> photos from events to get a better bird-eye's view of the "important" >> pictures among the mess. >> A quick and easy way to achieve that could be an option to import photos into a special event i.e. named "incoming". From there you could move/distibute them into the events according to your preferences. What about that? > One thing that has been requested in the past several times is for Shotwell > to display photos organized by their location on disk: > http://trac.yorba.org/ticket/1594 That gets my vote too, shoud be a selectable option! -- ____________________________________________________________________ In a world without walls and fences we don't need windows and gates. From maciej.rumianowski at gmail.com Tue Oct 12 20:29:24 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Tue, 12 Oct 2010 22:29:24 +0200 Subject: [Shotwell] XML-RPC and Wordpress In-Reply-To: References: <1286913590.1945.91.camel@maciej-netbook> Message-ID: <1286915364.1945.107.camel@maciej-netbook> Hi Lucas, Currently I am working on Blogger support as my project on University. My promoter expressed some doubts about the amount of work the Blogger functionality involves. I am looking for something to add. There is no pressure to include it in 0.8 version. My project have to end in one Semester, but I would like to work longer:) I will create tickets for it as Jim proposed. Cheers, Maciek Dnia 2010-10-12, wto o godzinie 13:12 -0700, Lucas Beeler pisze: > Hi Maciek, > > The entire Shotwell publishing subsystem is built around REST. The > pre-defined transaction objects for probing endpoints, transporting > multi-part encoded binary data, delivering structured information, > etc., all assume a REST endpoint. So if you wanted to add Wordpress > support, well, you'd have to re-write much of the Shotwell publishing > subsystem so that it also supported XML-RPC. This isn't an easy task, > but it's not impossible either. However, because it would involve a > substantial amount of design work, we at Yorba would have to be deeply > involved from the beginning. With that in mind, I don't think we have > the time and resources to do this for Shotwell 0.8. That said, this > may be possible for Shotwell 0.9 or later. > > Cheers, > Lucas From hendry.michael at gmail.com Tue Oct 12 20:36:46 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Tue, 12 Oct 2010 21:36:46 +0100 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates Message-ID: <1286915806.1707.55.camel@Linley6> I've imported my archive of images, which includes many scanned 35mm negatives, which are stored by number (IMG001.jpg, IMG002.jpg etc) in subdirectories which identify the order in which the films were processed (1960-01, 1960-02 etc). Shotwell couldn't identify the dates for these images which it could use in attaching them to events, so they ended up in a poorly ordered jumble. I decided to adjust the EXIF data for the files in each directory by writing a shell script containing lines like: ... exiftool -DateTimeOriginal="1960:01:01 12:00:00" IMG000.jpg exiftool -DateTimeOriginal="1960:01:01 12:00:01" IMG001.jpg exiftool -DateTimeOriginal="1960:01:01 12:00:02" IMG002.jpg ... which is for the directory 1960-01, and makes it look as though the images were taken a second apart on the 1st Jan 1960, starting at noon. "1960:01:02" is used for directory 1960-2, and so on. Once I'd done this, all I had to do was Import the directories again? WRONG! Shotwell thinks the adjusted files are duplicates, and declines to import them, so it is necessary to identify the images in the general "Photos" view, and move them to the Wastebasket. All I had to do now was Import the directories again? WRONG AGAIN! All the images that I'd put in the Wastebasket were restored, and my images with the adjusted EXIF data were ignored again. To resolve this, it was necessary to find all the relevant images in the Photo view - which is not straightforward unless they happen to be contiguous - select them all, move them to the Wastebasket AND empty the Wastebasket before I could import the adjusted images and have them put together as events. There are a number of points here: 1. There are perfectly good reasons which I might like to have two or more absolutely identical images in different directories, and to be able to track them using Shotwell - for example I might have a working directory which starts off as an exact copy of an archive directory which I plan to leave untouched. Why doesn't Shotwell recognise this as an option? 2. In my view, a Wastebasket image has already been flagged as "unwanted", so when I choose to Import a duplicate (in Shotwell's terms) its information should overwrite the original. In any case, the original image file no longer exists once I've changed its EXIF data, so Shotwell should accept the changed image as the definitive one. 3. When an attempt is made to Import an image which appears to be identical to one already in Shotwell's database, the option of overwriting the original entry should be offered, as should the option of creating a new entry. 4. I'd like to be able to see that I have several versions of the same file in a directory, even though they might appear to be identical to Shotwell. I might, for example, keep 800x600 and 1024x768 versions of the same image and have them separately tagged for different export jobs. Now that I've slogged through the task of adding the dates and times to my old images, I'm finding the ease of browsing in Shotwell has allowed me to rediscover some buried treasures - please accept my comments as suggestions for making an already brilliant product even better! Michael From Sebastian at SSpaeth.de Wed Oct 13 07:05:51 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Wed, 13 Oct 2010 09:05:51 +0200 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: <4CB4C316.4060805@gmx.net> References: <1286853385.754.16.camel@kusanagi> <4CB4C316.4060805@gmx.net> Message-ID: <87y6a21sj4.fsf@SSpaeth.de> > A quick and easy way to achieve that could be an option to import photos > into a special event i.e. named "incoming". From there you could > move/distibute them into the events according to your preferences. > What about that? NOOOOOOOO :-) I agree that the day-based events are a bit fine grained sometimes, but it is easier to merge multiple events (it is trivial to be exact) rather than to fish out correct photos out of one mega-event (err, did I take that tree picture in Rome or Barcelona again? :-)) What would be sensible is to have an option that creates one event per import, a "film roll" as some programs call it, I believe. But other than than I am happy with the way it is. If you know that you were in Barcelona from Nov 10-Nov 30, just select those 20 events and click on merge. Done. I agree that folder-based events would also make sense for those of us who come from the old world of folder-based organization :-). So either per: date, import, or folder, but not a mega-incoming event please :). Thanks, Sebastian From Sebastian at SSpaeth.de Wed Oct 13 07:33:47 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Wed, 13 Oct 2010 09:33:47 +0200 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: <1286915806.1707.55.camel@Linley6> References: <1286915806.1707.55.camel@Linley6> Message-ID: <87sk0a1r8k.fsf@SSpaeth.de> Discplaimer: Nnote that I am related to shotwell development. > Shotwell thinks the adjusted files are duplicates, and declines to > import them, so it is necessary to identify the images in the general > "Photos" view, and move them to the Wastebasket. > > All I had to do now was Import the directories again? > WRONG AGAIN! Preventing duplicates is one of the beauties of shotwell for me. I often run an import from a camera sd card twice without deleting the pictures inbetween, I often import from a network share where my wife has put new photos in various locations, etc. I were lost if not for the duplicate detection :-). > All the images that I'd put in the Wastebasket were restored, and my > images with the adjusted EXIF data were ignored again. I would consider the first one a bug, if I put it in the trash (mostly unsharp and crappy pictures) I don't want them restored on repeated imports. (they are still crappy :-)) > To resolve this, it was necessary to find all the relevant images in the > Photo view - which is not straightforward unless they happen to be > contiguous - select them all, move them to the Wastebasket AND empty the > Wastebasket before I could import the adjusted images and have them put > together as events. What you could do is to delete the underlying files and they would be shown as missing on the next start which allows you to easily throw them in the trash. > 1. There are perfectly good reasons which I might like to have two or > more absolutely identical images in different directories, and to be > able to track them using Shotwell - for example I might have a working > directory which starts off as an exact copy of an archive directory > which I plan to leave untouched. Why doesn't Shotwell recognise this as > an option? Because in the easy and common case users don't want duplicates? :-) And there are only a handful of shotwell developers that can't cater for the more complex cases from the very beginning? Shotwell is still a young app. > 2. In my view, a Wastebasket image has already been flagged as > "unwanted", so when I choose to Import a duplicate (in Shotwell's terms) > its information should overwrite the original. I disagree, in my usecase once I've thrown a picture in the wastebasket, I don't want it to be reimported. ooh, "zombie photos" otherwise :). > 3. When an attempt is made to Import an image which appears to be > identical to one already in Shotwell's database, the option of > overwriting the original entry should be offered, as should the option > of creating a new entry. That might be an option but it should have the possibility to set permanent defaults. I don't want to click through 9k of photos again and again, saying that I really don't want to reimport them every time... > 4. I'd like to be able to see that I have several versions of the same > file in a directory, even though they might appear to be identical to > Shotwell. I might, for example, keep 800x600 and 1024x768 versions of > the same image and have them separately tagged for different export > jobs. If they have different resolution, they are (for shotwell) different images as the files differ, so that should already be possible. The problem I see is that people have very different use cases and work flows and catering for all these is impossible without creating a whole slur of complex user options (which is against the shotwell philosophy). So what might seem as stupidity and neglect to you, might be the main feature and advantage to me :). Sebastian From hendry.michael at gmail.com Wed Oct 13 09:13:37 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 13 Oct 2010 10:13:37 +0100 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: <87sk0a1r8k.fsf@SSpaeth.de> References: <1286915806.1707.55.camel@Linley6> <87sk0a1r8k.fsf@SSpaeth.de> Message-ID: <1286961217.1711.30.camel@Linley6> On Wed, 2010-10-13 at 09:33 +0200, Sebastian Spaeth wrote: > Discplaimer: Nnote that I am related to shotwell development. > > > Shotwell thinks the adjusted files are duplicates, and declines to > > import them, so it is necessary to identify the images in the general > > "Photos" view, and move them to the Wastebasket. > > > > All I had to do now was Import the directories again? > > WRONG AGAIN! > > Preventing duplicates is one of the beauties of shotwell for me. I often > run an import from a camera sd card twice without deleting the pictures > inbetween, I often import from a network share where my wife has put new > photos in various locations, etc. I were lost if not for the duplicate > detection :-). > So the rest of us have to suffer because of your carelessness? At the very least, there should be a warning of the duplicates, and an option to go ahead anyway, with a configuration option to ban all duplicates. > > All the images that I'd put in the Wastebasket were restored, and my > > images with the adjusted EXIF data were ignored again. > > I would consider the first one a bug, if I put it in the trash (mostly > unsharp and crappy pictures) I don't want them restored on repeated > imports. (they are still crappy :-)) Glad we can agree about something! > > > To resolve this, it was necessary to find all the relevant images in the > > Photo view - which is not straightforward unless they happen to be > > contiguous - select them all, move them to the Wastebasket AND empty the > > Wastebasket before I could import the adjusted images and have them put > > together as events. > > What you could do is to delete the underlying files and they would be > shown as missing on the next start which allows you to easily throw them > in the trash. But I want to keep the underlying files, with their EXIF data changed. I agree that this would be a reliable way of ensuring the removal of the dud information, using the sequence: 1. Open the relevant directory in the file manager. 2. Send its contents to the "Deleted Items" folder. 3. Close Shotwell. 4. Open Shotwell. 5. Wait for Shotwell to scan through and discover that files are missing. 6. Authorise their deletion from Shotwell. 7. Restore the directory's contents from the "Deleted Items" folder. 8. Make the adjustments to the EXIF data. 9. Import the folder using Shotwell. It's a bit of a long way round. > > > 1. There are perfectly good reasons which I might like to have two or > > more absolutely identical images in different directories, and to be > > able to track them using Shotwell - for example I might have a working > > directory which starts off as an exact copy of an archive directory > > which I plan to leave untouched. Why doesn't Shotwell recognise this as > > an option? > > Because in the easy and common case users don't want duplicates? :-) And > there are only a handful of shotwell developers that can't cater for the > more complex cases from the very beginning? Shotwell is still a young > app. > > > 2. In my view, a Wastebasket image has already been flagged as > > "unwanted", so when I choose to Import a duplicate (in Shotwell's terms) > > its information should overwrite the original. > > I disagree, in my usecase once I've thrown a picture in the wastebasket, > I don't want it to be reimported. ooh, "zombie photos" otherwise :). > You agreed (above) that restoring information from the Wastebasket is the wrong thing to do when an attempt to import apparently identical images is made. Are you suggesting that once you've emptied the Wastebasket Shotwell should "remember" that you've got rid of an image and never want it imported again? > > 3. When an attempt is made to Import an image which appears to be > > identical to one already in Shotwell's database, the option of > > overwriting the original entry should be offered, as should the option > > of creating a new entry. > > That might be an option but it should have the possibility to set > permanent defaults. I don't want to click through 9k of photos again and > again, saying that I really don't want to reimport them every time... Agreed, or a warning about duplicates and a set of "Yes...Yes to all...No...No to all" import options would sort that. > > > 4. I'd like to be able to see that I have several versions of the same > > file in a directory, even though they might appear to be identical to > > Shotwell. I might, for example, keep 800x600 and 1024x768 versions of > > the same image and have them separately tagged for different export > > jobs. > > If they have different resolution, they are (for shotwell) different > images as the files differ, so that should already be possible. Doesn't work for me - I think it's because the thumbnails are identical, and the test for "identicality" doesn't take file-size or EXIF data into consideration. > > The problem I see is that people have very different use cases and work > flows and catering for all these is impossible without creating a whole > slur of complex user options (which is against the shotwell > philosophy). So what might seem as stupidity and neglect to you, might > be the main feature and advantage to me :). > Ah, we're getting into the everlasting battle between Philosophy and Pragmatism here! Michael From toroklev at gmail.com Wed Oct 13 09:43:38 2010 From: toroklev at gmail.com (Levente Torok) Date: Wed, 13 Oct 2010 11:43:38 +0200 Subject: [Shotwell] feature request: title just like in picasa Message-ID: Hi Guys again, I'd like to know if titles can be displayed in full screen mode (just like in picasa). I am also missing a possibility to edit it as easy as in picasa (one-by-one). Or am I trying to use this tool in a way that is not its own? Cheers, Lev From Sebastian at SSpaeth.de Wed Oct 13 12:06:17 2010 From: Sebastian at SSpaeth.de (Sebastian Spaeth) Date: Wed, 13 Oct 2010 14:06:17 +0200 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: <1286961217.1711.30.camel@Linley6> References: <1286915806.1707.55.camel@Linley6> <87sk0a1r8k.fsf@SSpaeth.de> <1286961217.1711.30.camel@Linley6> Message-ID: <87fwwaqoue.fsf@SSpaeth.de> On 2010-10-13, Michael Hendry wrote: > > Preventing duplicates is one of the beauties of shotwell for me. I often > > run an import from a camera sd card twice without deleting the pictures > > inbetween, I often import from a network share where my wife has put new > > photos in various locations, etc. I were lost if not for the duplicate > > detection :-). > So the rest of us have to suffer because of your carelessness? It's not carelessness, it's my workflow. I reimport the same directory over and over again, with at least 2 persons adding pictures to various locations. > At the very least, there should be a warning of the duplicates, and an > option to go ahead anyway, with a configuration option to ban all > duplicates. Yep, it seems that would satisfy everyone. > > I disagree, in my usecase once I've thrown a picture in the wastebasket, > > I don't want it to be reimported. ooh, "zombie photos" otherwise :). > You agreed (above) that restoring information from the Wastebasket is > the wrong thing to do when an attempt to import apparently identical > images is made. Are you suggesting that once you've emptied the > Wastebasket Shotwell should "remember" that you've got rid of an image > and never want it imported again? Yes, that is what I think. Once discarded, it should not be reimported (without a warning). Agreed, or a warning about duplicates and a set of "Yes...Yes to > all...No...No to all" import options would sort that. /me nods. > > If they have different resolution, they are (for shotwell) different > > images as the files differ, so that should already be possible. > > Doesn't work for me - I think it's because the thumbnails are identical, > and the test for "identicality" doesn't take file-size or EXIF data into > consideration. Uhh, last I looked at the database, it was taking the md5 of the photo file for duplicate identification. So if the EXIF data is different (or the file size), it should be possible to import duplicates. I defer to those more knowledgeable of the code base though. Sebastian From hendry.michael at gmail.com Wed Oct 13 13:17:46 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Wed, 13 Oct 2010 14:17:46 +0100 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: <87fwwaqoue.fsf@SSpaeth.de> References: <1286915806.1707.55.camel@Linley6> <87sk0a1r8k.fsf@SSpaeth.de> <1286961217.1711.30.camel@Linley6> <87fwwaqoue.fsf@SSpaeth.de> Message-ID: <1286975866.1711.41.camel@Linley6> On Wed, 2010-10-13 at 14:06 +0200, Sebastian Spaeth wrote: > On 2010-10-13, Michael Hendry wrote: > > > Preventing duplicates is one of the beauties of shotwell for me. I often > > > run an import from a camera sd card twice without deleting the pictures > > > inbetween, I often import from a network share where my wife has put new > > > photos in various locations, etc. I were lost if not for the duplicate > > > detection :-). > > > So the rest of us have to suffer because of your carelessness? > > It's not carelessness, it's my workflow. I reimport the same directory > over and over again, with at least 2 persons adding pictures to various > locations. OK - point taken! > > > At the very least, there should be a warning of the duplicates, and an > > option to go ahead anyway, with a configuration option to ban all > > duplicates. > > Yep, it seems that would satisfy everyone. > > > > I disagree, in my usecase once I've thrown a picture in the wastebasket, > > > I don't want it to be reimported. ooh, "zombie photos" otherwise :). > > > You agreed (above) that restoring information from the Wastebasket is > > the wrong thing to do when an attempt to import apparently identical > > images is made. Are you suggesting that once you've emptied the > > Wastebasket Shotwell should "remember" that you've got rid of an image > > and never want it imported again? > > Yes, that is what I think. Once discarded, it should not be reimported > (without a warning). > > Agreed, or a warning about duplicates and a set of "Yes...Yes to > > all...No...No to all" import options would sort that. > > /me nods. > > > > If they have different resolution, they are (for shotwell) different > > > images as the files differ, so that should already be possible. > > > > Doesn't work for me - I think it's because the thumbnails are identical, > > and the test for "identicality" doesn't take file-size or EXIF data into > > consideration. > > Uhh, last I looked at the database, it was taking the md5 of the photo > file for duplicate identification. So if the EXIF data is different (or > the file size), it should be possible to import duplicates. I defer to > those more knowledgeable of the code base though. In https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/644125 #4 Jim Nelson confirms that 0.7.x won't pick up the change in EXIF data. I've also come across the situation where one file twice the size of another was regarded as a duplicate. Michael From jim at yorba.org Wed Oct 13 16:48:18 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 13 Oct 2010 09:48:18 -0700 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: References: Message-ID: Hello, On Wed, Oct 13, 2010 at 2:43 AM, Levente Torok wrote: > Hi Guys again, > > I'd like to know if titles can be displayed in full screen mode (just > like in picasa). > > This is something we're considering: http://trac.yorba.org/ticket/2238 > I am also missing a possibility to edit it as easy as in picasa > (one-by-one). > Or am I trying to use this tool in a way that is not its own? > Cheers, > I'm not sure what you mean by this. Do you mean edit the image (crop, rotate, etc.) or edit its title, tags, etc.? -- Jim From jim at yorba.org Wed Oct 13 17:02:18 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 13 Oct 2010 10:02:18 -0700 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: <87y6a21sj4.fsf@SSpaeth.de> References: <1286853385.754.16.camel@kusanagi> <4CB4C316.4060805@gmx.net> <87y6a21sj4.fsf@SSpaeth.de> Message-ID: For what it's worth, Shotwell 0.7 introduced a Last Import page which shows exactly what it sounds like -- everything last imported. At some point I would like to add the ability to browse all import rolls ( http://trac.yorba.org/ticket/1793). -- Jim On Wed, Oct 13, 2010 at 12:05 AM, Sebastian Spaeth wrote: > > A quick and easy way to achieve that could be an option to import photos > > into a special event i.e. named "incoming". From there you could > > move/distibute them into the events according to your preferences. > > What about that? > > NOOOOOOOO :-) > > I agree that the day-based events are a bit fine grained sometimes, but > it is easier to merge multiple events (it is trivial to be exact) rather > than to fish out correct photos out of one mega-event (err, did I take > that tree picture in Rome or Barcelona again? :-)) > > What would be sensible is to have an option that creates one event per > import, a "film roll" as some programs call it, I believe. But other > than than I am happy with the way it is. If you know that you were in > Barcelona from Nov 10-Nov 30, just select those 20 events and click on > merge. Done. > > I agree that folder-based events would also make sense for those of us > who come from the old world of folder-based organization :-). > > So either per: date, import, or folder, but not a mega-incoming event > please :). > > Thanks, > Sebastian > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Wed Oct 13 17:06:16 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 13 Oct 2010 10:06:16 -0700 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: References: Message-ID: <4CB5E708.30303@yorba.org> On 10/13/2010 09:48 AM, Jim Nelson wrote: > Hello, > > On Wed, Oct 13, 2010 at 2:43 AM, Levente Torok wrote: > >> Hi Guys again, >> >> I'd like to know if titles can be displayed in full screen mode (just >> like in picasa). >> >> > This is something we're considering: http://trac.yorba.org/ticket/2238 > > >> I am also missing a possibility to edit it as easy as in picasa >> (one-by-one). >> Or am I trying to use this tool in a way that is not its own? >> Cheers, >> > I'm not sure what you mean by this. Do you mean edit the image (crop, > rotate, etc.) or edit its title, tags, etc.? I believe that Levente was asking to be able to edit the caption in full-screen mode, just like in Picasa. That's a reasonable idea and I've added a comment reflecting that to the ticket above. adam From toroklev at gmail.com Wed Oct 13 20:09:18 2010 From: toroklev at gmail.com (Levente Torok) Date: Wed, 13 Oct 2010 22:09:18 +0200 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: <4CB5E708.30303@yorba.org> References: <4CB5E708.30303@yorba.org> Message-ID: Hi Adam and Jim and the list, Thanks guys for considering my opinion. This would be a very nice thing however what bothers me is that I have to right click on every image and select the function "title editing" (or so). Whenever I am in the process of writing titles I am concentrating on the story on the images and it is very much bothering that I have to repeat these extra clicks all the time instead of being able to write the titles as a sequence. Indeed, picasa is not very optimal either, since it requires an extra click under every image but it is probably the least that we can expect from a user. On the other hand, being able to edit titles in full screen mode would be a super cool thing but I would consider full screen operations only as a secondary thing, since most users think of it as a "display only" thing, it is meant to be a monitor for the end product, the slide show. So what I am proposing is first to be able to access caption editing faster then it is now, plus, if a user presses PgDn - PgUp in the editing mode, focus moves to the next next - previous image caption. What do you think? ps: did my former mail on sorting reached the list? In that I wrote that I would be very very happy to meet an image viewer in which I can order images just like in picasa (arbitrarily moving back and forth) and be able to export to picasa web storage with that order and captions and keep it in sync in both ways (upstream and downstream). I would want to completely replace picasa with an alternative because of its annoying bugs and hidden behaviour. Levente On Wed, Oct 13, 2010 at 7:06 PM, Adam Dingle wrote: > ?On 10/13/2010 09:48 AM, Jim Nelson wrote: >> Hello, >> >> On Wed, Oct 13, 2010 at 2:43 AM, Levente Torok ?wrote: >> >>> Hi Guys again, >>> >>> I'd like to know if titles can be displayed in full screen mode (just >>> like in picasa). >>> >>> >> This is something we're considering: http://trac.yorba.org/ticket/2238 >> >> >>> I am also missing a possibility to edit it as easy as in picasa >>> (one-by-one). >>> Or am I trying to use this tool in a way that is not its own? >>> Cheers, >>> >> I'm not sure what you mean by this. ?Do you mean edit the image (crop, >> rotate, etc.) or edit its title, tags, etc.? > > I believe that Levente was asking to be able to edit the caption in > full-screen mode, just like in Picasa. ?That's a reasonable idea and > I've added a comment reflecting that to the ticket above. > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Oct 13 22:00:57 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 13 Oct 2010 15:00:57 -0700 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: References: <4CB5E708.30303@yorba.org> Message-ID: On Wed, Oct 13, 2010 at 1:09 PM, Levente Torok wrote: > > On the other hand, being able to edit titles in full screen mode would > be a super cool thing but I would consider full screen operations only > as a secondary thing, since most users think of it as a "display only" > thing, it is meant to be a monitor for the end product, the slide > show. So what I am proposing is first to be able to access caption > editing faster then it is now, > plus, if a user presses PgDn - PgUp in the editing mode, focus moves > to the next next - previous image caption. > > What do you think? > I think this makes sense -- you're making a point about workflow, which is something we've been thinking about here. I see the problem you're describing, but do you have a design in mind? Would you want to be able to simply click on the title and edit it in-place? I understand wanting to minimize mouse clicks and/or keystrokes, but it seems that there needs to be at least one action to activate title editing. > ps: did my former mail on sorting reached the list? In that I wrote that > I would be very very happy to meet an image viewer in which I can > order images just like in picasa (arbitrarily moving back and forth) > and be able to export to picasa web storage with that order and > captions and keep it in sync in both ways (upstream and downstream). > The email did not make it through the list and it don't see it in the pending queue. Can you re-send? I've created a new ticket for what you're asking, but in a more general sense (all Web services, not merely PicasaWeb). We have been discussing this for a while, but it doesn't look like it was ticketed properly. Thanks, -- Jim From mahfiaz at gmail.com Wed Oct 13 22:19:03 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Thu, 14 Oct 2010 01:19:03 +0300 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: References: <4CB5E708.30303@yorba.org> Message-ID: <1287008343.2105.6.camel@antiloop> ?hel kenal p?eval, K, 2010-10-13 kell 15:00, kirjutas Jim Nelson: > > I think this makes sense -- you're making a point about workflow, > which is something we've been thinking about here. I see the problem > you're describing, but do you have a design in mind? Would you want > to be able to simply click on the title and edit it in-place? I > understand wanting to minimize mouse clicks and/or keystrokes, but it > seems that there needs to be at least one action to activate title > editing. I think there should be three possibilities: 1. Clicking on the title (should it select all or not?) 2. Pressing a shortcut like Ctrl+T or simply t 3. Title bar could end with a little tick "Batch Title mode", in which Page Up/Down and Enter would change pictures and title would always be active for directly typing. Mattias From nero at in-design.com Thu Oct 14 15:02:25 2010 From: nero at in-design.com (nero) Date: Thu, 14 Oct 2010 11:02:25 -0400 Subject: [Shotwell] Problems compiling on new installation of Fedora 13 Message-ID: <4CB71B81.6050507@in-design.com> Linux nero.in-design.com 2.6.34.7-56.fc13.i686 #1 SMP Wed Sep 15 03:33:58 UTC 2010 i686 i686 i386 GNU/Linux l-0.7.2 # make mkdir -p src /usr/bin/valac --ccode --directory=src --basedir=src -g --enable-checking --thread \ --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 --pkg=glib-2.0 --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 --pkg=gconf-2.0 --pkg=libgphoto2 --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 --pkg=gdk-x11-2.0 --pkg=FixedKeyFile --pkg=ExtendedPosix --pkg=posix --pkg=LConv --pkg=gdk-none --pkg=libraw \ --vapidir=./vapi \ -X -D_PREFIX='"/usr/local"' -X -D_VERSION='"0.7.2"' -X -DGETTEXT_PACKAGE='"shotwell"' -X -D_LANG_SUPPORT_DIR='"/usr/local/share/locale"' \ -X -I./vapi \ \ src/main.vala src/AppWindow.vala src/CollectionPage.vala src/Thumbnail.vala src/DatabaseTables.vala src/ThumbnailCache.vala src/image_util.vala src/CheckerboardLayout.vala src/PhotoPage.vala src/Page.vala src/ImportPage.vala src/GPhoto.vala src/SortedList.vala src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala src/Photo.vala src/Orientation.vala src/util.vala src/BatchImport.vala src/Dialogs.vala src/Resources.vala src/Debug.vala src/Sidebar.vala src/ColorTransformation.vala src/EditingTools.vala src/DataObject.vala src/DataCollection.vala src/LibraryWindow.vala src/CameraTable.vala src/DirectWindow.vala src/Properties.vala src/CustomComponents.vala src/Config.vala src/Event.vala src/International.vala src/Workers.vala src/system.vala src/AppDirs.vala src/PixbufCache.vala src/WebConnectors.vala src/FacebookConnector.vala src/CommandManager.vala src/Commands.vala src/SlideshowPage.vala src/LibraryFiles.vala src/FlickrConnector.vala src/Printing.vala src/Tag.vala src/TagPage.vala src/PicasaConnector.vala src/Screensaver.vala src/PhotoFileAdapter.vala src/PhotoFileFormat.vala src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala src/PhotoExporter.vala src/DirectoryMonitor.vala src/LibraryMonitor.vala src/OfflinePage.vala src/LastImportPage.vala src/AlienDatabase.vala src/AlienDatabaseImportJob.vala src/AlienDatabaseImportDialog.vala src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala CollectionPage.vala:1747.9-1764.66: error: missing break statement at end of switch section CollectionPage.vala:1746.5-1746.42: error: missing return statement at end of method or lambda body private Comparator get_sort_comparator() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CollectionPage.vala:1772.9-1780.61: error: missing break statement at end of switch section CollectionPage.vala:1771.5-1771.61: error: missing return statement at end of method or lambda body private ComparatorPredicate get_sort_comparator_predicate() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CollectionPage.vala:1822.9-1831.22: error: missing break statement at end of switch section DatabaseTables.vala:1267.5-1267.80: error: missing return statement at end of method or lambda body public static Gee.HashMap? marshall_all_transformations(string? trans) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ThumbnailCache.vala:214.9-219.30: error: missing break statement at end of switch section ThumbnailCache.vala:213.5-213.47: error: missing return statement at end of method or lambda body private static ThumbnailCache get_cache_for(Size size) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CheckerboardLayout.vala:966.9-997.18: error: missing break statement at end of switch section ImportPage.vala:560.5-560.58: error: missing return statement at end of method or lambda body public override CheckerboardItem? get_fullscreen_photo() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ImportPage.vala:578.9-639.18: error: missing break statement at end of switch section Dimensions.vala:222.9-233.51: error: missing break statement at end of switch section Dimensions.vala:221.5-221.46: error: missing return statement at end of method or lambda body public Dimensions get_scaled_by_constraint(int scale, ScaleConstraint constraint) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Photo.vala:505.9-513.43: error: missing break statement at end of switch section Photo.vala:504.5-504.46: error: missing return statement at end of method or lambda body private PhotoFileReader get_backing_reader(BackingFetchMode mode) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:51.9-74.32: error: missing break statement at end of switch section Orientation.vala:50.5-50.39: error: missing return statement at end of method or lambda body public Orientation rotate_clockwise() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:82.9-105.36: error: missing break statement at end of switch section Orientation.vala:81.5-81.46: error: missing return statement at end of method or lambda body public Orientation rotate_counterclockwise() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:113.9-136.32: error: missing break statement at end of switch section Orientation.vala:112.5-112.41: error: missing return statement at end of method or lambda body public Orientation flip_top_to_bottom() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:144.9-167.36: error: missing break statement at end of switch section Orientation.vala:143.5-143.41: error: missing return statement at end of method or lambda body public Orientation flip_left_to_right() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:175.9-186.44: error: missing break statement at end of switch section Orientation.vala:174.5-174.30: error: missing return statement at end of method or lambda body public Orientation perform(Rotation rotation) { ^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:194.9-219.53: error: missing break statement at end of switch section Orientation.vala:193.5-193.34: error: missing return statement at end of method or lambda body public Rotation[] to_rotations() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:227.9-240.57: error: missing break statement at end of switch section Orientation.vala:226.5-226.39: error: missing return statement at end of method or lambda body public Dimensions rotate_dimensions(Dimensions dim) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:252.9-287.18: error: missing break statement at end of switch section Orientation.vala:306.9-352.18: error: missing break statement at end of switch section Orientation.vala:367.9-413.18: error: missing break statement at end of switch section Orientation.vala:452.9-463.42: error: missing break statement at end of switch section Orientation.vala:451.5-451.29: error: missing return statement at end of method or lambda body public Gdk.Pixbuf perform(Gdk.Pixbuf pixbuf) { ^^^^^^^^^^^^^^^^^^^^^^^^^ Orientation.vala:471.9-480.28: error: missing break statement at end of switch section Orientation.vala:470.5-470.28: error: missing return statement at end of method or lambda body public Rotation opposite() { ^^^^^^^^^^^^^^^^^^^^^^^^ ColorTransformation.vala:148.13-192.22: error: missing break statement at end of switch section EditingTools.vala:2567.9-2602.18: error: missing break statement at end of switch section Workers.vala:51.9-58.18: error: missing break statement at end of switch section PixbufCache.vala:192.9-199.18: error: missing break statement at end of switch section WebConnectors.vala:24.9-32.30: error: missing break statement at end of switch section WebConnectors.vala:23.5-23.27: error: missing return statement at end of method or lambda body public string to_string() { ^^^^^^^^^^^^^^^^^^^^^^^ WebConnectors.vala:39.5-39.40: error: missing return statement at end of method or lambda body public static HttpMethod from_string(string str) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ WebConnectors.vala:1117.5-1117.47: error: missing return statement at end of method or lambda body public ServiceInteractor? create_interactor(PublishingDialog host, string service_name) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:56.9-63.37: error: missing break statement at end of switch section Printing.vala:55.5-55.40: error: missing return statement at end of method or lambda body public Measurement get_content_width() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:71.9-78.38: error: missing break statement at end of switch section Printing.vala:70.5-70.41: error: missing return statement at end of method or lambda body public Measurement get_content_height() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:159.5-159.33: error: missing return statement at end of method or lambda body public Measurement convert_to(MeasurementUnit to_unit) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:467.5-467.48: error: missing return statement at end of method or lambda body private MeasurementUnit get_user_unit_choice() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:566.9-589.18: error: missing break statement at end of switch section Printing.vala:606.9-617.18: error: missing break statement at end of switch section Printing.vala:624.5-624.44: error: missing return statement at end of method or lambda body private ContentLayout get_content_layout() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Printing.vala:870.9-878.18: error: missing break statement at end of switch section PhotoFileFormat.vala:123.9-133.58: error: missing break statement at end of switch section PhotoFileFormat.vala:122.5-122.44: error: missing return statement at end of method or lambda body private PhotoFileFormatDriver get_driver() { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MimicManager.vala:110.23-110.62: error: use of possibly unassigned local variable `writer' VerifyJob job = new VerifyJob(this, photo, writer); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Compilation failed: 57 error(s), 0 warning(s) make: *** [src/.stamp] Error 1 Not really sure where to start or even what information to include to help others help me trouble shoot this issue. Please let me know what other information I can provide to help with this issue. Thanks, Tamer From adam at yorba.org Thu Oct 14 15:14:59 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 14 Oct 2010 08:14:59 -0700 Subject: [Shotwell] Problems compiling on new installation of Fedora 13 In-Reply-To: <4CB71B81.6050507@in-design.com> References: <4CB71B81.6050507@in-design.com> Message-ID: <4CB71E73.5080504@yorba.org> Tamer, what version of valac are you using? You can find out like this: % valac --version Shotwell requires at least Vala 0.9.7. adam On 10/14/2010 08:02 AM, nero wrote: > Linux nero.in-design.com 2.6.34.7-56.fc13.i686 #1 SMP Wed Sep 15 > 03:33:58 UTC 2010 i686 i686 i386 GNU/Linux > > l-0.7.2 # make > mkdir -p src > /usr/bin/valac --ccode --directory=src --basedir=src -g > --enable-checking --thread \ > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 --pkg=glib-2.0 > --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 --pkg=gconf-2.0 > --pkg=libgphoto2 --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 > --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 --pkg=gdk-x11-2.0 > --pkg=FixedKeyFile --pkg=ExtendedPosix --pkg=posix --pkg=LConv > --pkg=gdk-none --pkg=libraw \ > --vapidir=./vapi \ > -X -D_PREFIX='"/usr/local"' -X -D_VERSION='"0.7.2"' -X > -DGETTEXT_PACKAGE='"shotwell"' -X > -D_LANG_SUPPORT_DIR='"/usr/local/share/locale"' \ > -X -I./vapi \ > \ > src/main.vala src/AppWindow.vala src/CollectionPage.vala > src/Thumbnail.vala src/DatabaseTables.vala src/ThumbnailCache.vala > src/image_util.vala src/CheckerboardLayout.vala src/PhotoPage.vala > src/Page.vala src/ImportPage.vala src/GPhoto.vala src/SortedList.vala > src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala > src/Photo.vala src/Orientation.vala src/util.vala src/BatchImport.vala > src/Dialogs.vala src/Resources.vala src/Debug.vala src/Sidebar.vala > src/ColorTransformation.vala src/EditingTools.vala src/DataObject.vala > src/DataCollection.vala src/LibraryWindow.vala src/CameraTable.vala > src/DirectWindow.vala src/Properties.vala src/CustomComponents.vala > src/Config.vala src/Event.vala src/International.vala src/Workers.vala > src/system.vala src/AppDirs.vala src/PixbufCache.vala > src/WebConnectors.vala src/FacebookConnector.vala > src/CommandManager.vala src/Commands.vala src/SlideshowPage.vala > src/LibraryFiles.vala src/FlickrConnector.vala src/Printing.vala > src/Tag.vala src/TagPage.vala src/PicasaConnector.vala > src/Screensaver.vala src/PhotoFileAdapter.vala src/PhotoFileFormat.vala > src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala > src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala > src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala > src/PhotoExporter.vala src/DirectoryMonitor.vala src/LibraryMonitor.vala > src/OfflinePage.vala src/LastImportPage.vala src/AlienDatabase.vala > src/AlienDatabaseImportJob.vala src/AlienDatabaseImportDialog.vala > src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala > CollectionPage.vala:1747.9-1764.66: error: missing break statement at > end of switch section > CollectionPage.vala:1746.5-1746.42: error: missing return statement at > end of method or lambda body > private Comparator get_sort_comparator() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > CollectionPage.vala:1772.9-1780.61: error: missing break statement at > end of switch section > CollectionPage.vala:1771.5-1771.61: error: missing return statement at > end of method or lambda body > private ComparatorPredicate get_sort_comparator_predicate() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > CollectionPage.vala:1822.9-1831.22: error: missing break statement at > end of switch section > DatabaseTables.vala:1267.5-1267.80: error: missing return statement at > end of method or lambda body > public static Gee.HashMap? > marshall_all_transformations(string? trans) { > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ThumbnailCache.vala:214.9-219.30: error: missing break statement at end > of switch section > ThumbnailCache.vala:213.5-213.47: error: missing return statement at end > of method or lambda body > private static ThumbnailCache get_cache_for(Size size) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > CheckerboardLayout.vala:966.9-997.18: error: missing break statement at > end of switch section > ImportPage.vala:560.5-560.58: error: missing return statement at end of > method or lambda body > public override CheckerboardItem? get_fullscreen_photo() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ImportPage.vala:578.9-639.18: error: missing break statement at end of > switch section > Dimensions.vala:222.9-233.51: error: missing break statement at end of > switch section > Dimensions.vala:221.5-221.46: error: missing return statement at end of > method or lambda body > public Dimensions get_scaled_by_constraint(int scale, > ScaleConstraint constraint) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Photo.vala:505.9-513.43: error: missing break statement at end of switch > section > Photo.vala:504.5-504.46: error: missing return statement at end of > method or lambda body > private PhotoFileReader get_backing_reader(BackingFetchMode mode) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:51.9-74.32: error: missing break statement at end of > switch section > Orientation.vala:50.5-50.39: error: missing return statement at end of > method or lambda body > public Orientation rotate_clockwise() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:82.9-105.36: error: missing break statement at end of > switch section > Orientation.vala:81.5-81.46: error: missing return statement at end of > method or lambda body > public Orientation rotate_counterclockwise() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:113.9-136.32: error: missing break statement at end of > switch section > Orientation.vala:112.5-112.41: error: missing return statement at end of > method or lambda body > public Orientation flip_top_to_bottom() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:144.9-167.36: error: missing break statement at end of > switch section > Orientation.vala:143.5-143.41: error: missing return statement at end of > method or lambda body > public Orientation flip_left_to_right() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:175.9-186.44: error: missing break statement at end of > switch section > Orientation.vala:174.5-174.30: error: missing return statement at end of > method or lambda body > public Orientation perform(Rotation rotation) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:194.9-219.53: error: missing break statement at end of > switch section > Orientation.vala:193.5-193.34: error: missing return statement at end of > method or lambda body > public Rotation[] to_rotations() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:227.9-240.57: error: missing break statement at end of > switch section > Orientation.vala:226.5-226.39: error: missing return statement at end of > method or lambda body > public Dimensions rotate_dimensions(Dimensions dim) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:252.9-287.18: error: missing break statement at end of > switch section > Orientation.vala:306.9-352.18: error: missing break statement at end of > switch section > Orientation.vala:367.9-413.18: error: missing break statement at end of > switch section > Orientation.vala:452.9-463.42: error: missing break statement at end of > switch section > Orientation.vala:451.5-451.29: error: missing return statement at end of > method or lambda body > public Gdk.Pixbuf perform(Gdk.Pixbuf pixbuf) { > ^^^^^^^^^^^^^^^^^^^^^^^^^ > Orientation.vala:471.9-480.28: error: missing break statement at end of > switch section > Orientation.vala:470.5-470.28: error: missing return statement at end of > method or lambda body > public Rotation opposite() { > ^^^^^^^^^^^^^^^^^^^^^^^^ > ColorTransformation.vala:148.13-192.22: error: missing break statement > at end of switch section > EditingTools.vala:2567.9-2602.18: error: missing break statement at end > of switch section > Workers.vala:51.9-58.18: error: missing break statement at end of switch > section > PixbufCache.vala:192.9-199.18: error: missing break statement at end of > switch section > WebConnectors.vala:24.9-32.30: error: missing break statement at end of > switch section > WebConnectors.vala:23.5-23.27: error: missing return statement at end of > method or lambda body > public string to_string() { > ^^^^^^^^^^^^^^^^^^^^^^^ > WebConnectors.vala:39.5-39.40: error: missing return statement at end of > method or lambda body > public static HttpMethod from_string(string str) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > WebConnectors.vala:1117.5-1117.47: error: missing return statement at > end of method or lambda body > public ServiceInteractor? create_interactor(PublishingDialog host, > string service_name) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:56.9-63.37: error: missing break statement at end of > switch section > Printing.vala:55.5-55.40: error: missing return statement at end of > method or lambda body > public Measurement get_content_width() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:71.9-78.38: error: missing break statement at end of > switch section > Printing.vala:70.5-70.41: error: missing return statement at end of > method or lambda body > public Measurement get_content_height() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:159.5-159.33: error: missing return statement at end of > method or lambda body > public Measurement convert_to(MeasurementUnit to_unit) { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:467.5-467.48: error: missing return statement at end of > method or lambda body > private MeasurementUnit get_user_unit_choice() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:566.9-589.18: error: missing break statement at end of > switch section > Printing.vala:606.9-617.18: error: missing break statement at end of > switch section > Printing.vala:624.5-624.44: error: missing return statement at end of > method or lambda body > private ContentLayout get_content_layout() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Printing.vala:870.9-878.18: error: missing break statement at end of > switch section > PhotoFileFormat.vala:123.9-133.58: error: missing break statement at end > of switch section > PhotoFileFormat.vala:122.5-122.44: error: missing return statement at > end of method or lambda body > private PhotoFileFormatDriver get_driver() { > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > MimicManager.vala:110.23-110.62: error: use of possibly unassigned local > variable `writer' > VerifyJob job = new VerifyJob(this, photo, writer); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Compilation failed: 57 error(s), 0 warning(s) > make: *** [src/.stamp] Error 1 > > > Not really sure where to start or even what information to include to > help others help me trouble shoot this issue. Please let me know what > other information I can provide to help with this issue. > > Thanks, > > Tamer > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From nero at in-design.com Thu Oct 14 15:26:25 2010 From: nero at in-design.com (nero) Date: Thu, 14 Oct 2010 11:26:25 -0400 Subject: [Shotwell] Problems compiling on new installation of Fedora 13 In-Reply-To: <4CB71E73.5080504@yorba.org> References: <4CB71B81.6050507@in-design.com> <4CB71E73.5080504@yorba.org> Message-ID: <4CB72121.7090303@in-design.com> Installing a greater version of valac worked. Thanks, T From jim at yorba.org Thu Oct 14 19:05:56 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 14 Oct 2010 12:05:56 -0700 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: <1286975866.1711.41.camel@Linley6> References: <1286915806.1707.55.camel@Linley6> <87sk0a1r8k.fsf@SSpaeth.de> <1286961217.1711.30.camel@Linley6> <87fwwaqoue.fsf@SSpaeth.de> <1286975866.1711.41.camel@Linley6> Message-ID: There's a number of different issues and problems in play here, and I'm afraid they're all being conflated under the banner of "duplicate detection". It's important to understand at least a couple of basic concepts. First, in regards to a file that is twice the size of another being regarded as a duplicate, that is most likely due to this bug: http://trac.yorba.org/ticket/2587 It was an oversight on my part and I would like to fix this for 0.8. Now, beyond that, there are three kinds of duplicate detection (that banner I was mentioning before): 1. The same filepath: If you import /home/jim/photo.jpg and then import again /home/jim/photo.jpg, Shotwell will treat that as a duplicate. This is a special case of duplicate detection; Shotwell will not allow you to have two photo "objects" in your library pointing to the same file. Note that this is true even if you update/change the file outside of Shotwell, i.e. modify its EXIF. Shotwell 0.7 does *not* detect external changes and update the library. Shotwell 0.8, on the other hand, will do that exact thing by detecting the change at startup: http://trac.yorba.org/ticket/2476 2. The same file contents: If two photos are byte-for-byte identical, they are considered duplicates and Shotwell will only import one of them. This comparison is of the entire file; changing the EXIF in one is enough to make the files different. 3. The same file on camera and on disk: Camera import introduces a problem. Because it takes so long to download a file and it's desirable to be able to see which photos you've already imported before importing them, we want to detect duplicates before pulling down the file. We do this by comparing the photo thumbnails (which is what led to that bug I mentioned at the top of this message). Otherwise, we would download the file, compare it to the library, realize it was a duplicate, and then delete the file. Now, apart from all this, the trash can creates a special case. If you move a photo to the trash and then import a file that is a duplicate -- i.e. is either the same filepath OR the same contents -- Shotwell will restore the photo object from the trash and not import the new file. (In the case of the same filepath, that's essentially what you're asking for.) We assume if you import a duplicate file, you're saying "You know what, I want this photo after all," and we restore it from the trash. It's also restoring all the stuff you've done to it while it was in Shotwell, i.e. its tags, transformations, and so on. We see this as valuable stuff to be preserving. This is all quite distinct from a different operation we refer to as "re-import": To take an existing photo in the library and re-examine all its properties and reflect any changes in the database (thumbnails, tags, etc.). I think what Michael is asking for when importing a file already in the trash is for Shotwell to re-import it. In 0.8 we're attacking the problem slightly differently, but detecting the change automatically and re-importing it in the background. But 0.7 does not have this capability in any manner. I know this is a lot to absorb, but I feel like some concepts and terms are being muddied. Some of it is my own fault, as we're trying to keep it simple for users, and some of it is due to a bug that's being grouped in as a part of designed behavior. By being aware of the different cases of "duplicate detection", I think we can figure what is useful, what can be tweaked, and what needs to be changed. -- Jim On Wed, Oct 13, 2010 at 6:17 AM, Michael Hendry wrote: > On Wed, 2010-10-13 at 14:06 +0200, Sebastian Spaeth wrote: > > On 2010-10-13, Michael Hendry wrote: > > > > Preventing duplicates is one of the beauties of shotwell for me. I > often > > > > run an import from a camera sd card twice without deleting the > pictures > > > > inbetween, I often import from a network share where my wife has put > new > > > > photos in various locations, etc. I were lost if not for the > duplicate > > > > detection :-). > > > > > So the rest of us have to suffer because of your carelessness? > > > > It's not carelessness, it's my workflow. I reimport the same directory > > over and over again, with at least 2 persons adding pictures to various > > locations. > > OK - point taken! > > > > > > At the very least, there should be a warning of the duplicates, and an > > > option to go ahead anyway, with a configuration option to ban all > > > duplicates. > > > > Yep, it seems that would satisfy everyone. > > > > > > I disagree, in my usecase once I've thrown a picture in the > wastebasket, > > > > I don't want it to be reimported. ooh, "zombie photos" otherwise :). > > > > > You agreed (above) that restoring information from the Wastebasket is > > > the wrong thing to do when an attempt to import apparently identical > > > images is made. Are you suggesting that once you've emptied the > > > Wastebasket Shotwell should "remember" that you've got rid of an image > > > and never want it imported again? > > > > Yes, that is what I think. Once discarded, it should not be reimported > > (without a warning). > > > > Agreed, or a warning about duplicates and a set of "Yes...Yes to > > > all...No...No to all" import options would sort that. > > > > /me nods. > > > > > > If they have different resolution, they are (for shotwell) different > > > > images as the files differ, so that should already be possible. > > > > > > Doesn't work for me - I think it's because the thumbnails are > identical, > > > and the test for "identicality" doesn't take file-size or EXIF data > into > > > consideration. > > > > Uhh, last I looked at the database, it was taking the md5 of the photo > > file for duplicate identification. So if the EXIF data is different (or > > the file size), it should be possible to import duplicates. I defer to > > those more knowledgeable of the code base though. > > In https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/644125 #4 Jim > Nelson confirms that 0.7.x won't pick up the change in EXIF data. > > I've also come across the situation where one file twice the size of > another was regarded as a duplicate. > > Michael > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From baldakkl at gmail.com Thu Oct 14 19:13:15 2010 From: baldakkl at gmail.com (Lorenzo Baldacchini) Date: Thu, 14 Oct 2010 21:13:15 +0200 Subject: [Shotwell] Problem in compiling on ubuntu 10.04 In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Lorenzo Baldacchini Date: 2010/10/14 Subject: Problem in compiling on ubuntu 10.04 To: shotwell at lists.zaftra.yorba.org Hi all, I am trying to compile the version 2291 and it seems to miss gstreamer * * *lorenzo at lorenzo-laptop:~/shotwell$ make* *Package gstreamer-0.10 was not found in the pkg-config search path.* *Perhaps you should add the directory containing `gstreamer-0.10.pc'* *to the PKG_CONFIG_PATH environment variable* *No package 'gstreamer-0.10' found* *Package gstreamer-base-0.10 was not found in the pkg-config search path.* *Perhaps you should add the directory containing `gstreamer-base-0.10.pc'* *to the PKG_CONFIG_PATH environment variable* *No package 'gstreamer-base-0.10' found* *make: *** [src/.stamp] Errore 1* * * How can I solve this? I have installed quite every package of gstreamer, but it does not work. Thanks to all! From adam at yorba.org Thu Oct 14 20:37:17 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 14 Oct 2010 13:37:17 -0700 Subject: [Shotwell] Problem in compiling on ubuntu 10.04 In-Reply-To: References: Message-ID: <4CB769FD.8050607@yorba.org> Lorenzo, the Shotwell trunk depends on GStreamer because of our new support for videos. You said you're on Ubuntu 10.04. You'll need to make sure you have the following packages installed: libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev If you have these packages installed, but *still* see these errors, then let me know and we can debug further. cheers adam On 10/14/2010 12:13 PM, Lorenzo Baldacchini wrote: > ---------- Forwarded message ---------- > From: Lorenzo Baldacchini > Date: 2010/10/14 > Subject: Problem in compiling on ubuntu 10.04 > To: shotwell at lists.zaftra.yorba.org > > > Hi all, > I am trying to compile the version 2291 and it seems to miss gstreamer > * > * > *lorenzo at lorenzo-laptop:~/shotwell$ make* > *Package gstreamer-0.10 was not found in the pkg-config search path.* > *Perhaps you should add the directory containing `gstreamer-0.10.pc'* > *to the PKG_CONFIG_PATH environment variable* > *No package 'gstreamer-0.10' found* > *Package gstreamer-base-0.10 was not found in the pkg-config search path.* > *Perhaps you should add the directory containing `gstreamer-base-0.10.pc'* > *to the PKG_CONFIG_PATH environment variable* > *No package 'gstreamer-base-0.10' found* > *make: *** [src/.stamp] Errore 1* > * > * > How can I solve this? > I have installed quite every package of gstreamer, but it does not work. > Thanks to all! > _______________________________________________ > Shotwell mailing list > Shotwell at lists.zaftra.yorba.org > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell From jani at ubuntu.com Sat Oct 16 14:19:20 2010 From: jani at ubuntu.com (Jani Monoses) Date: Sat, 16 Oct 2010 17:19:20 +0300 Subject: [Shotwell] miscompilation? Message-ID: Hello I am using Ubuntu 10.10 and Shotwell trunk. Whenever I try to rate or rename a photo it segfaults. Changing the Photo file like below makes the error go away. According to the core file it crashes in database_table_unref.c called from Photo. Can others reproduce this on 10.10 with the default valac package and trunk? --- src/Photo.vala 2010-10-16 16:28:53.000000000 +0300 +++ Photo.vala 2010-10-16 14:07:16.000000000 +0300 @@ -1413,7 +1413,8 @@ if (sources != null) sources.freeze_notifications(); - PhotoTable.get_instance().begin_transaction(); + PhotoTable pt = PhotoTable.get_instance(); + pt.begin_transaction(); foreach (Photo photo in photos) { try { From simonspa at kth.se Sat Oct 16 17:20:28 2010 From: simonspa at kth.se (Simon Spannagel) Date: Sat, 16 Oct 2010 19:20:28 +0200 Subject: [Shotwell] Dividing line Message-ID: <4CB9DEDC.1090304@kth.se> Hejsan, just a little idea for a small UI improvement: what about a thin dividing line and a new starting row between photos in the tag-view that have a bigger distance in time than let's say 3 months? Following scenario: I'm visiting a place, taking photos, store them using Shotwell. Half a year later I return, taking photos again, string them again. All photos from both sessions get the same tag "the_place" among other. Now browsing my photos by clicking on this "the_place" tag, nothing shows me, that these photos do not belong together but are taken at the same place. By a thin division line this could be solved, just as eye-catcher: "watch out, other series!" and then I can take a closer look using the date metadata. a attached a simple mockup. What do you think? Greets, Simon From mahfiaz at gmail.com Sat Oct 16 18:08:16 2010 From: mahfiaz at gmail.com (Mattias =?ISO-8859-1?Q?P=F5ldaru?=) Date: Sat, 16 Oct 2010 21:08:16 +0300 Subject: [Shotwell] Dividing line In-Reply-To: <4CB9DEDC.1090304@kth.se> References: <4CB9DEDC.1090304@kth.se> Message-ID: <1287252496.5698.1.camel@antiloop> ?hel kenal p?eval, L, 2010-10-16 kell 19:20, kirjutas Simon Spannagel: > a attached a simple mockup. Could you please upload the mockup file to a image sharing service and post a link here? What about a picasa-like divider with date on it? Mattias From simonspa at kth.se Sat Oct 16 23:45:41 2010 From: simonspa at kth.se (Simon Spannagel) Date: Sun, 17 Oct 2010 01:45:41 +0200 Subject: [Shotwell] Dividing line In-Reply-To: <1287252496.5698.1.camel@antiloop> References: <4CB9DEDC.1090304@kth.se> <1287252496.5698.1.camel@antiloop> Message-ID: <4CBA3925.70904@kth.se> Oh, I'm sorry: http://yfrog.com/5nmockupjj yeah, maybe with the date on it, but I think this is not necessary if we want to keep it simple. there should just be a notifiable division. greetings, Simon Am 16.10.2010 20:08, schrieb Mattias P?ldaru: > ?hel kenal p?eval, L, 2010-10-16 kell 19:20, kirjutas Simon Spannagel: > >> a attached a simple mockup. > Could you please upload the mockup file to a image sharing service and > post a link here? > > What about a picasa-like divider with date on it? > > > Mattias > From jim at yorba.org Mon Oct 18 19:47:46 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 18 Oct 2010 12:47:46 -0700 Subject: [Shotwell] Dividing line In-Reply-To: <4CBA3925.70904@kth.se> References: <4CB9DEDC.1090304@kth.se> <1287252496.5698.1.camel@antiloop> <4CBA3925.70904@kth.se> Message-ID: The way we're thinking about doing this is ticketed here: http://trac.yorba.org/ticket/222 Instead of picking an arbitrary span (like 3 months), we would separate each event in the Photos view. There would probably be a user option in the View menu to enable and disable this. -- Jim On Sat, Oct 16, 2010 at 4:45 PM, Simon Spannagel wrote: > Oh, I'm sorry: > http://yfrog.com/5nmockupjj > > yeah, maybe with the date on it, but I think this is not necessary if we > want to keep it simple. there should just be a notifiable division. > > greetings, > Simon > > > Am 16.10.2010 20:08, schrieb Mattias P?ldaru: > > ?hel kenal p?eval, L, 2010-10-16 kell 19:20, kirjutas Simon Spannagel: >> >> a attached a simple mockup. >>> >> Could you please upload the mockup file to a image sharing service and >> post a link here? >> >> What about a picasa-like divider with date on it? >> >> >> Mattias >> >> _______________________________________________ > Shotwell mailing list > Shotwell at lists.zaftra.yorba.org > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > From bengt at thuree.com Tue Oct 19 13:32:42 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 20 Oct 2010 00:32:42 +1100 Subject: [Shotwell] Gstreamer ? Message-ID: <1287495162.9473.9.camel@lappis.thuree.com> Hi Sorry, if I have missed this one, but where do I get gstreamer package from? Package gstreamer-0.10 was not found in the pkg-config search path. Trying to compile shotwell from source on my Squeeze (debian) system, which means I needed to compile Vala etc from source as well. Thanks in advance /Bengt p.s. Is there a Debian repository anywhere by the way? -- With Regards Bengt Thuree bengt at thuree.com From bengt at thuree.com Tue Oct 19 13:34:17 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 20 Oct 2010 00:34:17 +1100 Subject: [Shotwell] Gstreamer ? - Solved In-Reply-To: <1287495162.9473.9.camel@lappis.thuree.com> References: <1287495162.9473.9.camel@lappis.thuree.com> Message-ID: <1287495257.9473.10.camel@lappis.thuree.com> :) Oups... aptitude install libgstreamer0.10-dev fixed it :) Sorry for this /Bengt On Wed, 2010-10-20 at 00:32 +1100, Bengt Thuree wrote: > Hi > > Sorry, if I have missed this one, but where do I get gstreamer package > from? > > Package gstreamer-0.10 was not found in the pkg-config search path. > > > Trying to compile shotwell from source on my Squeeze (debian) system, > which means I needed to compile Vala etc from source as well. > > Thanks in advance > > /Bengt > > p.s. > Is there a Debian repository anywhere by the way? -- With Regards Bengt Thuree bengt at thuree.com From VveOYzxbFBEW8Jeb at cry-its.trillianpro.com Tue Oct 19 13:44:02 2010 From: VveOYzxbFBEW8Jeb at cry-its.trillianpro.com (Christian) Date: Tue, 19 Oct 2010 08:44:02 -0500 Subject: [Shotwell] Captions for Facebook uploads Message-ID: <1287495841.24594.31.camel@cd-mintylap> Hi, This kind of says how great Shotwell has become when my main issue is that there's no option to add captions to Facebook uploads. I really hop this will be added soon since every other Facebook uploader (including mobile ones) has an adding caption option. -- //Christian From bengt at thuree.com Tue Oct 19 21:24:56 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 20 Oct 2010 08:24:56 +1100 Subject: [Shotwell] Compile errors? Message-ID: <1287523496.9473.15.camel@lappis.thuree.com> Hi I have installed latest Vala (0.11) and libgee (0.6.0) and am getting the following errors when I am compiling. Am I using a to late Vala or? I have also an up to date shotwell version bengt at lappis:~/Development/shotwell$ svn update At revision 2303. /Bengt > bengt at lappis:~/Development/shotwell$ make > mkdir -p src > valac --ccode --directory=src --basedir=src -g --enable-checking --thread \ > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 --pkg=glib-2.0 --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 --pkg=json-glib-1.0 --pkg=gconf-2.0 --pkg=libgphoto2 --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 --pkg=gdk-x11-2.0 --pkg=gstreamer-0.10 --pkg=gstreamer-base-0.10 --pkg=ExtendedPosix --pkg=posix --pkg=LConv --pkg=libraw \ > --vapidir=./vapi \ > -X -D_PREFIX='"/home/bengt/unstable/shotwell"' -X -D_VERSION='"0.7.2+trunk"' -X -DGETTEXT_PACKAGE='"shotwell"' -X -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' \ > -X -I./vapi \ > \ > src/main.vala src/AppWindow.vala src/CollectionPage.vala src/Thumbnail.vala src/DatabaseTables.vala src/ThumbnailCache.vala src/image_util.vala src/CheckerboardLayout.vala src/PhotoPage.vala src/Page.vala src/ImportPage.vala src/GPhoto.vala src/SortedList.vala src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala src/Photo.vala src/Orientation.vala src/util.vala src/BatchImport.vala src/Dialogs.vala src/Resources.vala src/Debug.vala src/Sidebar.vala src/ColorTransformation.vala src/EditingTools.vala src/DataObject.vala src/DataCollection.vala src/LibraryWindow.vala src/CameraTable.vala src/DirectWindow.vala src/Properties.vala src/CustomComponents.vala src/Config.vala src/Event.vala src/International.vala src/Workers.vala src/system.vala src/AppDirs.vala src/PixbufCache.vala src/WebConnectors.vala src/FacebookConnector.vala src/CommandManager.vala src/Commands.vala src/SlideshowPage.vala src/LibraryFiles.vala src/FlickrConnector.vala src/YandexConnector.vala src/Printing.vala src/Tag.vala src/TagPage.vala src/PicasaConnector.vala src/Screensaver.vala src/PhotoFileAdapter.vala src/PhotoFileFormat.vala src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala src/Exporter.vala src/DirectoryMonitor.vala src/LibraryMonitor.vala src/OfflinePage.vala src/LastImportPage.vala src/AlienDatabase.vala src/AlienDatabaseImportJob.vala src/AlienDatabaseImportDialog.vala src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala src/VideoSupport.vala src/VideosPage.vala src/Tombstone.vala src/MetadataWriter.vala src/Application.vala src/TimedQueue.vala src/MediaPage.vala > warning: D-Bus GLib is deprecated, use GDBus > src/GdkSupport.vala:86.17-86.55: error: 1 extra arguments for `bool Gdk.PixbufLoader.write (uint8[] buf)' > pixbuf_loader.write(buffer, bytes_read); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > src/Workers.vala:427.36-427.70: error: Argument 2: Cannot convert from `BackgroundJob.priority_compare_func' to `GLib.CompareDataFunc' > queue.push_sorted(job, BackgroundJob.priority_compare_func); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > src/WebConnectors.vala:255.72-255.85: error: Argument 3: Cannot convert from `string?' to `uint8[]' > message.set_request(payload_content_type, Soup.MemoryUse.COPY, custom_payload, > ^^^^^^^^^^^^^^ > src/WebConnectors.vala:372.17-372.31: error: Argument 3: Cannot convert from `string?' to `uint8[]' > formdata_string, formdata_string.length); > ^^^^^^^^^^^^^^^ > src/WebConnectors.vala:497.37-497.102: error: 1 extra arguments for `void Soup.Buffer.new (Soup.MemoryUse use, uint8[] data)' > Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, photo_data.data, data_length); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > src/YandexConnector.vala:639.78-639.87: error: Argument 2: Cannot convert from `string?' to `uint8[]' > Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); > ^^^^^^^^^^ > > ^^^^^^^^^^^^ > Compilation failed: 6 error(s), 115 warning(s) > make: *** [src/.stamp] Error 1 > bengt at lappis:~/Development/shotwell$ > -- With Regards Bengt Thuree bengt at thuree.com From jim at yorba.org Tue Oct 19 21:30:56 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 19 Oct 2010 14:30:56 -0700 Subject: [Shotwell] Compile errors? In-Reply-To: <1287523496.9473.15.camel@lappis.thuree.com> References: <1287523496.9473.15.camel@lappis.thuree.com> Message-ID: Hi Bengt, Shotwell is not updated to work with Vala 0.11 (yet). See: http://trac.yorba.org/ticket/2638 We recommend using 0.10 for now. Thanks, -- Jim On Tue, Oct 19, 2010 at 2:24 PM, Bengt Thuree wrote: > Hi > > I have installed latest Vala (0.11) and libgee (0.6.0) > and am getting the following errors when I am compiling. > > Am I using a to late Vala or? > > I have also an up to date shotwell version > bengt at lappis:~/Development/shotwell$ svn update > At revision 2303. > > /Bengt > > bengt at lappis:~/Development/shotwell$ make > > mkdir -p src > > valac --ccode --directory=src --basedir=src -g --enable-checking --thread > \ > > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 --pkg=glib-2.0 > --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 --pkg=json-glib-1.0 --pkg=gconf-2.0 > --pkg=libgphoto2 --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 > --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 --pkg=gdk-x11-2.0 > --pkg=gstreamer-0.10 --pkg=gstreamer-base-0.10 --pkg=ExtendedPosix > --pkg=posix --pkg=LConv --pkg=libraw \ > > --vapidir=./vapi \ > > -X -D_PREFIX='"/home/bengt/unstable/shotwell"' -X > -D_VERSION='"0.7.2+trunk"' -X -DGETTEXT_PACKAGE='"shotwell"' -X > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' \ > > -X -I./vapi \ > > \ > > src/main.vala src/AppWindow.vala src/CollectionPage.vala > src/Thumbnail.vala src/DatabaseTables.vala src/ThumbnailCache.vala > src/image_util.vala src/CheckerboardLayout.vala src/PhotoPage.vala > src/Page.vala src/ImportPage.vala src/GPhoto.vala src/SortedList.vala > src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala src/Photo.vala > src/Orientation.vala src/util.vala src/BatchImport.vala src/Dialogs.vala > src/Resources.vala src/Debug.vala src/Sidebar.vala > src/ColorTransformation.vala src/EditingTools.vala src/DataObject.vala > src/DataCollection.vala src/LibraryWindow.vala src/CameraTable.vala > src/DirectWindow.vala src/Properties.vala src/CustomComponents.vala > src/Config.vala src/Event.vala src/International.vala src/Workers.vala > src/system.vala src/AppDirs.vala src/PixbufCache.vala src/WebConnectors.vala > src/FacebookConnector.vala src/CommandManager.vala src/Commands.vala > src/SlideshowPage.vala src/LibraryFiles.vala src/FlickrConnector.vala > src/YandexConnector.vala src/Pr > inting.vala src/Tag.vala src/TagPage.vala src/PicasaConnector.vala > src/Screensaver.vala src/PhotoFileAdapter.vala src/PhotoFileFormat.vala > src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala > src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala > src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala > src/Exporter.vala src/DirectoryMonitor.vala src/LibraryMonitor.vala > src/OfflinePage.vala src/LastImportPage.vala src/AlienDatabase.vala > src/AlienDatabaseImportJob.vala src/AlienDatabaseImportDialog.vala > src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala > src/VideoSupport.vala src/VideosPage.vala src/Tombstone.vala > src/MetadataWriter.vala src/Application.vala src/TimedQueue.vala > src/MediaPage.vala > > warning: D-Bus GLib is deprecated, use GDBus > > src/GdkSupport.vala:86.17-86.55: error: 1 extra arguments for `bool > Gdk.PixbufLoader.write (uint8[] buf)' > > pixbuf_loader.write(buffer, bytes_read); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/Workers.vala:427.36-427.70: error: Argument 2: Cannot convert from > `BackgroundJob.priority_compare_func' to > `GLib.CompareDataFunc' > > queue.push_sorted(job, BackgroundJob.priority_compare_func); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/WebConnectors.vala:255.72-255.85: error: Argument 3: Cannot convert > from `string?' to `uint8[]' > > message.set_request(payload_content_type, Soup.MemoryUse.COPY, > custom_payload, > > > ^^^^^^^^^^^^^^ > > src/WebConnectors.vala:372.17-372.31: error: Argument 3: Cannot convert > from `string?' to `uint8[]' > > formdata_string, formdata_string.length); > > ^^^^^^^^^^^^^^^ > > src/WebConnectors.vala:497.37-497.102: error: 1 extra arguments for `void > Soup.Buffer.new (Soup.MemoryUse use, uint8[] data)' > > Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, > photo_data.data, data_length); > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/YandexConnector.vala:639.78-639.87: error: Argument 2: Cannot convert > from `string?' to `uint8[]' > > Soup.Buffer bindable_data = new > Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); > > > ^^^^^^^^^^ > > > > ^^^^^^^^^^^^ > > Compilation failed: 6 error(s), 115 warning(s) > > make: *** [src/.stamp] Error 1 > > bengt at lappis:~/Development/shotwell$ > > > > -- > With Regards > > Bengt Thuree > bengt at thuree.com > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.zaftra.yorba.org > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > From bengt at thuree.com Tue Oct 19 22:16:39 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 20 Oct 2010 09:16:39 +1100 Subject: [Shotwell] Compile errors? In-Reply-To: References: <1287523496.9473.15.camel@lappis.thuree.com> Message-ID: <1287526599.9473.17.camel@lappis.thuree.com> Hi Worked much better... still some issues though :( > cc -c `pkg-config --cflags atk gdk-2.0 gee-1.0 gtk+-2.0 glib-2.0 libexif sqlite3 gexiv2 json-glib-1.0 gconf-2.0 libgphoto2 libsoup-2.4 libxml-2.0 unique-1.0 webkit-1.0 gudev-1.0 dbus-glib-1 gdk-x11-2.0 gstreamer-0.10 gstreamer-base-0.10 gthread-2.0` -I./vapi -D_PREFIX='"/home/bengt/unstable/shotwell"' -D_VERSION='"0.7.2+trunk"' -DGETTEXT_PACKAGE='"shotwell"' -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' `./libraw-config --cflags` -O2 -g -pipe -fPIC -DG_UDEV_API_IS_SUBJECT_TO_CHANGE -o src/main.o src/main.c > Package json-glib-1.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `json-glib-1.0.pc' > to the PKG_CONFIG_PATH environment variable > No package 'json-glib-1.0' found > /Bengt On Tue, 2010-10-19 at 14:30 -0700, Jim Nelson wrote: > Hi Bengt, > > Shotwell is not updated to work with Vala 0.11 (yet). See: > http://trac.yorba.org/ticket/2638 > > We recommend using 0.10 for now. > > Thanks, > > -- Jim > > On Tue, Oct 19, 2010 at 2:24 PM, Bengt Thuree > wrote: > Hi > > I have installed latest Vala (0.11) and libgee (0.6.0) > and am getting the following errors when I am compiling. > > Am I using a to late Vala or? > > I have also an up to date shotwell version > bengt at lappis:~/Development/shotwell$ svn update > At revision 2303. > > /Bengt > > bengt at lappis:~/Development/shotwell$ make > > mkdir -p src > > valac --ccode --directory=src --basedir=src -g > --enable-checking --thread \ > > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 > --pkg=glib-2.0 --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 > --pkg=json-glib-1.0 --pkg=gconf-2.0 --pkg=libgphoto2 > --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 > --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 > --pkg=gdk-x11-2.0 --pkg=gstreamer-0.10 > --pkg=gstreamer-base-0.10 --pkg=ExtendedPosix --pkg=posix > --pkg=LConv --pkg=libraw \ > > --vapidir=./vapi \ > > -X -D_PREFIX='"/home/bengt/unstable/shotwell"' -X > -D_VERSION='"0.7.2+trunk"' -X -DGETTEXT_PACKAGE='"shotwell"' > -X > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' \ > > -X -I./vapi \ > > \ > > src/main.vala src/AppWindow.vala > src/CollectionPage.vala src/Thumbnail.vala > src/DatabaseTables.vala src/ThumbnailCache.vala > src/image_util.vala src/CheckerboardLayout.vala > src/PhotoPage.vala src/Page.vala src/ImportPage.vala > src/GPhoto.vala src/SortedList.vala > src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala > src/Photo.vala src/Orientation.vala src/util.vala > src/BatchImport.vala src/Dialogs.vala src/Resources.vala > src/Debug.vala src/Sidebar.vala src/ColorTransformation.vala > src/EditingTools.vala src/DataObject.vala > src/DataCollection.vala src/LibraryWindow.vala > src/CameraTable.vala src/DirectWindow.vala src/Properties.vala > src/CustomComponents.vala src/Config.vala src/Event.vala > src/International.vala src/Workers.vala src/system.vala > src/AppDirs.vala src/PixbufCache.vala src/WebConnectors.vala > src/FacebookConnector.vala src/CommandManager.vala > src/Commands.vala src/SlideshowPage.vala src/LibraryFiles.vala > src/FlickrConnector.vala src/YandexConnector.vala src/Pr > inting.vala src/Tag.vala src/TagPage.vala > src/PicasaConnector.vala src/Screensaver.vala > src/PhotoFileAdapter.vala src/PhotoFileFormat.vala > src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala > src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala > src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala > src/Exporter.vala src/DirectoryMonitor.vala > src/LibraryMonitor.vala src/OfflinePage.vala > src/LastImportPage.vala src/AlienDatabase.vala > src/AlienDatabaseImportJob.vala > src/AlienDatabaseImportDialog.vala > src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala > src/VideoSupport.vala src/VideosPage.vala src/Tombstone.vala > src/MetadataWriter.vala src/Application.vala > src/TimedQueue.vala src/MediaPage.vala > > warning: D-Bus GLib is deprecated, use GDBus > > src/GdkSupport.vala:86.17-86.55: error: 1 extra arguments > for `bool Gdk.PixbufLoader.write (uint8[] buf)' > > pixbuf_loader.write(buffer, bytes_read); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/Workers.vala:427.36-427.70: error: Argument 2: Cannot > convert from `BackgroundJob.priority_compare_func' to > `GLib.CompareDataFunc' > > queue.push_sorted(job, > BackgroundJob.priority_compare_func); > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/WebConnectors.vala:255.72-255.85: error: Argument 3: > Cannot convert from `string?' to `uint8[]' > > message.set_request(payload_content_type, > Soup.MemoryUse.COPY, custom_payload, > > > ^^^^^^^^^^^^^^ > > src/WebConnectors.vala:372.17-372.31: error: Argument 3: > Cannot convert from `string?' to `uint8[]' > > formdata_string, formdata_string.length); > > ^^^^^^^^^^^^^^^ > > src/WebConnectors.vala:497.37-497.102: error: 1 extra > arguments for `void Soup.Buffer.new (Soup.MemoryUse use, > uint8[] data)' > > Soup.Buffer bindable_data = new > Soup.Buffer(Soup.MemoryUse.COPY, photo_data.data, > data_length); > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/YandexConnector.vala:639.78-639.87: error: Argument 2: > Cannot convert from `string?' to `uint8[]' > > Soup.Buffer bindable_data = new > Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); > > > ^^^^^^^^^^ > > > > ^^^^^^^^^^^^ > > Compilation failed: 6 error(s), 115 warning(s) > > make: *** [src/.stamp] Error 1 > > bengt at lappis:~/Development/shotwell$ > > > > -- > With Regards > > Bengt Thuree > bengt at thuree.com > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.zaftra.yorba.org > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- With Regards Bengt Thuree bengt at thuree.com From jim at yorba.org Tue Oct 19 22:25:33 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 19 Oct 2010 15:25:33 -0700 Subject: [Shotwell] Compile errors? In-Reply-To: <1287526599.9473.17.camel@lappis.thuree.com> References: <1287523496.9473.15.camel@lappis.thuree.com> <1287526599.9473.17.camel@lappis.thuree.com> Message-ID: Yes, that library requirement was added recently for Yandex photo support. This should do the trick: $ sudo apt-get install libjson-glib-dev -- Jim On Tue, Oct 19, 2010 at 3:16 PM, Bengt Thuree wrote: > Hi > > Worked much better... still some issues though :( > > > > cc -c `pkg-config --cflags atk gdk-2.0 gee-1.0 gtk+-2.0 glib-2.0 libexif > sqlite3 gexiv2 json-glib-1.0 gconf-2.0 libgphoto2 libsoup-2.4 libxml-2.0 > unique-1.0 webkit-1.0 gudev-1.0 dbus-glib-1 gdk-x11-2.0 gstreamer-0.10 > gstreamer-base-0.10 gthread-2.0` -I./vapi > -D_PREFIX='"/home/bengt/unstable/shotwell"' -D_VERSION='"0.7.2+trunk"' > -DGETTEXT_PACKAGE='"shotwell"' > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' > `./libraw-config --cflags` -O2 -g -pipe -fPIC > -DG_UDEV_API_IS_SUBJECT_TO_CHANGE -o src/main.o src/main.c > > Package json-glib-1.0 was not found in the pkg-config search path. > > Perhaps you should add the directory containing `json-glib-1.0.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'json-glib-1.0' found > > > /Bengt > > On Tue, 2010-10-19 at 14:30 -0700, Jim Nelson wrote: > > Hi Bengt, > > > > Shotwell is not updated to work with Vala 0.11 (yet). See: > > http://trac.yorba.org/ticket/2638 > > > > We recommend using 0.10 for now. > > > > Thanks, > > > > -- Jim > > > > On Tue, Oct 19, 2010 at 2:24 PM, Bengt Thuree > > wrote: > > Hi > > > > I have installed latest Vala (0.11) and libgee (0.6.0) > > and am getting the following errors when I am compiling. > > > > Am I using a to late Vala or? > > > > I have also an up to date shotwell version > > bengt at lappis:~/Development/shotwell$ svn update > > At revision 2303. > > > > /Bengt > > > bengt at lappis:~/Development/shotwell$ make > > > mkdir -p src > > > valac --ccode --directory=src --basedir=src -g > > --enable-checking --thread \ > > > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 > > --pkg=glib-2.0 --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 > > --pkg=json-glib-1.0 --pkg=gconf-2.0 --pkg=libgphoto2 > > --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 > > --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 > > --pkg=gdk-x11-2.0 --pkg=gstreamer-0.10 > > --pkg=gstreamer-base-0.10 --pkg=ExtendedPosix --pkg=posix > > --pkg=LConv --pkg=libraw \ > > > --vapidir=./vapi \ > > > -X -D_PREFIX='"/home/bengt/unstable/shotwell"' -X > > -D_VERSION='"0.7.2+trunk"' -X -DGETTEXT_PACKAGE='"shotwell"' > > -X > > > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' \ > > > -X -I./vapi \ > > > \ > > > src/main.vala src/AppWindow.vala > > src/CollectionPage.vala src/Thumbnail.vala > > src/DatabaseTables.vala src/ThumbnailCache.vala > > src/image_util.vala src/CheckerboardLayout.vala > > src/PhotoPage.vala src/Page.vala src/ImportPage.vala > > src/GPhoto.vala src/SortedList.vala > > src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala > > src/Photo.vala src/Orientation.vala src/util.vala > > src/BatchImport.vala src/Dialogs.vala src/Resources.vala > > src/Debug.vala src/Sidebar.vala src/ColorTransformation.vala > > src/EditingTools.vala src/DataObject.vala > > src/DataCollection.vala src/LibraryWindow.vala > > src/CameraTable.vala src/DirectWindow.vala src/Properties.vala > > src/CustomComponents.vala src/Config.vala src/Event.vala > > src/International.vala src/Workers.vala src/system.vala > > src/AppDirs.vala src/PixbufCache.vala src/WebConnectors.vala > > src/FacebookConnector.vala src/CommandManager.vala > > src/Commands.vala src/SlideshowPage.vala src/LibraryFiles.vala > > src/FlickrConnector.vala src/YandexConnector.vala src/Pr > > inting.vala src/Tag.vala src/TagPage.vala > > src/PicasaConnector.vala src/Screensaver.vala > > src/PhotoFileAdapter.vala src/PhotoFileFormat.vala > > src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala > > src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala > > src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala > > src/Exporter.vala src/DirectoryMonitor.vala > > src/LibraryMonitor.vala src/OfflinePage.vala > > src/LastImportPage.vala src/AlienDatabase.vala > > src/AlienDatabaseImportJob.vala > > src/AlienDatabaseImportDialog.vala > > src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala > > src/VideoSupport.vala src/VideosPage.vala src/Tombstone.vala > > src/MetadataWriter.vala src/Application.vala > > src/TimedQueue.vala src/MediaPage.vala > > > warning: D-Bus GLib is deprecated, use GDBus > > > src/GdkSupport.vala:86.17-86.55: error: 1 extra arguments > > for `bool Gdk.PixbufLoader.write (uint8[] buf)' > > > pixbuf_loader.write(buffer, bytes_read); > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/Workers.vala:427.36-427.70: error: Argument 2: Cannot > > convert from `BackgroundJob.priority_compare_func' to > > `GLib.CompareDataFunc' > > > queue.push_sorted(job, > > BackgroundJob.priority_compare_func); > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:255.72-255.85: error: Argument 3: > > Cannot convert from `string?' to `uint8[]' > > > message.set_request(payload_content_type, > > Soup.MemoryUse.COPY, custom_payload, > > > > > ^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:372.17-372.31: error: Argument 3: > > Cannot convert from `string?' to `uint8[]' > > > formdata_string, formdata_string.length); > > > ^^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:497.37-497.102: error: 1 extra > > arguments for `void Soup.Buffer.new (Soup.MemoryUse use, > > uint8[] data)' > > > Soup.Buffer bindable_data = new > > Soup.Buffer(Soup.MemoryUse.COPY, photo_data.data, > > data_length); > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/YandexConnector.vala:639.78-639.87: error: Argument 2: > > Cannot convert from `string?' to `uint8[]' > > > Soup.Buffer bindable_data = new > > Soup.Buffer(Soup.MemoryUse.COPY, photo_data, data_length); > > > > > ^^^^^^^^^^ > > > > > > ^^^^^^^^^^^^ > > > Compilation failed: 6 error(s), 115 warning(s) > > > make: *** [src/.stamp] Error 1 > > > bengt at lappis:~/Development/shotwell$ > > > > > > > -- > > With Regards > > > > Bengt Thuree > > bengt at thuree.com > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.zaftra.yorba.org > > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > -- > With Regards > > Bengt Thuree > bengt at thuree.com > > From bengt at thuree.com Tue Oct 19 23:38:16 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 20 Oct 2010 10:38:16 +1100 Subject: [Shotwell] Compile errors? In-Reply-To: References: <1287523496.9473.15.camel@lappis.thuree.com> <1287526599.9473.17.camel@lappis.thuree.com> Message-ID: <1287531496.9473.18.camel@lappis.thuree.com> Thanks, that did the trick :) /Bengt On Tue, 2010-10-19 at 15:25 -0700, Jim Nelson wrote: > Yes, that library requirement was added recently for Yandex photo > support. This should do the trick: > > $ sudo apt-get install libjson-glib-dev > > -- Jim > > On Tue, Oct 19, 2010 at 3:16 PM, Bengt Thuree > wrote: > Hi > > Worked much better... still some issues though :( > > > > cc -c `pkg-config --cflags atk gdk-2.0 gee-1.0 gtk+-2.0 > glib-2.0 libexif sqlite3 gexiv2 json-glib-1.0 gconf-2.0 > libgphoto2 libsoup-2.4 libxml-2.0 unique-1.0 webkit-1.0 > gudev-1.0 dbus-glib-1 gdk-x11-2.0 gstreamer-0.10 > gstreamer-base-0.10 gthread-2.0` -I./vapi > -D_PREFIX='"/home/bengt/unstable/shotwell"' -D_VERSION='"0.7.2 > +trunk"' -DGETTEXT_PACKAGE='"shotwell"' > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' `./libraw-config --cflags` -O2 -g -pipe -fPIC -DG_UDEV_API_IS_SUBJECT_TO_CHANGE -o src/main.o src/main.c > > Package json-glib-1.0 was not found in the pkg-config search > path. > > Perhaps you should add the directory containing > `json-glib-1.0.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'json-glib-1.0' found > > > /Bengt > > > On Tue, 2010-10-19 at 14:30 -0700, Jim Nelson wrote: > > Hi Bengt, > > > > Shotwell is not updated to work with Vala 0.11 (yet). See: > > http://trac.yorba.org/ticket/2638 > > > > We recommend using 0.10 for now. > > > > Thanks, > > > > -- Jim > > > > On Tue, Oct 19, 2010 at 2:24 PM, Bengt Thuree > > > wrote: > > Hi > > > > I have installed latest Vala (0.11) and libgee > (0.6.0) > > and am getting the following errors when I am > compiling. > > > > Am I using a to late Vala or? > > > > I have also an up to date shotwell version > > bengt at lappis:~/Development/shotwell$ svn update > > At revision 2303. > > > > /Bengt > > > bengt at lappis:~/Development/shotwell$ make > > > mkdir -p src > > > valac --ccode --directory=src --basedir=src -g > > --enable-checking --thread \ > > > --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 > --pkg=gtk+-2.0 > > --pkg=glib-2.0 --pkg=libexif --pkg=sqlite3 > --pkg=gexiv2 > > --pkg=json-glib-1.0 --pkg=gconf-2.0 --pkg=libgphoto2 > > --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0 > > --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 > > --pkg=gdk-x11-2.0 --pkg=gstreamer-0.10 > > --pkg=gstreamer-base-0.10 --pkg=ExtendedPosix > --pkg=posix > > --pkg=LConv --pkg=libraw \ > > > --vapidir=./vapi \ > > > -X > -D_PREFIX='"/home/bengt/unstable/shotwell"' -X > > -D_VERSION='"0.7.2+trunk"' -X > -DGETTEXT_PACKAGE='"shotwell"' > > -X > > > -D_LANG_SUPPORT_DIR='"/home/bengt/unstable/shotwell/share/locale"' \ > > > -X -I./vapi \ > > > \ > > > src/main.vala src/AppWindow.vala > > src/CollectionPage.vala src/Thumbnail.vala > > src/DatabaseTables.vala src/ThumbnailCache.vala > > src/image_util.vala src/CheckerboardLayout.vala > > src/PhotoPage.vala src/Page.vala src/ImportPage.vala > > src/GPhoto.vala src/SortedList.vala > > src/EventsDirectoryPage.vala src/Dimensions.vala > src/Box.vala > > src/Photo.vala src/Orientation.vala src/util.vala > > src/BatchImport.vala src/Dialogs.vala > src/Resources.vala > > src/Debug.vala src/Sidebar.vala > src/ColorTransformation.vala > > src/EditingTools.vala src/DataObject.vala > > src/DataCollection.vala src/LibraryWindow.vala > > src/CameraTable.vala src/DirectWindow.vala > src/Properties.vala > > src/CustomComponents.vala src/Config.vala > src/Event.vala > > src/International.vala src/Workers.vala > src/system.vala > > src/AppDirs.vala src/PixbufCache.vala > src/WebConnectors.vala > > src/FacebookConnector.vala src/CommandManager.vala > > src/Commands.vala src/SlideshowPage.vala > src/LibraryFiles.vala > > src/FlickrConnector.vala src/YandexConnector.vala > src/Pr > > inting.vala src/Tag.vala src/TagPage.vala > > src/PicasaConnector.vala src/Screensaver.vala > > src/PhotoFileAdapter.vala src/PhotoFileFormat.vala > > src/PhotoFileSniffer.vala src/PhotoMetadata.vala > src/GRaw.vala > > src/GdkSupport.vala src/JfifSupport.vala > src/RawSupport.vala > > src/MimicManager.vala src/TrashPage.vala > src/PngSupport.vala > > src/Exporter.vala src/DirectoryMonitor.vala > > src/LibraryMonitor.vala src/OfflinePage.vala > > src/LastImportPage.vala src/AlienDatabase.vala > > src/AlienDatabaseImportJob.vala > > src/AlienDatabaseImportDialog.vala > > src/FSpotDatabaseDriver.vala > src/FSpotDatabaseTables.vala > > src/VideoSupport.vala src/VideosPage.vala > src/Tombstone.vala > > src/MetadataWriter.vala src/Application.vala > > src/TimedQueue.vala src/MediaPage.vala > > > warning: D-Bus GLib is deprecated, use GDBus > > > src/GdkSupport.vala:86.17-86.55: error: 1 extra > arguments > > for `bool Gdk.PixbufLoader.write (uint8[] buf)' > > > pixbuf_loader.write(buffer, > bytes_read); > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/Workers.vala:427.36-427.70: error: Argument 2: > Cannot > > convert from `BackgroundJob.priority_compare_func' > to > > `GLib.CompareDataFunc' > > > queue.push_sorted(job, > > BackgroundJob.priority_compare_func); > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:255.72-255.85: error: > Argument 3: > > Cannot convert from `string?' to `uint8[]' > > > message.set_request(payload_content_type, > > Soup.MemoryUse.COPY, custom_payload, > > > > > ^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:372.17-372.31: error: > Argument 3: > > Cannot convert from `string?' to `uint8[]' > > > formdata_string, > formdata_string.length); > > > ^^^^^^^^^^^^^^^ > > > src/WebConnectors.vala:497.37-497.102: error: 1 > extra > > arguments for `void Soup.Buffer.new (Soup.MemoryUse > use, > > uint8[] data)' > > > Soup.Buffer bindable_data = new > > Soup.Buffer(Soup.MemoryUse.COPY, photo_data.data, > > data_length); > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > src/YandexConnector.vala:639.78-639.87: error: > Argument 2: > > Cannot convert from `string?' to `uint8[]' > > > Soup.Buffer bindable_data = new > > Soup.Buffer(Soup.MemoryUse.COPY, photo_data, > data_length); > > > > > ^^^^^^^^^^ > > > > > > > ^^^^^^^^^^^^ > > > Compilation failed: 6 error(s), 115 warning(s) > > > make: *** [src/.stamp] Error 1 > > > bengt at lappis:~/Development/shotwell$ > > > > > > > -- > > With Regards > > > > Bengt Thuree > > bengt at thuree.com > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.zaftra.yorba.org > > > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > -- > > With Regards > > Bengt Thuree > bengt at thuree.com > > > -- With Regards Bengt Thuree bengt at thuree.com From jani at ubuntu.com Wed Oct 20 21:49:25 2010 From: jani at ubuntu.com (Jani Monoses) Date: Thu, 21 Oct 2010 00:49:25 +0300 Subject: [Shotwell] miscompilation? In-Reply-To: References: Message-ID: On 10/16/2010 05:19 PM, Jani Monoses wrote: > Hello > > I am using Ubuntu 10.10 and Shotwell trunk. > Whenever I try to rate or rename a photo it segfaults. FYI this has been fixed in trunk. http://trac.yorba.org/ticket/2710 From gilliy at gmx.de Thu Oct 21 05:40:00 2010 From: gilliy at gmx.de (grantio) Date: Wed, 20 Oct 2010 22:40:00 -0700 (PDT) Subject: [Shotwell] PhotoMetadata Message-ID: <1287639600657-24489.post@talk.nabble.com> I am completely new to shotwell. I already tried different tools as I am an interested free-time photographer. I really love this tool, as it is fast, it supports tags, which I think is really important due to more and more increasing numbers of photos and last but absolutley not least it looks good and has a nice feel. I am wondering if you considered already to let the user choose which MetaData from the EXIF Info he wants to be seen in the basic and the extended property window. I think by default these choice is not the best, at least not for me. Are there any easy possibilites, otherwise I was thinking of modifying the entries on my own, so that I see the important entries at once. The following entries are the most important for me. Location: Camera model: Flash: Focus Mode: AF Area Mode: Focal Length: Exposure Time: Exposure bias: Aperture Value: ISO: Lens Type: Thank you in advance and thank you very much for this nice kind of software. Gregor -- View this message in context: http://shotwell.3510.www.nabble.com/PhotoMetadata-tp24489p24489.html Sent from the Shotwell mailing list archive at Nabble.com. From nicolas at toromanoff.org Fri Oct 22 09:14:34 2010 From: nicolas at toromanoff.org (nicolas at toromanoff.org) Date: Fri, 22 Oct 2010 11:14:34 +0200 Subject: [Shotwell] Export to gallery: ticket #1585 Message-ID: Hello, I am a newcomer on the mailing-list and Shotweel (thanks to Ubuntu 10.10) But I need an export to Gallery2 in Shotweel, as it is the feature of F-Spot I used the most. And I liked the soft enough to start to code it. ;-) Is there anybody else who is working on this ? Didn't find any clue in the ML archive, nor in the ticket http://trac.yorba.org/ticket/1585. Knowing I am starting Vala, never code yet any gnome app, I am not sure the code will be as clean as it should be. (but I write C since a longer time) I read http://trac.yorba.org/wiki/ShotwellArchitectureOverview then took inspiration from [Picasa|Flickr]Connector.vala to create a GalleryConnector.vala. Already able to connect to my gallery and fetch the albums list. To do : * save login/password/gallery_name/gallery_url in Config * parse the album list return by Gallery * create the windows to select/create a destination album * creation of a new album * upload selected photos to an album * *clean first vala code I write.* I don't need it, but nice to have (not sure I'll have time to code it): * gallery1 protocol * gallery3 protocol Hope to work on shotwell next week-end, and have a first version able to upload in an already exiting album in a near future. Any advice to be sure not duplicate any work ? Regards, Nicolas. From jim at yorba.org Fri Oct 22 20:26:18 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 22 Oct 2010 13:26:18 -0700 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: <1287689373.29983.28.camel@kusanagi> References: <1286853385.754.16.camel@kusanagi> <1287689373.29983.28.camel@kusanagi> Message-ID: > > Yes. The Escape key (and only that key) works in the following scenario: > exiting from a "single image view" to go back to the event/gallery view. > However, > - This doesn't work to go from an event --> the month, or the month --> the > year, or the year --> Events. In other words, this doesn't allow you to go > "up" indefinitely in the hierarchy. > - The backspace and alt-left keys don't work, it might be nice having them > too (for increased consistency with some other apps) > > Right. The question I have is, if we were to increase the navigational features of Shotwell, should we follow a file manager model or a web browser model (or, like Nautilus, offer a hybrid)? A "traditional" file manager navigation model is to offer movement up and down the directory tree (and laterally too, come to think of it). I think that's what you're suggesting in your first bullet point. However, Shotwell can also be seen (and indeed is modeled this way internally) as a collection of pages the user can move through in random order (via the sidebar or a "link" on the page, i.e. double-clicking on an event item to move to that event). In a web browser model, you would have forward and backward buttons to move through pages you've viewed in that order. A hybrid model (like Nautilus) would be to combine the back-and-forth of browsing pages with an up key to move through the tree. In all of these cases, we have to deal with other navigation features, especially the full-window page (i.e. the image viewer). It would mean having two forward and backward functions: one to move through the photos of the page you just came from, and the other to move through the pages themselves. These are some of the thoughts I've had about improving navigation in Shotwell, if we were to go that route. > > Some more thoughts today: > I'm also wondering what the target userbase of Shotwell is. Is it pro > photographers, mom & pop, or both? If it targets mom and pop, I'd recommend > having the following additional buttons in the toolbar (shown/hidden > depending on the context): > > The dream is that mom & pop can sit down and immediately be productive with Shotwell, but as we add more advanced features, power users can "unlock" them in various ways. It's a dream, at least. > - Go back ("Go back to the list of photos"); this button is shown when you > are in the "view mode" of a photo, and is the same thing as pressing Escape > (except that it's discoverable) > This is possible. We used to have a menu item for this but removed it. I've ticketed this for re-consideration: http://trac.yorba.org/ticket/2719 > - View/edit; this button is shown when you're in an event view and want to > see a particular photo/edit it full size. This may sound silly, but > double-clicks can be hard to discover/remember for non-geeks, according to > my observations over the years (with f-spot, nautilus, evolution, for > example). > That's possible, but I have to wonder if people are really that confused by this (and need a button). For example, Nautilus doesn't have a "launch" or "open" button, but people understand to double-click to open a program or a document. > - Rename; shown in library/year/month view to rename an event (just besides > the Merge button), since it's an often-used action. Do not assume users will > use the right-click or menus spontaneously :) > > This one I could see, because you're right, this is something people will want to do a lot. Also, we have plenty of room on the Event Directory toolbar: http://trac.yorba.org/ticket/2721 > > Finally: do you have a particular reason why the photo toolbar is at the > bottom instead of at the top? There are two problems with this: > This was a conscious decision on our part. We realize it violates HIG but went with it anyway for one of the reasons you mentioned: the human gaze moves upward. As a photo app, we felt people are more interested in seeing their photos than our toolbar and wanted to put them up higher. I know I'm biased, but I actually feel this when I use other photo/image apps -- I feel like the toolbar is crowding out the photos, which are the things I'm more interested in. -- Jim From simonspa at kth.se Sat Oct 23 00:22:11 2010 From: simonspa at kth.se (Simon Spannagel) Date: Sat, 23 Oct 2010 02:22:11 +0200 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: References: <1286853385.754.16.camel@kusanagi> <1287689373.29983.28.camel@kusanagi> Message-ID: <4CC22AB3.2040207@kth.se> Am 22.10.2010 22:26, schrieb Jim Nelson: > I know I'm biased, but I actually feel this when I use other > photo/image apps -- I feel like the toolbar is crowding out the > photos, which are the things I'm more interested in. This is actually really correct - I just realized now what the "makes a good feeling" thing is in shotwell: you are always focused on the photos, nothing bothers you. That is a problem I have with many photo galleries / managers: they look more like a manager application than like my pictures... Keep it this way - this is really great. cheers, Simon From nicolas at toromanoff.org Mon Oct 25 07:47:13 2010 From: nicolas at toromanoff.org (nicolas at toromanoff.org) Date: Mon, 25 Oct 2010 09:47:13 +0200 Subject: [Shotwell] Export to gallery: ticket #1585 Message-ID: <589039c0bf74cdfc7c8c455b0de65850.squirrel@ntoroman.dyndns.org> Hello, > To do : > * save login/password/gallery_name/gallery_url in Config done (but remove the gallery_name: useless) > * parse the album list return by Gallery done > * create the windows to select/create a destination album selection reuse the Picasa one, but need some update. > * creation of a new album > * upload selected photos to an album > * *clean first vala code I write.* I was not as productive as i expected to be. Still not able to upload a photo. The Gallery2 protocol is not very complicated (even if I didn't understand yet the way to upload the photo, but I hope for the best) I have one issue I don't understand (from my code, but I don't know why nor where) : Shouldn't the Session save the session, I mean storing cookie or anything else to save the actual connection session ? Because I POST or GET the correct command to login (http://gallery.example/gallery/main.php?g2_controller=remote:GalleryRemote&g2_form[cmd]=login&g2_form[uname]=uname&g2_form[password]=password ), received the correct response. Then if I call, with same session, a new command (a fetch_directory pe.) with a correct auth_token, I should be still connected: but the answer identify the caller as the guest user. >From a browser I only have to open the login URL, then open the fetch_directory URL (even without the auth_token), and it is enough, I get the directory list identified as the logged user. So is using the same session enough ? Or can I in some way corrupt the session values ? Nicolas. From jani at ubuntu.com Mon Oct 25 10:09:22 2010 From: jani at ubuntu.com (Jani Monoses) Date: Mon, 25 Oct 2010 13:09:22 +0300 Subject: [Shotwell] Export to gallery: ticket #1585 In-Reply-To: <589039c0bf74cdfc7c8c455b0de65850.squirrel@ntoroman.dyndns.org> References: <589039c0bf74cdfc7c8c455b0de65850.squirrel@ntoroman.dyndns.org> Message-ID: On 10/25/2010 10:47 AM, nicolas at toromanoff.org wrote: > Hello, > >> To do : >> * save login/password/gallery_name/gallery_url in Config > done (but remove the gallery_name: useless) >> * parse the album list return by Gallery > done >> * create the windows to select/create a destination album > selection reuse the Picasa one, but need some update. >> * creation of a new album >> * upload selected photos to an album >> * *clean first vala code I write.* > > I was not as productive as i expected to be. > Still not able to upload a photo. > > The Gallery2 protocol is not very complicated (even if I didn't understand > yet the way to upload the photo, but I hope for the best) F-spot supports Gallery so maybe looking at how they do it helps http://git.gnome.org/browse/f-spot/tree/src/Extensions/Exporters/FSpot.Exporters.Gallery/FSpot.Exporters.Gallery?id=0.8.0 From maciej.rumianowski at gmail.com Mon Oct 25 17:36:01 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Mon, 25 Oct 2010 19:36:01 +0200 Subject: [Shotwell] Mailing list change? Message-ID: <1288028161.2181.19.camel@maciej-netbook> Why the email address has changed and mails get lost in the way to subscribers. I have also found that archive has wrong address it is http://lists.zaftra.yorba.org/pipermail/shotwell/ but http://lists.yorba.org/pipermail/shotwell/ is good. Cheers, Maciek From toroklev at gmail.com Sat Oct 16 17:06:06 2010 From: toroklev at gmail.com (Levente Torok) Date: Sat, 16 Oct 2010 19:06:06 +0200 Subject: [Shotwell] feature request: title just like in picasa In-Reply-To: <1287008343.2105.6.camel@antiloop> References: <4CB5E708.30303@yorba.org> <1287008343.2105.6.camel@antiloop> Message-ID: I think there should be three possibilities: 1. Clicking on the title (should it select all or not?) 2. Pressing a shortcut like Ctrl+T or simply t 3. Title bar could end with a little tick "Batch Title mode", in which Page Up/Down and Enter would change pictures and title would always be active for directly typing. Mattias -------------------- Hi Guys, In my special view the purpose of F-spot (and shotwell) is to replace picasa client to some extent in linux and other platforms. So I suggest checking the use cases in that first. I thing Mattias explanation is something that I like. On the other hand, for some reasons I dont like facebook type of batch title generation. I guess the thing I dont like is the fact that in the editing mode I need to have an image in my head what the output ( in viewing mode ) will look like. But it is totally subjective since it depends very much on the type of photographies for which I am generating the titles. Cheers, Lev From sil at kryogenix.org Sat Oct 23 21:56:49 2010 From: sil at kryogenix.org (Stuart Langridge) Date: Sat, 23 Oct 2010 22:56:49 +0100 Subject: [Shotwell] Importing my existing Pictures folder Message-ID: <1287871009.3964.3.camel@giles> Shotwell uses my Pictures folder to store pictures, which is excellent. However, I already *have* a bunch of pictures in my Pictures folder; that's where I currently store all my images. (I don't currently use a photo manager at all.) I'm worried about how I'm meant to handle this situation with Shotwell 0.7 (in Ubuntu 10.10). Should I tell it to copy the files (from the Pictures folder into...the Pictures folder?) Load them in place without copying them? What happens if I do that and then Shotwell 0.8 starts auto-importing things already in my Pictures folder? Will I get them twice? I'm a bit confused... sil From nekohayo at gmail.com Thu Oct 21 19:29:33 2010 From: nekohayo at gmail.com (Jeff Fortin) Date: Thu, 21 Oct 2010 15:29:33 -0400 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: References: <1286853385.754.16.camel@kusanagi> Message-ID: <1287689373.29983.28.camel@kusanagi> > Fourth, there should probably be a "go back" button and > shortcut keys > (ex: backspace/alt+left/escape) to go back to the previous > view (go back > from a photo to its event, from the event to the month, from > the month > to the year, etc.). > > > > We do already have some notion of "go back" when you're viewing a > photo. If you press Escape, you'll go to the view you were in when > you double-clicked the image. Are you suggesting something beyond > this? Yes. The Escape key (and only that key) works in the following scenario: exiting from a "single image view" to go back to the event/gallery view. However, - This doesn't work to go from an event --> the month, or the month --> the year, or the year --> Events. In other words, this doesn't allow you to go "up" indefinitely in the hierarchy. - The backspace and alt-left keys don't work, it might be nice having them too (for increased consistency with some other apps) Some more thoughts today: I'm also wondering what the target userbase of Shotwell is. Is it pro photographers, mom & pop, or both? If it targets mom and pop, I'd recommend having the following additional buttons in the toolbar (shown/hidden depending on the context): - Go back ("Go back to the list of photos"); this button is shown when you are in the "view mode" of a photo, and is the same thing as pressing Escape (except that it's discoverable) - View/edit; this button is shown when you're in an event view and want to see a particular photo/edit it full size. This may sound silly, but double-clicks can be hard to discover/remember for non-geeks, according to my observations over the years (with f-spot, nautilus, evolution, for example). - View; this button is shown in library view/year view/month view to "enter" an event (again due to the problem of double click). - Rename; shown in library/year/month view to rename an event (just besides the Merge button), since it's an often-used action. Do not assume users will use the right-click or menus spontaneously :) Finally: do you have a particular reason why the photo toolbar is at the bottom instead of at the top? There are two problems with this: 1- http://library.gnome.org/devel/hig-book/stable/toolbars-appearance.html the HIG recommends putting toolbars "directly below the main menu bar". In our case it would probably be shown not "directly below", but still above of the image canvas (since the toolbar does not affect items in the sidebar) 2- gtk tooltips often don't appear correctly (they show offscreen) when the toolbar is at the bottom and Shotwell is maximized. Bad for usability. 3- consistency with other applications, and the fact that the human gaze tends towards the top of the application to find toolbars, and the fact that my mouse spends the most of its time in the upper part of the screen. From nekohayo at gmail.com Sat Oct 23 00:12:17 2010 From: nekohayo at gmail.com (Jeff Fortin) Date: Fri, 22 Oct 2010 20:12:17 -0400 Subject: [Shotwell] Feedback and ideas: deleting events, saving EXIF rotation, etc. In-Reply-To: References: <1286853385.754.16.camel@kusanagi> <1287689373.29983.28.camel@kusanagi> Message-ID: <1287792737.23528.7.camel@kusanagi> > Right. The question I have is, if we were to increase the > navigational features of Shotwell, should we follow a file manager > model or a web browser model (or, like Nautilus, offer a hybrid)? I guess that the mere fact that there is a sidebar that allows jumping to any position makes it a hybrid model as it is not purely linear. Add to that a "Go back" button that goes back to the previous view (in most cases, that means the "parent" view) and you get the best of both worlds? > That's possible, but I have to wonder if people are really that > confused by this (and need a button). For example, Nautilus doesn't > have a "launch" or "open" button, but people understand to > double-click to open a program or a document. Except that Nautilus allows using it in single-click mode (this is how I have set it up for every non-computer-savy user whose computer I maintain; this is even how I use it, myself) > This was a conscious decision on our part. We realize it violates HIG > but went with it anyway for one of the reasons you mentioned: the > human gaze moves upward. As a photo app, we felt people are more > interested in seeing their photos than our toolbar and wanted to put > them up higher. I know I'm biased, but I actually feel this when I > use other photo/image apps -- I feel like the toolbar is crowding out > the photos, which are the things I'm more interested in. Hm, quite an interesting perspective. But then, aren't you similarly annoyed by other content-centric apps that have toolbars on top (like office suites, tomboy/gnote, inkscape, audio editors, etc.? It's kind of a tradition across the desktop, so you need solid reasons to break consistency, I guess. My 2?. From vperetokin at gmail.com Mon Oct 25 19:10:16 2010 From: vperetokin at gmail.com (Vadim Peretokin) Date: Mon, 25 Oct 2010 15:10:16 -0400 Subject: [Shotwell] Importing my existing Pictures folder In-Reply-To: <1287871009.3964.3.camel@giles> References: <1287871009.3964.3.camel@giles> Message-ID: I second that slight confusion there - what happens if they're already all in Pictures? The UI needs to be more clear / intuitive about this. From hendry.michael at gmail.com Sat Oct 16 00:04:24 2010 From: hendry.michael at gmail.com (Michael Hendry) Date: Sat, 16 Oct 2010 01:04:24 +0100 Subject: [Shotwell] RFC - option to force Import to overwrite originals by [Shotwell-perceived] duplicates In-Reply-To: References: <1286915806.1707.55.camel@Linley6> <87sk0a1r8k.fsf@SSpaeth.de> <1286961217.1711.30.camel@Linley6> <87fwwaqoue.fsf@SSpaeth.de> <1286975866.1711.41.camel@Linley6> Message-ID: <1287187464.2091.48.camel@Linley6> On Thu, 2010-10-14 at 12:05 -0700, Jim Nelson wrote: > There's a number of different issues and problems in play here, and > I'm afraid they're all being conflated under the banner of "duplicate > detection". It's important to understand at least a couple of basic > concepts. Thanks for the clarification, Jim - see my interpolated comments below: > > First, in regards to a file that is twice the size of another being > regarded as a duplicate, that is most likely due to this bug: > http://trac.yorba.org/ticket/2587 It was an oversight on my part and > I would like to fix this for 0.8. Excellent. > > Now, beyond that, there are three kinds of duplicate detection (that > banner I was mentioning before): > > 1. The same filepath: If you import /home/jim/photo.jpg and then > import again /home/jim/photo.jpg, Shotwell will treat that as a > duplicate. This is a special case of duplicate detection; Shotwell > will not allow you to have two photo "objects" in your library > pointing to the same file. Note that this is true even if you > update/change the file outside of Shotwell, i.e. modify its EXIF. > Shotwell 0.7 does *not* detect external changes and update the > library. > > Shotwell 0.8, on the other hand, will do that exact thing by detecting > the change at startup: http://trac.yorba.org/ticket/2476 If I understand this correctly, in Shotwell 0.8 it will be necessary to close Shotwell and open it again if one of the files is changed (in my case, if I change the date-stamp in the EXIF data) - an attempt to import that file again will still be seen as an attempt to import a duplicate because the file has the same name, but all will be well the next time I start Shotwell. > > 2. The same file contents: If two photos are byte-for-byte identical, > they are considered duplicates and Shotwell will only import one of > them. This comparison is of the entire file; changing the EXIF in one > is enough to make the files different. Precisely what I was expecting from duplicate detection. > > 3. The same file on camera and on disk: Camera import introduces a > problem. Because it takes so long to download a file and it's > desirable to be able to see which photos you've already imported > before importing them, we want to detect duplicates before pulling > down the file. We do this by comparing the photo thumbnails (which is > what led to that bug I mentioned at the top of this message). > Otherwise, we would download the file, compare it to the library, > realize it was a duplicate, and then delete the file. > OK - I found this useful today after I'd failed to delete image files I'd already downloaded from my camera. I think I'd prefer to have the option of overwriting the already-downloaded images, though. > Now, apart from all this, the trash can creates a special case. If > you move a photo to the trash and then import a file that is a > duplicate -- i.e. is either the same filepath OR the same contents -- > Shotwell will restore the photo object from the trash and not import > the new file. (In the case of the same filepath, that's essentially > what you're asking for.) We assume if you import a duplicate file, > you're saying "You know what, I want this photo after all," and we > restore it from the trash. It's also restoring all the stuff you've > done to it while it was in Shotwell, i.e. its tags, transformations, > and so on. We see this as valuable stuff to be preserving. > I hear what you're saying, but I have to say I find its implementation in practice totally counterintuitive! If I had put something in the wastebasket and then realised I wanted it after all, I would take it out of the wastebasket myself. I agree that transferring the tags associated with the original file would be helpful - this could be implemented as a dialog box asking something like: Importing file with same name and path - keep tags? [yes]...[yes to all]...[no]...[no to all] > This is all quite distinct from a different operation we refer to as > "re-import": To take an existing photo in the library and re-examine > all its properties and reflect any changes in the database > (thumbnails, tags, etc.). I think what Michael is asking for when > importing a file already in the trash is for Shotwell to re-import it. > In 0.8 we're attacking the problem slightly differently, but detecting > the change automatically and re-importing it in the background. But > 0.7 does not have this capability in any manner. Yes, I think 0.8 will deal with my complaints. How will it handle the preservation of tags when it discovers a changed file on startup? And how about the case of a changed file which at some stage been edited via Shotwell? My preference would be to transfer the tags and drop the edit trail. > > I know this is a lot to absorb, but I feel like some concepts and > terms are being muddied. Some of it is my own fault, as we're trying > to keep it simple for users, and some of it is due to a bug that's > being grouped in as a part of designed behavior. By being aware of > the different cases of "duplicate detection", I think we can figure > what is useful, what can be tweaked, and what needs to be changed. > > -- Jim > "Duplicate" means "identical" to me - you can't have shades of duplicate-ness. If the process of checking a potential duplicate is going to take a long time, then the user should be given the option to abort or continue. Michael From vera at yorba.org Mon Oct 25 19:26:46 2010 From: vera at yorba.org (Vera Yin) Date: Mon, 25 Oct 2010 12:26:46 -0700 Subject: [Shotwell] Mailing list change? In-Reply-To: <1288028161.2181.19.camel@maciej-netbook> References: <1288028161.2181.19.camel@maciej-netbook> Message-ID: Thank you for pointing out this problem. We made a server change recently and hadn't updated some resources to reflect the new host names. This has now been fixed. The correct address for the Shotwell mailing list is shotwell at lists.yorba.org as before. There was a backlog of Shotwell mailing lists emails that just went out. Please let me know if you feel that any other mail, such as messages you posted to the list, has not gone through. Thanks, Vera On Mon, Oct 25, 2010 at 10:36 AM, Maciej Rumianowski wrote: > Why the email address has changed and mails get lost in the way to > subscribers. > > I have also found that archive has wrong address it is > http://lists.zaftra.yorba.org/pipermail/shotwell/ but > http://lists.yorba.org/pipermail/shotwell/ is good. > > > Cheers, > Maciek > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.zaftra.yorba.org > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > From maciej.rumianowski at gmail.com Mon Oct 25 19:32:19 2010 From: maciej.rumianowski at gmail.com (Maciej Rumianowski) Date: Mon, 25 Oct 2010 21:32:19 +0200 Subject: [Shotwell] Mailing list change? In-Reply-To: References: <1288028161.2181.19.camel@maciej-netbook> Message-ID: <1288035139.2181.37.camel@maciej-netbook> Everything alright:) Thanks, Maciek Dnia 2010-10-25, pon o godzinie 12:26 -0700, Vera Yin pisze: > Thank you for pointing out this problem. We made a server change > recently and hadn't updated some resources to reflect the new host > names. This has now been fixed. > > The correct address for the Shotwell mailing list is > shotwell at lists.yorba.org as before. > > There was a backlog of Shotwell mailing lists emails that just went > out. Please let me know if you feel that any other mail, such as > messages you posted to the list, has not gone through. > > Thanks, > Vera > > On Mon, Oct 25, 2010 at 10:36 AM, Maciej Rumianowski > wrote: > > Why the email address has changed and mails get lost in the way to > > subscribers. > > > > I have also found that archive has wrong address it is > > http://lists.zaftra.yorba.org/pipermail/shotwell/ but > > http://lists.yorba.org/pipermail/shotwell/ is good. > > > > > > Cheers, > > Maciek > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.zaftra.yorba.org > > http://lists.zaftra.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From jim at yorba.org Mon Oct 25 22:35:53 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 25 Oct 2010 18:35:53 -0400 Subject: [Shotwell] Importing my existing Pictures folder In-Reply-To: References: <1287871009.3964.3.camel@giles> Message-ID: This is something we've been made aware of before and would like to correct it. Here's the ticket: http://trac.yorba.org/ticket/2729 (Actually, it was you that mentioned it to us Stuart, just last night. No wonder I thought I'd heard this so recently! Another beer, please.) Shotwell has a shunt inside the import code: if a file is already in the Pictures directory, it will never be copied, even if the user selects Copy instead of Link. So, no worries. It's not totally straightforward to detect this situation and avoid the confusion, but we should at least attempt to. -- Jim On Mon, Oct 25, 2010 at 3:10 PM, Vadim Peretokin wrote: > I second that slight confusion there - what happens if they're already all > in Pictures? The UI needs to be more clear / intuitive about this. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From kreckel at ginac.de Wed Oct 27 07:19:26 2010 From: kreckel at ginac.de (Richard B. Kreckel) Date: Wed, 27 Oct 2010 09:19:26 +0200 Subject: [Shotwell] compilation problem Message-ID: <4CC7D27E.9060401@ginac.de> Hi, I'm interested in the movie import feature and so I tried compiling the subversion trunk on a Debian/squeeze system. I updated some packages (vala 0.10.0, exiv2 0.2.0, GExiv2 0.2.0) but compilation failed with this: warning: D-Bus GLib is deprecated, use GDBus src/WebConnectors.vala:497.74-497.88: error: The name `data' does not exist in the context of `string?' Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, photo_data.data, data_length); ^^^^^^^^^^^^^^^ src/LibraryWindow.vala:715.38-715.50: error: The name `NONE' does not exist in the context of `Gdk.Atom' if (((int) target) == ((int) Gdk.Atom.NONE)) { ^^^^^^^^^^^^^ Compilation failed: 2 error(s), 1 warning(s) Does anybody have a idea what's going on? -richy. -- Richard B. Kreckel From roy.nico at free.fr Wed Oct 27 09:01:27 2010 From: roy.nico at free.fr (nicolas roy) Date: Wed, 27 Oct 2010 11:01:27 +0200 Subject: [Shotwell] creating events named after subfolders, while importing Message-ID: <4CC7EA67.3060303@free.fr> Hello, everybody. I discovered shotweel a few days ago, and i find it very nice, simple and efficient. I would like to make it my default Photo organizer, but i'm wondering about the following : i have a 6-years collection of photos, which i organized up to now according in an "old-style" way, namely, i did not use any "event" or "Tag", they are just stored in folders, with the name of an event : Photos/2009/my_birthday Photos/2010/summer_hollydays and so on. Would it be possible to import my whole collection, and let Shotwell automatically create an event for each of the folders ? I really don't want to create them manually, there are tow many of them. Thanks nicolas From jim at yorba.org Wed Oct 27 12:53:52 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 27 Oct 2010 08:53:52 -0400 Subject: [Shotwell] compilation problem In-Reply-To: <4CC7D27E.9060401@ginac.de> References: <4CC7D27E.9060401@ginac.de> Message-ID: These are bindings problems. I suspect you have old .vapi files on your system somewhere that the Vala compiler is using. (These bindings changed a while back.) I would uninstall 0.10 and recursively scan your /usr directory for any remaining .vapi files. gexiv2 and Gee install VAPIs, so those should not be deleted, but any GDK or GLib vapis you see after that should be removed. Then reinstall 0.10.0. -- Jim On Wed, Oct 27, 2010 at 3:19 AM, Richard B. Kreckel wrote: > Hi, > > I'm interested in the movie import feature and so I tried compiling the > subversion trunk on a Debian/squeeze system. I updated some packages (vala > 0.10.0, exiv2 0.2.0, GExiv2 0.2.0) but compilation failed with this: > > warning: D-Bus GLib is deprecated, use GDBus > src/WebConnectors.vala:497.74-497.88: error: The name `data' does not exist > in the context of `string?' > Soup.Buffer bindable_data = new Soup.Buffer(Soup.MemoryUse.COPY, > photo_data.data, data_length); > > ^^^^^^^^^^^^^^^ > src/LibraryWindow.vala:715.38-715.50: error: The name `NONE' does not exist > in the context of `Gdk.Atom' > if (((int) target) == ((int) Gdk.Atom.NONE)) { > ^^^^^^^^^^^^^ > Compilation failed: 2 error(s), 1 warning(s) > > Does anybody have a idea what's going on? > > -richy. > -- > Richard B. Kreckel > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Oct 27 20:19:00 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 27 Oct 2010 16:19:00 -0400 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: <4CC7EA67.3060303@free.fr> References: <4CC7EA67.3060303@free.fr> Message-ID: Would you want Shotwell to convert your directory structure to events or for Shotwell to offer a view of your directory structure within the sidebar? We've been considering the latter: http://trac.yorba.org/ticket/1594 -- Jim On Wed, Oct 27, 2010 at 5:01 AM, nicolas roy wrote: > Hello, everybody. > > I discovered shotweel a few days ago, and i find it very nice, simple and > efficient. I would like to make it my default Photo organizer, but i'm > wondering > about the following : i have a 6-years collection of photos, which i > organized > up to now according in an "old-style" way, namely, i did not use any > "event" or > "Tag", they are just stored in folders, with the name of an event : > Photos/2009/my_birthday > Photos/2010/summer_hollydays > > and so on. Would it be possible to import my whole collection, and let > Shotwell > automatically create an event for each of the folders ? > I really don't want to create them manually, there are tow many of them. > > Thanks > > nicolas > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From kreckel at ginac.de Wed Oct 27 22:46:00 2010 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 28 Oct 2010 00:46:00 +0200 Subject: [Shotwell] compilation problem In-Reply-To: References: <4CC7D27E.9060401@ginac.de> Message-ID: <4CC8ABA8.40201@ginac.de> On 10/27/2010 02:53 PM, Jim Nelson wrote: > These are bindings problems. I suspect you have old .vapi files on your > system somewhere that the Vala compiler is using. (These bindings > changed a while back.) > > I would uninstall 0.10 and recursively scan your /usr directory for any > remaining .vapi files. gexiv2 and Gee install VAPIs, so those should > not be deleted, but any GDK or GLib vapis you see after that should be > removed. Then reinstall 0.10.0. Thanks a lot! (You know, I'm totally new to vala and didn't even know that declarations are in .vapi files.) It turned out that uninstalling Debian/sqeeze's valac package (this is version 0.8.1) solved the problem. Shotwell compiled fine then and works like a charm. What I find strange though is that the custom installation of vala 0.10.0 picked up files from the system's vala package (glib-2.0.vapi, for instance). Shouldn't vala know where to look for .vapi files? -richy. -- Richard B. Kreckel From simonspa at kth.se Thu Oct 28 01:58:53 2010 From: simonspa at kth.se (Simon Spannagel) Date: Thu, 28 Oct 2010 03:58:53 +0200 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: References: <4CC7EA67.3060303@free.fr> Message-ID: <4CC8D8DD.6010906@kth.se> Am 27.10.2010 22:19, schrieb Jim Nelson: > directory structure within the sidebar? > We've been considering the latter: http://trac.yorba.org/ticket/1594 > > -- Jim Ah, don't do that. In my opinion that would destroy the good and well-sorted experience the user gets - cause this folder view will always remind him how messed up his pictures are stored. I think you don't need this folder view in Shotwell - if one wants to browse the directories, one can still use his favourite file manager... Simon From roy.nico at free.fr Thu Oct 28 05:56:37 2010 From: roy.nico at free.fr (nicolas roy) Date: Thu, 28 Oct 2010 07:56:37 +0200 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: References: <4CC7EA67.3060303@free.fr> Message-ID: <4CC91095.6010800@free.fr> Hej. I meant the first option. Convert the directory structure once, and never use this again, and use rather the "event" feature of shotwell. I just don'T want to loose several years of classifying work of my old pictures... nico Le 27/10/2010 22:19, Jim Nelson a ?crit : > Would you want Shotwell to convert your directory structure to events > or for Shotwell to offer a view of your directory structure within the > sidebar? We've been considering the latter: > http://trac.yorba.org/ticket/1594 > > -- Jim > > On Wed, Oct 27, 2010 at 5:01 AM, nicolas roy > wrote: > > Hello, everybody. > > I discovered shotweel a few days ago, and i find it very nice, > simple and > efficient. I would like to make it my default Photo organizer, but > i'm wondering > about the following : i have a 6-years collection of photos, which > i organized > up to now according in an "old-style" way, namely, i did not use > any "event" or > "Tag", they are just stored in folders, with the name of an event : > Photos/2009/my_birthday > Photos/2010/summer_hollydays > > and so on. Would it be possible to import my whole collection, and > let Shotwell > automatically create an event for each of the folders ? > I really don't want to create them manually, there are tow many of > them. > > Thanks > > nicolas > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From el.cameleon.1 at gmail.com Thu Oct 28 07:07:26 2010 From: el.cameleon.1 at gmail.com (Vincent) Date: Thu, 28 Oct 2010 09:07:26 +0200 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: <4CC8D8DD.6010906@kth.se> References: <4CC7EA67.3060303@free.fr> <4CC8D8DD.6010906@kth.se> Message-ID: On Thu, Oct 28, 2010 at 3:58 AM, Simon Spannagel wrote: > > Am 27.10.2010 22:19, schrieb Jim Nelson: > > directory structure within the sidebar? >> We've been considering the latter: http://trac.yorba.org/ticket/1594 >> >> -- Jim >> > Ah, don't do that. (...) > Please, consider to do it because I want that my picture can be browse with other software that Shotwell. Having mess folder without name (only date) to store my photos make it very difficult to switch to another photo manager, or simply to find photos upload to UbuntuOne or archive on a DVD. From simonspa at kth.se Thu Oct 28 08:48:15 2010 From: simonspa at kth.se (Simon Spannagel) Date: Thu, 28 Oct 2010 10:48:15 +0200 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: References: <4CC7EA67.3060303@free.fr> <4CC8D8DD.6010906@kth.se> Message-ID: <4CC938CF.1000005@kth.se> Am 28.10.2010 09:07, schrieb Vincent: > On Thu, Oct 28, 2010 at 3:58 AM, Simon Spannagel wrote: > >> Am 27.10.2010 22:19, schrieb Jim Nelson: >> >> directory structure within the sidebar? >>> We've been considering the latter: http://trac.yorba.org/ticket/1594 >>> >>> -- Jim >>> >> Ah, don't do that. (...) >> > Please, consider to do it (...) This only comes if you use the Shotwell import function - this will not change in any sense if they implement a folder view pane. If you want this you should rather suggest "Please give a option to sort imported pictures by events in their folders" or similar. Cheers Simon From stephane.blondon at gmail.com Thu Oct 28 22:50:56 2010 From: stephane.blondon at gmail.com (=?UTF-8?Q?St=C3=A9phane_Blondon?=) Date: Fri, 29 Oct 2010 00:50:56 +0200 Subject: [Shotwell] bug: shotwell doesn't detect the camera but gphoto does it Message-ID: Hello everyone, If I plug a camera (fujifilm finepix AX200) with his USB port to the computer and execute shotwell, shotwell doesn't show the camera on the left column. - The camera is properly detected by the gPhoto2 binary. gPhoto can copy the files on the computer too. - The same behaviour occurs with gthumb (camera not found). You can find more details and logs about my gThumb attempt in the bug reports I sended to my distribution: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599736 Note that gphoto, gthumb and shotwell comes from the Debian testing packages. What could I do to understand better the problem and to try to fix it? (I have subscribed to the mailing list.) -- St?phane From jim at yorba.org Fri Oct 29 19:11:58 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 29 Oct 2010 12:11:58 -0700 Subject: [Shotwell] compilation problem In-Reply-To: <4CC8ABA8.40201@ginac.de> References: <4CC7D27E.9060401@ginac.de> <4CC8ABA8.40201@ginac.de> Message-ID: There's been some recent changes to where valac looks for vapis in recent releases, I believe to separate where standard distribution vapis are installed and vapis from other libraries. That's probably part of the problem you're seeing, but I'm not sure. Either way, glad you got it worked out. -- Jim On Wed, Oct 27, 2010 at 3:46 PM, Richard B. Kreckel wrote: > On 10/27/2010 02:53 PM, Jim Nelson wrote: > >> These are bindings problems. I suspect you have old .vapi files on your >> system somewhere that the Vala compiler is using. (These bindings >> changed a while back.) >> >> I would uninstall 0.10 and recursively scan your /usr directory for any >> remaining .vapi files. gexiv2 and Gee install VAPIs, so those should >> not be deleted, but any GDK or GLib vapis you see after that should be >> removed. Then reinstall 0.10.0. >> > > Thanks a lot! (You know, I'm totally new to vala and didn't even know that > declarations are in .vapi files.) > > It turned out that uninstalling Debian/sqeeze's valac package (this is > version 0.8.1) solved the problem. Shotwell compiled fine then and works > like a charm. > > What I find strange though is that the custom installation of vala 0.10.0 > picked up files from the system's vala package (glib-2.0.vapi, for > instance). Shouldn't vala know where to look for .vapi files? > > > -richy. > -- > Richard B. Kreckel > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Fri Oct 29 21:11:38 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 29 Oct 2010 14:11:38 -0700 Subject: [Shotwell] bug: shotwell doesn't detect the camera but gphoto does it In-Reply-To: References: Message-ID: I noticed on your bugzilla report that you're using Shotwell 0.6.1. I would recommend upgrading to 0.7.2 (our latest) before you continue your testing. You can download 0.7.2 from our web site at http://yorba.org/shotwell. Then try running Shotwell like this: $ SHOTWELL_LOG=1 shotwell In 0.7 and above, this will create a log file in ~/.cache/shotwell/shotwell.log. If you could post that here or send it to me, it would be most helpful in figuring out why we're not seeing the camera. -- Jim 2010/10/28 St?phane Blondon > Hello everyone, > > If I plug a camera (fujifilm finepix AX200) with his USB port to the > computer and execute shotwell, shotwell doesn't show the camera on the > left column. > > - The camera is properly detected by the gPhoto2 binary. gPhoto can > copy the files on the computer too. > - The same behaviour occurs with gthumb (camera not found). > > You can find more details and logs about my gThumb attempt in the bug > reports I sended to my distribution: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599736 > > Note that gphoto, gthumb and shotwell comes from the Debian testing > packages. > > What could I do to understand better the problem and to try to fix it? > > > (I have subscribed to the mailing list.) > > -- > St?phane > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Fri Oct 29 21:54:55 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 29 Oct 2010 14:54:55 -0700 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: <4CC8D8DD.6010906@kth.se> References: <4CC7EA67.3060303@free.fr> <4CC8D8DD.6010906@kth.se> Message-ID: <4CCB42AF.3040902@yorba.org> On 10/27/2010 06:58 PM, Simon Spannagel wrote: > > > Am 27.10.2010 22:19, schrieb Jim Nelson: >> directory structure within the sidebar? >> We've been considering the latter: http://trac.yorba.org/ticket/1594 >> >> -- Jim > Ah, don't do that. In my opinion that would destroy the good and > well-sorted experience the user gets - cause this folder view will > always remind him how messed up his pictures are stored. I think you > don't need this folder view in Shotwell - if one wants to browse the > directories, one can still use his favourite file manager... It's clear that some users care about where photos are stored and others don't. The long-term plan for Shotwell is to add several more sidebar trees which the user can enable or disable as they like. If you don't care about events and only want to browse through your photos according to their on-disk location, you'll be able to hide the event tree and turn on the folder tree. Conversely, a user who only wants to use events will be able to show only that tree. We may also add trees which will let you browse photos by - geolocation: country, state, city and so on (http://trac.yorba.org/ticket/1473) - import rolls (http://trac.yorba.org/ticket/1793) - time: like events, but doesn't allow renaming/splitting/merging (http://trac.yorba.org/ticket/2747) - cameras and so on. I hope this will make everyone happy. :) adam From gpopac at gmail.com Sat Oct 30 10:35:14 2010 From: gpopac at gmail.com (=?UTF-8?Q?=D0=9C=D0=B8=D0=BB=D0=BE=D1=88_?= =?UTF-8?Q?=D0=9F=D0=BE=D0=BF=D0=BE=D0=B2=D0=B8=D1=9B?=) Date: Sat, 30 Oct 2010 12:35:14 +0200 Subject: [Shotwell] Autoimport crashes shotwell Message-ID: <1288434914.9326.2.camel@PotrChkO> I use Lastest version from SVN. When started, it works fine, until Shotwell starts to import photos from library: ERROR:LibraryMonitor.vala:453:library_monitor_discovery_stage_completed: assertion failed: (master_info != NULL) Aborted Any tips? From simonspa at kth.se Sun Oct 31 09:42:02 2010 From: simonspa at kth.se (Simon Spannagel) Date: Sun, 31 Oct 2010 10:42:02 +0100 Subject: [Shotwell] creating events named after subfolders, while importing In-Reply-To: <4CCB42AF.3040902@yorba.org> References: <4CC7EA67.3060303@free.fr> <4CC8D8DD.6010906@kth.se> <4CCB42AF.3040902@yorba.org> Message-ID: <4CCD39EA.3080701@kth.se> Am 29.10.2010 23:54, schrieb Adam Dingle: > browse photos by > > - geolocation: country, state, city and so on > (http://trac.yorba.org/ticket/1473) > - import rolls (http://trac.yorba.org/ticket/1793) > - time: like events, but doesn't allow renaming/splitting/merging > (http://trac.yorba.org/ticket/2747) > - cameras > > and so on. Wow! You guys really think about what you're doing! Great!