From adam at yorba.org Thu Sep 1 04:41:52 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 01 Sep 2011 07:41:52 +0300 Subject: [Shotwell] Re-Import RAW+JPEG, 0.11 In-Reply-To: References: <4E5E04DE.5090501@yorba.org> Message-ID: <4E5F0D10.2080506@yorba.org> On 08/31/2011 06:52 PM, Maximilian B wrote: > Hi Adam, thanks for your work! > >> Now, I'll let you in on a little secret: due to a bug it actually *is* >> possible to import RAW+JPEG pairs in Shotwell 0.11 if you drag in files >> rather than folders: >> >> http://redmine.yorba.org/issues/4079 >> > Re-importing images as paired pictures seem to work this way but the > camera JPEG will not always be shown even if camera is set to default > developer: A few points: 1. We've recently fixed a bug which caused Shotwell to ignore the Developer preference in 0.11: http://redmine.yorba.org/issues/4065 So I'd strongly suggest that you build from git master rather than use 0.11.0 if you want to experiment with RAW+JPEG in Shotwell today. 2. I tried importing RAW+JPEG from the filesystem again today and found that the trick I described here works both when you import in place and when you copy to the filesystem. If the RAW and JPEG photos are in the Shotwell trash, however, it won't work - Shotwell will simply resurrect the RAW photo from the trash when you import. A few comments on the steps you described: > > 1. I set default raw developer to camera. > 2. I disabled watch library directory for new files > 3. I trashed Images Do you mean that you moved the images to the Shotwell trash, or that you moved the associated files to the GNOME desktop trash? Unfortunately this is ambiguous. > 4. and tried to re-import a few images in two ways: > 4.a. drag in images of original folder. images will be paired but > alternately the shotwell developed JPEG and camera JPEG will be shown I don't understand what you mean by "alternately the shotwell developed JPEG and camera JPEG will be shown". > 4.b. completely moved files and folder to a different partition and > removed them from library directory. then dragged in images of that > folder applying copy to library option. images will be paired but only > the shotwell developed JPEG will be shown. This could be a consequence of http://redmine.yorba.org/issues/4065. Again, I think you should now build from git master if you can. Cheers - adam From list at heinrich-muenz.de Thu Sep 1 05:35:27 2011 From: list at heinrich-muenz.de (Heiner) Date: Thu, 01 Sep 2011 07:35:27 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> Message-ID: <4E5F199F.6040807@heinrich-muenz.de> Is there any workaround fon non-coders, or will I have to stick to f-spot? By the way - I've also tried to simply import my photo folders (the files, without using f-spots database). But that produces unexpected results as well: If I set the raw developer to "camera"before importing, it will end up showing nicely paired raw/jpg images - but unfortunatelly whithout any tags. If I set the raw developer to "Shotwell", it will end up having two sparate images, raw and jpg. The jpg will be tagged correctly, while the raw file won't have any tags at all. It would be nice to have the first alternative (paired files) with tags - but how can I achieve this? Regards Heinrich Am 31.08.2011 19:40, schrieb Lucas Beeler: >> "L 2467 2011-08-31 13:29:24 [WRN] No namespace information for >> XMP-Pr?fix `lr' available" > This error is actually an unrelated and spurious artifact of the exiv2 > library that Shotwell uses to read metadata from files, unfortunately > (see this ticket here: http://redmine.yorba.org/issues/3950). It would > be great if it were related, 'cause that would give us more insight > into the problem. > > Cheers, > Lucas From ethan.glasser.camp at gmail.com Thu Sep 1 08:30:54 2011 From: ethan.glasser.camp at gmail.com (Ethan) Date: Thu, 1 Sep 2011 04:30:54 -0400 Subject: [Shotwell] Pictures as symbolic links Message-ID: Hi, I was going to file this as a ticket on redmine, but I didn't get a confirmation email when I registered, so I couldn't. I know Shotwell supports symbolic links to directories containing images. Are there any plans to support symbolic links to images in Shotwell? Would patches be welcome? Any suggestions on implementation direction? Thanks! Ethan From oliver at first.in-berlin.de Thu Sep 1 10:05:00 2011 From: oliver at first.in-berlin.de (oliver) Date: Thu, 1 Sep 2011 12:05:00 +0200 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: Message-ID: <20110901100500.GA1867@siouxsie> Hi, a while ago I talked about using symbolic links. But I was not accurate enough in picking the terms. I later explained it: "symbolic links" was not meant as symbolic links on the filesystem level, which is what symbolic links are. I meant: symbolically linking the data into the database, but not file-by-file; I meant whole directory tries ("repositories"), while making the database hold inside the according directory-tree. So, if you want to implement "symbolic links instead of copying" on the filesystem level, I'm not sure if this really makes sense. The reason is: the link only works, if the pictures are available. If not, it's a broken link. In that case, it would be better to follow the way I mentioned: if a whole pictrure-directory is not there (e..g. movable media), then only once it's checked if the whole directory is there, instead of checking each broken link individually. Ciao, Oliver From ethan.glasser.camp at gmail.com Thu Sep 1 13:11:04 2011 From: ethan.glasser.camp at gmail.com (Ethan) Date: Thu, 1 Sep 2011 09:11:04 -0400 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: <20110901100500.GA1867@siouxsie> References: <20110901100500.GA1867@siouxsie> Message-ID: On Thu, Sep 1, 2011 at 6:05 AM, oliver wrote: > a while ago I talked about using symbolic links. > But I was not accurate enough in picking the terms. > I later explained it: "symbolic links" was not meant > as symbolic links on the filesystem level, which is > what symbolic links are. > Let me clarify. What I want *is* support for symbolic links on the filesystem level. I'm experimenting with using git-annex to store my picture files, so my picture library consists of symlinks to pictures. The symlinks have appropriate names like "dscn8517.jpg", and they link to files like ".git/annex/objects/8x/k7/WORM-s1985206-m1306675740--dscn8517.jpg/WORM-s1985206-m1306675740--dscn8517.jpg". I'd like these files to be recognized at all when I start shotwell. If the links are broken, I'm OK with them being marked as "missing". In a perfect world, if they got shuffled around, I would like them to not be re-imported as duplicates. Shotwell currently explicitly doesn't support symbolic links as "images" (see BatchImport.vala:1444 and DirectoryMonitor.vala:69). I can understand that it might be complicated to figure out how to treat them; what happens if a symlink changes target? If a symlink is updated, does this mean it needs to be rescanned? In my use case I don't care too much about these questions, but recognizing the files at all would be an important step. Advice on how to go about implementing this would therefore be appreciated. I think I can just add cases to both of the above files for symlinks that provide file metainformation from the linked file and add a FileMonitor on the linked file (as well as the symlink?) but I haven't actually written any code yet. Ethan From paulo at matos-sorge.com Thu Sep 1 14:21:53 2011 From: paulo at matos-sorge.com (Paulo J. Matos) Date: Thu, 01 Sep 2011 15:21:53 +0100 Subject: [Shotwell] Halting during import In-Reply-To: <4E5E0A87.4020402@yorba.org> References: <4E5E0A87.4020402@yorba.org> Message-ID: On 31/08/11 11:18, Adam Dingle wrote: > Sure: > > $ SHOTWELL_LOG=1 shotwell > > The log file will appear in ~/.cache/shotwell/shotwell.log . Perhaps it > will give a clue as to what's going on. > Again, I reproduced it this morning with shotwell 0.11. I did a first run with logging [shotwell.log] and then it halted so I killed the app. Then I restarted shotwell with logging [shotwell1.log] and noticed that the Auto-import was starting before I did anything. So I thought that might have been the problem. I went to preferences to turn off auto-importing. Nothing was there to disable it. But I found an option through gconf-editor and disabled it. So I closed shotwell and restarted it with logging [shotwell2.log]. I imported my photos correctly. Interestingly whenever I killed shotwell while it was importing the photos RAW+JPEG that were imported until the app is killed show up separately. I attach the logs however here are some interesting things: [shotwell.log]: L 4850 2011-09-01 11:16:20 [WRN] ImportPage.vala:1392: Unable to fetch metadata for /DCIM/100D5000/DSC_0001.NEF: [-1] Error retrieving file object for /DCIM/100D5000/DSC_0001.NEF: Unspecified error This is strange. What kind of path is that. The actual path should be /media/4FC5-8E2D/DCIM/... First run halts and I killed it at 11:23:45 (closed to the end of the log). [shotwell1.log]: L 8234 2011-09-01 11:33:27 [CRT] Thumbnail.vala:325: Unable to fetch low-quality thumbnail for DataView DSC_0126.NEF [DataSource [22034] /home/pmatos/Pictures/2011/08/31/DSC_0126.NEF] (scale: 160): Failed to open file '/home/pmatos/.shotwell/thumbs/thumbs128/thumb0000000000005612.jpg': No such file or directory Can't understand what's the problem here. Should check if file exists once I get back home but if it doesn't exist then I need to understand why it was not created to start with. How does the creation of thumbnails work? I can imagine that a thread is spawned to create the thumbnail and once that is done, an event is received and the thumbnail is displayed. Is it something like this? Cheers, -- PMatos From oliver at first.in-berlin.de Thu Sep 1 15:23:23 2011 From: oliver at first.in-berlin.de (oliver) Date: Thu, 1 Sep 2011 17:23:23 +0200 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: <20110901152323.GA1657@siouxsie> On Thu, Sep 01, 2011 at 09:11:04AM -0400, Ethan wrote: > On Thu, Sep 1, 2011 at 6:05 AM, oliver wrote: > > > a while ago I talked about using symbolic links. > > But I was not accurate enough in picking the terms. > > I later explained it: "symbolic links" was not meant > > as symbolic links on the filesystem level, which is > > what symbolic links are. > > > > Let me clarify. What I want *is* support for symbolic links on the > filesystem level. I'm experimenting with using git-annex to store my > picture files, so my picture library consists of symlinks to pictures. The > symlinks have appropriate names like "dscn8517.jpg", and they link to files > like > ".git/annex/objects/8x/k7/WORM-s1985206-m1306675740--dscn8517.jpg/WORM-s1985206-m1306675740--dscn8517.jpg". Aha. I didn't know of git-annex. I used git as repository for my files, when preparing an exhibition. The disadvantage is: the files are in the working directory as well as in the repository, which means: there is at least twice as much disk spce used as I would need for the pictures... and with every new file-version mo0re space is needed. (But I have versioning, which migth become very helpful). After my work was done I removed the .git and saved disk space. I had the original phpotgraphs elswehere and the work for printing in the pic-working dir. I may also look at git-annex. Not sure if it provides what I'm looking for, but AFAIK git is written as libraries and interfaces to the user, so the functionality should be available for own programs. I tried "-d" switch from shotwell with relative pathnames. The db-dir was created relative to the $HOME. I hope it also will work with absolute pathnames, because then i could use $ shotwell -d which comes close to my attempt with picture-repositories, which contains the pictures as well as the database. This would be done if I use $MY_PICTURE_DIR as path to the picture files as well as for "-d". I hope the abspath-attempt will work. Did not tried so far. If it does, then the only problem is, that there is no meta-view, which automatically shows me the picture-repositories all in shotwell overview/menus. Then I could pick out one or more of those repos, e.g. one is on USB, another is on changebale HDD under /mnt/pics/ and the rest is on my main HDD somewhere in $HOME or so. At the moment one would need to start another shotwell -d program to get access to other picture-repos. > > I'd like these files to be recognized at all when I start shotwell. If the > links are broken, I'm OK with them being marked as "missing". In a perfect > world, if they got shuffled around, I would like them to not be re-imported > as duplicates. Shotwell does check files on importing. I tried at least with some jpg-files and it works. Don't know if it also can handle some 10k or some 100k files efficiently. Also I don't know how it compares files to check on equality. But it seems, for jpeg-files it checks the pure data-part. But if it finds equally data-dart files, it *might* be fine, to ask, if other comments parts from the files might be added to the database, so that pictures with differing comment sections but similar jpg-data might yield in adding all the found comment parts, so that no comment is missing. Would be nice, but is a rather minor feature (nice to have, but not extremely important). > > Shotwell currently explicitly doesn't support symbolic links as "images" > (see BatchImport.vala:1444 and DirectoryMonitor.vala:69). I can understand > that it might be complicated to figure out how to treat them; [...] Symlinks are not that complicated. But it might need some more syscalls to check that. => man 2 stat => man 2 lstat Ciao, Oliver From oliver at first.in-berlin.de Thu Sep 1 15:36:04 2011 From: oliver at first.in-berlin.de (oliver) Date: Thu, 1 Sep 2011 17:36:04 +0200 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: <20110901153604.GA2052@siouxsie> On Thu, Sep 01, 2011 at 09:11:04AM -0400, Ethan wrote: > On Thu, Sep 1, 2011 at 6:05 AM, oliver wrote: > > > a while ago I talked about using symbolic links. > > But I was not accurate enough in picking the terms. > > I later explained it: "symbolic links" was not meant > > as symbolic links on the filesystem level, which is > > what symbolic links are. > > > > Let me clarify. What I want *is* support for symbolic links on the > filesystem level. I'm experimenting with using git-annex to store my > picture files, [...] I found that page: http://git-annex.branchable.com/ Looks interesting/promising. I think I will have a closer look at it. Ciao, Oliver From guiyou65 at hotmail.com Thu Sep 1 20:58:41 2011 From: guiyou65 at hotmail.com (Thierry Le Guillou) Date: Thu, 1 Sep 2011 22:58:41 +0200 Subject: [Shotwell] Very old date for ancient pictures Message-ID: hello, I have some photos from my grand-grand father that I scanned and stored with Shotwell. But when I try to put the real date in picture metadat field : 1 july 1896, Shotwell modify the date in 1 july 1970 ! Is there any limitation on dates ? In metadatas or in shotwell calendar interface ? Is it possible to unlimit this ? What about a text field to put directly the date in picture ? Thierry From clinton at yorba.org Thu Sep 1 21:38:14 2011 From: clinton at yorba.org (Clinton Rogers) Date: Thu, 1 Sep 2011 14:38:14 -0700 Subject: [Shotwell] Very old date for ancient pictures In-Reply-To: References: Message-ID: Hi Thierry, On Thu, Sep 1, 2011 at 1:58 PM, Thierry Le Guillou wrote: > hello, > I have some photos from my grand-grand father that I scanned and stored with > Shotwell. > But when I try to put the real date in picture metadat field : 1 july 1896, > Shotwell modify the date in 1 july 1970 ! > Is there any limitation on dates ? In metadatas or in shotwell calendar > interface ? Is it possible to unlimit this ? Unfortunately, due to a code limitation, Shotwell does not handle dates before 1 January 1902. Changing this limit might be tricky, since we rely on glib for dates and times. > What about a text field to put directly the date in picture ? By using the hierarchical tag system, you can do exactly that. You might try something like creating a tag named '1896', then underneath that, a child tag named 'July', a child of that child named '1st' and then tagging your photographs from that date with that. This allows you to sort your images by date, even if the date is prior to 1902. I hope this helps you, but if you have any other questions, please feel free to respond. Cheers, -c From jim at yorba.org Thu Sep 1 22:01:00 2011 From: jim at yorba.org (Jim Nelson) Date: Thu, 1 Sep 2011 15:01:00 -0700 Subject: [Shotwell] Very old date for ancient pictures In-Reply-To: References: Message-ID: We do have a ticket for this, by the way: http://redmine.yorba.org/issues/3040 -- Jim On Thu, Sep 1, 2011 at 2:38 PM, Clinton Rogers wrote: > Hi Thierry, > > > On Thu, Sep 1, 2011 at 1:58 PM, Thierry Le Guillou > wrote: > > hello, > > I have some photos from my grand-grand father that I scanned and stored > with > > Shotwell. > > But when I try to put the real date in picture metadat field : 1 july > 1896, > > Shotwell modify the date in 1 july 1970 ! > > Is there any limitation on dates ? In metadatas or in shotwell calendar > > interface ? Is it possible to unlimit this ? > Unfortunately, due to a code limitation, Shotwell does not handle > dates before 1 January 1902. Changing this limit might be tricky, > since we rely on glib for dates and times. > > > What about a text field to put directly the date in picture ? > By using the hierarchical tag system, you can do exactly that. You > might try something like creating a tag named '1896', then underneath > that, a child tag named 'July', a child of that child named '1st' and > then tagging your photographs from that date with that. This allows > you to sort your images by date, even if the date is prior to 1902. > > I hope this helps you, but if you have any other questions, please > feel free to respond. > Cheers, > -c > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Thu Sep 1 22:41:28 2011 From: jim at yorba.org (Jim Nelson) Date: Thu, 1 Sep 2011 15:41:28 -0700 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: When we first started Shotwell, we avoided symlinks because they open up a number of issues we preferred not have to face up front, such as broken links, directory loops, and who knows what else. Over time we added some support: the auto-import and directory monitoring features do support symlinks for directories (for some specific use cases we felt we needed to support), but not with files themselves. We have a ticket to support symlinks completely: http://redmine.yorba.org/issues/2983 I don't know that we would want to install FileMonitors for each linked file, however, since there is a hard limit each process can create. The general strategy we've used in directory monitoring is to install a single directory monitor and watch the files it contains. -- Jim On Thu, Sep 1, 2011 at 6:11 AM, Ethan wrote: > On Thu, Sep 1, 2011 at 6:05 AM, oliver wrote: > > > a while ago I talked about using symbolic links. > > But I was not accurate enough in picking the terms. > > I later explained it: "symbolic links" was not meant > > as symbolic links on the filesystem level, which is > > what symbolic links are. > > > > Let me clarify. What I want *is* support for symbolic links on the > filesystem level. I'm experimenting with using git-annex to store my > picture files, so my picture library consists of symlinks to pictures. The > symlinks have appropriate names like "dscn8517.jpg", and they link to files > like > > ".git/annex/objects/8x/k7/WORM-s1985206-m1306675740--dscn8517.jpg/WORM-s1985206-m1306675740--dscn8517.jpg". > > I'd like these files to be recognized at all when I start shotwell. If the > links are broken, I'm OK with them being marked as "missing". In a perfect > world, if they got shuffled around, I would like them to not be re-imported > as duplicates. > > Shotwell currently explicitly doesn't support symbolic links as "images" > (see BatchImport.vala:1444 and DirectoryMonitor.vala:69). I can understand > that it might be complicated to figure out how to treat them; what happens > if a symlink changes target? If a symlink is updated, does this mean it > needs to be rescanned? In my use case I don't care too much about these > questions, but recognizing the files at all would be an important step. > Advice on how to go about implementing this would therefore be appreciated. > I think I can just add cases to both of the above files for symlinks that > provide file metainformation from the linked file and add a FileMonitor on > the linked file (as well as the symlink?) but I haven't actually written > any > code yet. > > Ethan > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lutimdale at yahoo.com Fri Sep 2 02:06:59 2011 From: lutimdale at yahoo.com (Lu Timdale) Date: Thu, 1 Sep 2011 19:06:59 -0700 (PDT) Subject: [Shotwell] Shotwell 0.11 Comments Message-ID: <1314929219.59314.YahooMailNeo@web160805.mail.bf1.yahoo.com> Hello, Just tried the latest and greatest version of Shotwell.? I'm eagerly getting ready to unleash it on my large photo collection, so I've been giving each new version a quick test.? My comments for 0.11 are below. 1. Corruption of dates on import seems to be fixed.? I had an issue previously when some dates got mixed up on the file system during import... problem is now gone.? Yeh! 2. Boolean searches Love the enhancements there, and it just seems to work.? All the most important ones are there. This could be expanded even further though... I can think of a few others that I would use if it was available - camera make / model / lens - shutter speed / iso / exposure / program (Auto/Aperture/Shutter/Man) / flash fired - file size Realise that you're trying to make this user friendly by limiting options, but there are lots of prosumer options that could be exposed here... namely all the exif info and all the file level info.? I wonder if there is a compromise that can be achieved by exposing one item "exif field" in the drop down and having a legend of the field names to use via a linked help page.? Each line would look like: "Exif Field" Anyway.... just a thought. 3. Tags. Hierarchical tags work great.? Apart from a few accessibility issues, they are very usable. I expected one feature when clicking on "Tags"... the top level tag, any photo with a any tag set would be shown.? Possibility for a future version? 4. Files / Events I like that allowing a custom folder structure on import has been implemented, but in order to support my workflow as is, I would need to A) - import to my custom folder structure in shotwell - rename the folders by enriching with a comment (in nautilus) - rename the files with an external tool (phatch?) - restart shotwell to update index to point to new folders/file names. or B) - use something else for import to shotwell's library directory - start shotwell (with watch library) to update Ideally, I would like this to be done without leaving shotwell.? This is probably the one main outstanding reason I'm not using shotwell exclusively.? I'm waiting for any/all of these. - rename photo files themselves on import - add event names on import - move files when modifying dates / changing event names - either reflect event structure in file structure (and vice versa), or expose folder view - create events based on existing folder names (for existing library) 5. Scalability I now have 130GB collection of 50K+ photos and videos.? Waiting for the "scale to 100K photos" feature as I think it may impact me. With every release, I'm left wanting for less and less.? Thank you for a great job. ? Lu Timdale lutimdale at yahoo.com From oliver at first.in-berlin.de Fri Sep 2 09:54:21 2011 From: oliver at first.in-berlin.de (oliver) Date: Fri, 2 Sep 2011 11:54:21 +0200 Subject: [Shotwell] Very old date for ancient pictures In-Reply-To: References: Message-ID: <20110902095421.GA1654@siouxsie> On Thu, Sep 01, 2011 at 10:58:41PM +0200, Thierry Le Guillou wrote: > hello, > I have some photos from my grand-grand father that I scanned and > stored with Shotwell. > But when I try to put the real date in picture metadat field : 1 > july 1896, Shotwell modify the date in 1 july 1970 ! [...] LOL 1970 sounds like Unix epoche time. :-) Ciao, Oliver From oliver at first.in-berlin.de Fri Sep 2 10:49:07 2011 From: oliver at first.in-berlin.de (oliver) Date: Fri, 2 Sep 2011 12:49:07 +0200 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: <20110902104907.GG1654@siouxsie> On Thu, Sep 01, 2011 at 03:41:28PM -0700, Jim Nelson wrote: > When we first started Shotwell, we avoided symlinks because they open up a > number of issues we preferred not have to face up front, such as broken > links, directory loops, and who knows what else. Over time we added some > support: the auto-import and directory monitoring features do support > symlinks for directories (for some specific use cases we felt we needed to > support), but not with files themselves. [...] If you just use files, without checking, if they are symbolic links, then you have the problems that goes along with symbolic links, already. Any file that you import might already be a symbolic link in the directory you import. How is/was that handled? > > We have a ticket to support symlinks completely: > http://redmine.yorba.org/issues/2983 I don't know that we would want to > install FileMonitors for each linked file, Is Filemonitoring already used on regular files? And: is it file-based? If so, this would may answer some of the performance issues I had with num of files > 100k. > however, since there is a hard > limit each process can create. The general strategy we've used in directory > monitoring is to install a single directory monitor and watch the files it > contains. [...] Is this automatically done, or triggered by the user? Such things as automatisms can strongly reduce performance.... ...at Desktop Environments as well as in photo-programs. Ciao, Oliver From martin+shotwell at flexion.org Fri Sep 2 12:46:32 2011 From: martin+shotwell at flexion.org (Martin Wimpress) Date: Fri, 02 Sep 2011 13:46:32 +0100 Subject: [Shotwell] Shotwell .011 for Lucid and Maverick - Attempt 3 Message-ID: Hi, I'm very sorry about the broken Shotwell 0.11 packages I released for Lucid and Maverick over the last couple of days :-( I think, and really hope, I've fixed the problems completely this time and submitted packages to the Ubuntu buildd servers over two hours ago, but they are still pending so I can't actually test them to ensure they work properly. Hopefully 'shotwell-0.11.0-1ppa7~lucid1' and 'shotwell-0.11.0-1ppa7~maverick1' will arrive in my PPA soon and all will be well with the world again ;-) * https://launchpad.net/~flexiondotorg/+archive/shotwell I am travelling for the next couple of days, so if the packages are still broken it will be a few days before I get around to fixing them. -- Regards, Martin. From paulo at matos-sorge.com Fri Sep 2 13:59:43 2011 From: paulo at matos-sorge.com (Paulo J. Matos) Date: Fri, 02 Sep 2011 14:59:43 +0100 Subject: [Shotwell] Re-Import RAW+JPEG, 0.11 In-Reply-To: <4E5E04DE.5090501@yorba.org> References: <4E5E04DE.5090501@yorba.org> Message-ID: On 31/08/11 10:54, Adam Dingle wrote: > I just discovered this this morning. I'm calling this a bug because we > didn't implement this intentionally (as far as I know): it just happens > to work. We might or might not change this for 0.11. But if this > behavior is reliable (e.g. it won't lead to a crash) we might keep it in > place. > Do you confirm that: if I export my original raw+jpeg photos to a folder. permanently delete them from shotwell and reimport them using the trick above, I will get them as a pair in shotwell? Cheers, -- PMatos From xavierviader at gmail.com Fri Sep 2 17:39:13 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Fri, 2 Sep 2011 19:39:13 +0200 Subject: [Shotwell] Shotwell .011 for Lucid and Maverick - Attempt 3 In-Reply-To: References: Message-ID: Hi Martin, great job !! Shotwell 0.11 is working (at least installed) in my ubuntu 10.04 Lucid. I've installed it in two machines, one with 64 bits and another with 32 bits. In both cases shotwell 0.11 it's been installed. thank you so much !! Xavi 2011/9/2 Martin Wimpress > Hi, > > I'm very sorry about the broken Shotwell 0.11 packages I released for Lucid > and Maverick over the last couple of days :-( > > I think, and really hope, I've fixed the problems completely this time and > submitted packages to the Ubuntu buildd servers over two hours ago, but they > are still pending so I can't actually test them to ensure they work > properly. Hopefully 'shotwell-0.11.0-1ppa7~lucid1' and > 'shotwell-0.11.0-1ppa7~**maverick1' will arrive in my PPA soon and all > will be well with the world again ;-) > > * https://launchpad.net/~**flexiondotorg/+archive/**shotwell > > I am travelling for the next couple of days, so if the packages are still > broken it will be a few days before I get around to fixing them. > > -- > Regards, Martin. > From acummings at gmx.com Fri Sep 2 17:34:56 2011 From: acummings at gmx.com (Alan Cummings) Date: Fri, 2 Sep 2011 13:34:56 -0400 Subject: [Shotwell] Shotwell .011 for Lucid and Maverick - Attempt 3 In-Reply-To: References: Message-ID: <20110902133456.1c7c8959.acummings@gmx.com> Martin Wimpress wrote: > Hi, > > I'm very sorry about the broken Shotwell 0.11 packages I released for > Lucid and Maverick over the last couple of days :-( > > I think, and really hope, I've fixed the problems completely this time > and submitted packages to the Ubuntu buildd servers over two hours ago, > but they are still pending so I can't actually test them to ensure they > work properly. Hopefully 'shotwell-0.11.0-1ppa7~lucid1' and > 'shotwell-0.11.0-1ppa7~maverick1' will arrive in my PPA soon and all > will be well with the world again ;-) > > * https://launchpad.net/~flexiondotorg/+archive/shotwell > > I am travelling for the next couple of days, so if the packages are > still broken it will be a few days before I get around to fixing them. > It works here on Lucid! Thanks Martin. -- Alan. From eric at yorba.org Fri Sep 2 18:20:18 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 2 Sep 2011 11:20:18 -0700 Subject: [Shotwell] Re-Import RAW+JPEG, 0.11 In-Reply-To: References: <4E5E04DE.5090501@yorba.org> Message-ID: On Fri, Sep 2, 2011 at 6:59 AM, Paulo J. Matos wrote: > > Do you confirm that: > if I export my original raw+jpeg photos to a folder. > permanently delete them from shotwell and reimport them using the trick > above, I will get them as a pair in shotwell? > This does seem to work, although since the behavior wasn't by design, it's possible this will change for 0.11.1 in some way. See the following ticket for more details: http://redmine.yorba.org/issues/4079 - Eric From pierre.willaime at gmail.com Fri Sep 2 18:58:15 2011 From: pierre.willaime at gmail.com (Pierre Willaime) Date: Fri, 2 Sep 2011 18:58:15 +0000 Subject: [Shotwell] piwigo shotwell plugin Message-ID: <20110902185815.793f33bc@gmail.com> Hi, It would be nice if shotwell could allow to resize pictures during the transfert to piwigo. Indeed, most people want to save space on their gallery and don't need pictures of a size like 5 Go. I think a lite option "size of pictures" with the choice between "HD" and "web size" would be perfect. What do you think about that ? bye Pierre From eric at yorba.org Fri Sep 2 19:05:50 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 2 Sep 2011 12:05:50 -0700 Subject: [Shotwell] piwigo shotwell plugin In-Reply-To: <20110902185815.793f33bc@gmail.com> References: <20110902185815.793f33bc@gmail.com> Message-ID: On Fri, Sep 2, 2011 at 11:58 AM, Pierre Willaime wrote: > It would be nice if shotwell could allow to resize pictures during the > transfert to piwigo. Indeed, most people want to save space on their gallery > and don't need pictures of a size like 5 Go. > > I think a lite option "size of pictures" with the choice between "HD" and > "web size" would be perfect. > > What do you think about that ? > Hi Pierre, We already have a ticket for exports by file size. I put a note on the ticket that it should be available for publishing as well. Ticket is here: http://redmine.yorba.org/issues/3856 - Eric From pierre.willaime at gmail.com Fri Sep 2 19:31:22 2011 From: pierre.willaime at gmail.com (Pierre Willaime) Date: Fri, 2 Sep 2011 19:31:22 +0000 Subject: [Shotwell] piwigo shotwell plugin In-Reply-To: References: <20110902185815.793f33bc@gmail.com> Message-ID: <20110902193122.0a836482@gmail.com> Le Fri, 2 Sep 2011 12:05:50 -0700, Eric Gregory a ?crit : > On Fri, Sep 2, 2011 at 11:58 AM, Pierre Willaime > wrote: > > > It would be nice if shotwell could allow to resize pictures during the > > transfert to piwigo. Indeed, most people want to save space on their gallery > > and don't need pictures of a size like 5 Go. > > > > I think a lite option "size of pictures" with the choice between "HD" and > > "web size" would be perfect. > > > > What do you think about that ? > > > > Hi Pierre, > > We already have a ticket for exports by file size. I put a note on the > ticket that it should be available for publishing as well. > > Ticket is here: > http://redmine.yorba.org/issues/3856 > > - Eric Thank you Eric. But I think it is not exactly the same request because I don't want to resize my pictures to a certain weight. I don't want a system which allows to not enter a height and width. and I don't care how exactly big my picture will be. I just want to can resize by height and width pictures (for example 800x600) in publishing to my piwigo galleries. So it's technically more simple than to not set height and width. If you think it's a good idea, I can open another ticket (if I have the right to do that). But if you think it's not necessary, it's not a problem. I don't create this. bye pierre From jim at yorba.org Fri Sep 2 19:34:28 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 2 Sep 2011 12:34:28 -0700 Subject: [Shotwell] piwigo shotwell plugin In-Reply-To: <20110902193122.0a836482@gmail.com> References: <20110902185815.793f33bc@gmail.com> <20110902193122.0a836482@gmail.com> Message-ID: Pierre, Does this ticket describe what you're asking for? http://redmine.yorba.org/issues/3750 -- Jim On Fri, Sep 2, 2011 at 12:31 PM, Pierre Willaime wrote: > Le Fri, 2 Sep 2011 12:05:50 -0700, > Eric Gregory a ?crit : > > > On Fri, Sep 2, 2011 at 11:58 AM, Pierre Willaime > > wrote: > > > > > It would be nice if shotwell could allow to resize pictures during the > > > transfert to piwigo. Indeed, most people want to save space on their > gallery > > > and don't need pictures of a size like 5 Go. > > > > > > I think a lite option "size of pictures" with the choice between "HD" > and > > > "web size" would be perfect. > > > > > > What do you think about that ? > > > > > > > Hi Pierre, > > > > We already have a ticket for exports by file size. I put a note on the > > ticket that it should be available for publishing as well. > > > > Ticket is here: > > http://redmine.yorba.org/issues/3856 > > > > - Eric > > Thank you Eric. > > But I think it is not exactly the same request because I don't want to > resize my pictures to a certain weight. I don't want a system which allows > to not enter a height and width. and I don't care how exactly big my picture > will be. > > I just want to can resize by height and width pictures (for example > 800x600) in publishing to my piwigo galleries. So it's technically more > simple than to not set height and width. > > If you think it's a good idea, I can open another ticket (if I have the > right to do that). But if you think it's not necessary, it's not a problem. > I don't create this. > > bye > > pierre > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From pierre.willaime at gmail.com Fri Sep 2 19:39:27 2011 From: pierre.willaime at gmail.com (Pierre Willaime) Date: Fri, 2 Sep 2011 19:39:27 +0000 Subject: [Shotwell] piwigo shotwell plugin In-Reply-To: References: <20110902185815.793f33bc@gmail.com> <20110902193122.0a836482@gmail.com> Message-ID: <20110902193927.588fcbc4@gmail.com> Le Fri, 2 Sep 2011 12:34:28 -0700, Jim Nelson a ?crit : > Pierre, > > Does this ticket describe what you're asking for? > > http://redmine.yorba.org/issues/3750 > > -- Jim Exactly ! Sorry did not see this ticket. Thanks Pierre From jim at yorba.org Fri Sep 2 19:40:45 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 2 Sep 2011 12:40:45 -0700 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: <20110902104907.GG1654@siouxsie> References: <20110901100500.GA1867@siouxsie> <20110902104907.GG1654@siouxsie> Message-ID: On Fri, Sep 2, 2011 at 3:49 AM, oliver wrote: > > If you just use files, without checking, if they are symbolic links, > then you have the problems that goes along with symbolic links, already. > Any file that you import might already be a symbolic link in the > directory you import. > > How is/was that handled? > > We do check if the directory is a symbolic link before processing it. GLib has a mechanism where you can determine if a symbolic link to a directory corresponds to the "real" path to the directory. This is how we avoid directory loops. Is Filemonitoring already used on regular files? > And: is it file-based? > If so, this would may answer some of the performance issues I had with num > of files > 100k. > No. We do install a FileMonitor for each directory in your library (usually ~/Pictures), but not for each file. (FileMonitor allows either to be monitored.) There's still a scalability issue when you have an insane number of directories in your library. But, if you have 100,000 photos in, say, 500 directories (not implausible), then only 500 FileMonitor objects are created, which is reasonable. > > however, since there is a hard > > limit each process can create. The general strategy we've used in > directory > > monitoring is to install a single directory monitor and watch the files > it > > contains. > [...] > > Is this automatically done, or triggered by the user? > Such things as automatisms can strongly reduce performance.... > ...at Desktop Environments as well as in photo-programs. > The FileMonitors are only installed if the "Watch library directory for new files" is checked in the Preferences dialog. By default this is turned off. -- Jim From ethan.glasser.camp at gmail.com Fri Sep 2 20:01:19 2011 From: ethan.glasser.camp at gmail.com (Ethan) Date: Fri, 2 Sep 2011 16:01:19 -0400 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: On Thu, Sep 1, 2011 at 6:41 PM, Jim Nelson wrote: > When we first started Shotwell, we avoided symlinks because they open up a > number of issues we preferred not have to face up front, such as broken > links, directory loops, and who knows what else. Over time we added some > support: the auto-import and directory monitoring features do support > symlinks for directories (for some specific use cases we felt we needed to > support), but not with files themselves. > I've been messing around with the attached patch which makes the simple changes to allow Shotwell's monitoring to use symlinked photos and videos. A similar change could be made to BatchImport.vala:1411 to allow the same when doing "manual" imports, but I haven't tested it yet. query_for_info will return a FileInfo that still has file_type SYMBOLIC_LINK for broken symlinks, so those would still not get imported. I don't think those changes would allow Shotwell to notice when a symlink goes bad, but that's more than I need right now. We have a ticket to support symlinks completely: > http://redmine.yorba.org/issues/2983 I don't know that we would want to > install FileMonitors for each linked file, however, since there is a hard > limit each process can create. The general strategy we've used in directory > monitoring is to install a single directory monitor and watch the files it > contains. > For my purposes that's good enough. It's true that symbolic links could in principle point outside the directory tree, and while it would be better if we could notice changes to them, that could lead to an explosion of monitors (at worst, one for each symlink if each symlink points to a new directory). What would be necessary for you to apply a patch like this one? Would you want symlink support to be utterly bulletproof? Broken symlinks should be noticed and counted as "missing"? Monitors installed on places where symlinks point? I'm willing to do the legwork if I know what the requirements are. Ethan From jim at yorba.org Fri Sep 2 20:08:11 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 2 Sep 2011 13:08:11 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E5F199F.6040807@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> Message-ID: Heinrich, At this point I think it's best if you tried 0.11.1, which is coming out soon. It will have a number of bug fixes, many of them dealing with tags and heirarchical tags (which seems to be the source of many of these issues). You might need to clear your library and re-import from F-Spot after you upgrade. -- Jim On Wed, Aug 31, 2011 at 10:35 PM, Heiner wrote: > Is there any workaround fon non-coders, or will I have to stick to f-spot? > > By the way - I've also tried to simply import my photo folders (the > files, without using f-spots database). But that produces unexpected > results as well: > > If I set the raw developer to "camera"before importing, it will end up > showing nicely paired raw/jpg images - but unfortunatelly whithout any > tags. > > If I set the raw developer to "Shotwell", it will end up having two > sparate images, raw and jpg. The jpg will be tagged correctly, while the > raw file won't have any tags at all. > > It would be nice to have the first alternative (paired files) with tags > - but how can I achieve this? > > Regards > Heinrich > > Am 31.08.2011 19:40, schrieb Lucas Beeler: > >> "L 2467 2011-08-31 13:29:24 [WRN] No namespace information for > >> XMP-Pr?fix `lr' available" > > This error is actually an unrelated and spurious artifact of the exiv2 > > library that Shotwell uses to read metadata from files, unfortunately > > (see this ticket here: http://redmine.yorba.org/issues/3950). It would > > be great if it were related, 'cause that would give us more insight > > into the problem. > > > > Cheers, > > Lucas > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From clinton at yorba.org Fri Sep 2 20:43:30 2011 From: clinton at yorba.org (Clinton Rogers) Date: Fri, 2 Sep 2011 13:43:30 -0700 Subject: [Shotwell] Shotwell 0.11 Comments In-Reply-To: <1314929219.59314.YahooMailNeo@web160805.mail.bf1.yahoo.com> References: <1314929219.59314.YahooMailNeo@web160805.mail.bf1.yahoo.com> Message-ID: Hi Lu, On Thu, Sep 1, 2011 at 7:06 PM, Lu Timdale wrote: > Hello, > > Just tried the latest and greatest version of Shotwell. > > > I'm eagerly getting ready to unleash it on my large photo collection, so > I've been giving each new version a quick test. My comments for 0.11 are > below. > > 1. Corruption of dates on import seems to be fixed. > > I had an issue previously when some dates got mixed up on the file system > during import... problem is now gone. Yeh! > > Excellent! > > 2. Boolean searches > Love the enhancements there, and it just seems to work. All the most > important ones are there. > This could be expanded even further though... > I can think of a few others that I would use if it was available > > - camera make / model / lens > - shutter speed / iso / exposure / program (Auto/Aperture/Shutter/Man) / > flash fired > - file size > These are good ideas, and we do hope to implement these someday. Please have a look at http://redmine.yorba.org/issues/3612 > > 3. Tags. > Hierarchical tags work great. Apart from a few accessibility issues, they > are very usable. > I expected one feature when clicking on "Tags"... the top level tag, any > photo with a any tag set would be shown. Possibility for a future version? > This is also a sound idea; I'll open a ticket for it right away. > > 4. Files / Events > > I like that allowing a custom folder structure on import has been > implemented, but in order to support my workflow as is, I would need to > > A) > > - import to my custom folder structure in shotwell > > - rename the folders by enriching with a comment (in nautilus) > - rename the files with an external tool (phatch?) > - restart shotwell to update index to point to new folders/file names. > > or > B) > > - use something else for import to shotwell's library directory > > - start shotwell (with watch library) to update > > > Ideally, I would like this to be done without leaving shotwell. This is > probably the one main outstanding reason I'm not using shotwell > exclusively. I'm waiting for any/all of these. > > - rename photo files themselves on import > - add event names on import > > - move files when modifying dates / changing event names > > - either reflect event structure in file structure (and vice versa), or > expose folder view > - create events based on existing folder names (for existing library) > > I'll bring all this up with the rest of the team and open a ticket for the ability to automatically rename files on import. It seems like that, along with having http://redmine.yorba.org/issues/3549 in place would definitely help. > > 5. Scalability > I now have 130GB collection of 50K+ photos and videos. Waiting for the > "scale to 100K photos" feature as I think it may impact me. > > Indeed. My own collection is much smaller, only about fifteen hundred photos, but I've already noticed that, say, adding a tag to several hundred of them at a time can occasionally bog down a bit. Heavy work on scaling well up to very large libraries hasn't begun yet, but it is definitely something really want to do. > > > With every release, I'm left wanting for less and less. > > > Thank you for a great job. > You're welcome, we're glad you like it. And thank you, too; there's no way we'd be able to find and correct all of the issues without user feedback. Cheers, -c From jim at yorba.org Fri Sep 2 21:34:40 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 2 Sep 2011 14:34:40 -0700 Subject: [Shotwell] Shotwell 0.11 Comments In-Reply-To: References: <1314929219.59314.YahooMailNeo@web160805.mail.bf1.yahoo.com> Message-ID: > > > 3. Tags. > > Hierarchical tags work great. Apart from a few accessibility issues, > they > > are very usable. > > I expected one feature when clicking on "Tags"... the top level tag, any > > photo with a any tag set would be shown. Possibility for a future > version? > > > > This ticket is related to what you're asking for: http://redmine.yorba.org/issues/1402 We've talked about allowing the user to display either groupings (i.e. a single item for all photos with a particular tag) or switch to showing all photos, as you're suggesting. -- Jim From list at heinrich-muenz.de Sat Sep 3 09:58:14 2011 From: list at heinrich-muenz.de (Heiner) Date: Sat, 03 Sep 2011 11:58:14 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> Message-ID: <1315043894.1838.1.camel@ubuntu> O.K., I 'll wait and report my experience here. Thanks Heinrich Am Freitag, den 02.09.2011, 13:08 -0700 schrieb Jim Nelson: > Heinrich, > > At this point I think it's best if you tried 0.11.1, which is coming > out soon. It will have a number of bug fixes, many of them dealing > with tags and heirarchical tags (which seems to be the source of many > of these issues). You might need to clear your library and re-import > from F-Spot after you upgrade. > > -- Jim > > On Wed, Aug 31, 2011 at 10:35 PM, Heiner > wrote: > Is there any workaround fon non-coders, or will I have to > stick to f-spot? > > By the way - I've also tried to simply import my photo folders > (the > files, without using f-spots database). But that produces > unexpected > results as well: > > If I set the raw developer to "camera"before importing, it > will end up > showing nicely paired raw/jpg images - but unfortunatelly > whithout any tags. > > If I set the raw developer to "Shotwell", it will end up > having two > sparate images, raw and jpg. The jpg will be tagged correctly, > while the > raw file won't have any tags at all. > > It would be nice to have the first alternative (paired files) > with tags > - but how can I achieve this? > > Regards > Heinrich > > Am 31.08.2011 19:40, schrieb Lucas Beeler: > > >> "L 2467 2011-08-31 13:29:24 [WRN] No namespace information > for > >> XMP-Pr?fix `lr' available" > > This error is actually an unrelated and spurious artifact of > the exiv2 > > library that Shotwell uses to read metadata from files, > unfortunately > > (see this ticket here: > http://redmine.yorba.org/issues/3950). It would > > be great if it were related, 'cause that would give us more > insight > > into the problem. > > > > Cheers, > > Lucas > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From chrisgame at pobox.com Sat Sep 3 18:20:46 2011 From: chrisgame at pobox.com (Chris Game) Date: Sat, 3 Sep 2011 19:20:46 +0100 (BST) Subject: [Shotwell] 0.11 hangs on Ubuntu Natty startup In-Reply-To: References: Message-ID: On a newly installed 'Natty' system (actually Mint 11 which looks like Natty) I have not been able to start Shotwell 0.11, or indeed an earlier version 0.9. I see there were some queries a couple of weeks ago with similar symptoms. What I get is a blank window on startup with sometimes a blank 'Welcome' window too, although that isn't always the case. There's no response to any visible controls, and eventually the process has to be killed. This happens with Shotwell from the ppa, and also with a compiled version. I can't believe this is unique, so is this an active issue? I can see some similar stuff in Lauchpad but it takes ages just to trawl the last week's bug reports so I may have overlooked a relevant one. The ~/.cache/.../shotwell/log file: L 7226 2011-08-28 13:31:08 [MSG] main.vala:388: Shotwell Photo Manager 0.10.1 L 7226 2011-08-28 13:31:08 [MSG] main.vala:73: Verifying database ... L 7226 2011-08-28 13:31:08 [MSG] VideoSupport.vala:360: interpreter state cookie not found; assuming all video thumbnails are out of date L 7226 2011-08-28 13:31:09 [MSG] VideoSupport.vala:360: interpreter state cookie not found; assuming all video thumbnails are out of date From chrisgame at pobox.com Sat Sep 3 20:20:46 2011 From: chrisgame at pobox.com (Chris Game) Date: Sat, 3 Sep 2011 21:20:46 +0100 (BST) Subject: [Shotwell] 0.11 hangs on Ubuntu Natty startup In-Reply-To: References: Message-ID: As a follow up, I've posted the gdb stuff on lauchpad, bug no 4097. I tried using a Ubuntu Natty live CD and I could install and run Shotwell fine on that. Is this a Mint issue and difference to Natty I wonder? Sorry that the subject is a little misleading in that respect! As a side remark, it seems harder and harder to find a distro with a reasonable Gnome setup that runs Shotwell, particularly outside Ubuntu. Compiling on Fedora is ok, but I don't want to have to do that every month. From joseph.bylund at gmail.com Sun Sep 4 19:06:39 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Sun, 04 Sep 2011 15:06:39 -0400 Subject: [Shotwell] shotwell bails on startup Message-ID: <4E63CC3F.5090009@gmail.com> I'm having an issue where shotwell starts up but exits almost immediately. I get an GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. ** ERROR:arraylist.c:471:gee_array_list_real_get: assertion failed: (index < self->_size) Aborted error and if I do the gdb thing it doesn't quit immediately, but I can't click anywhere and I can't even ctrl+c back to my prompt. I also get: Program received signal SIGABRT, Aborted. 0x00007ffff01dbd05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c Any suggestions? Thanks. -Joe From joseph.bylund at gmail.com Sun Sep 4 21:16:48 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Sun, 04 Sep 2011 17:16:48 -0400 Subject: [Shotwell] missing dependencies for shotwell 0.11.0? Message-ID: <4E63EAC0.4050607@gmail.com> After moving my .shotwell directory to try from a fresh start I was getting an "GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications." error on natty. Looking at this bug: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/757866 I tried installing the dconf libraries which fixed everything. Maybe these should be added as dependencies of shotwell? sudo aptitude install dconf-tools libconf0 libdconf-dbus-1-0 -Joe From eric at yorba.org Mon Sep 5 18:16:39 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 11:16:39 -0700 Subject: [Shotwell] shotwell bails on startup In-Reply-To: <4E63CC3F.5090009@gmail.com> References: <4E63CC3F.5090009@gmail.com> Message-ID: On Sun, Sep 4, 2011 at 12:06 PM, Joseph Bylund wrote: > I'm having an issue where shotwell starts up but exits almost immediately. > I get an > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > not be saved or shared with other applications. > ** > ERROR:arraylist.c:471:gee_**array_list_real_get: assertion failed: (index > < self->_size) > Aborted > > error and if I do the gdb thing it doesn't quit immediately, but I can't > click anywhere and I can't even ctrl+c back to my prompt. I also get: > > Program received signal SIGABRT, Aborted. > 0x00007ffff01dbd05 in raise (sig=6) > at ../nptl/sysdeps/unix/sysv/**linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/**linux/raise.c: No such file or > directory. > in ../nptl/sysdeps/unix/sysv/**linux/raise.c > > Any suggestions? Thanks. > -Joe > Hi Joe, Good news is that this is already fixed in trunk, and will make its way into the 0.11.1 release. More info on the issue here: http://redmine.yorba.org/issues/4088 - Eric From andrew.stacey at math.ntnu.no Mon Sep 5 18:24:59 2011 From: andrew.stacey at math.ntnu.no (Andrew Stacey) Date: Mon, 5 Sep 2011 20:24:59 +0200 Subject: [Shotwell] Minor bug in makefile for local install Message-ID: <20110905182459.GD10792@fimf-t19.math.ntnu.no> Hi, I just successfully compiled Shotwell 0.11 on Debian squeeze. I installed it as a user, rather than system-wide, as I had to install a few updates of libraries. In the install step, it complained about installing the GConf stuff as it was trying to install that to the system location instead of the user location. I'd also recommend changing the error message about not finding the GStreamer pbutils plugin to say that it's part of the 'plugins-base' package. Andrew From eric at yorba.org Mon Sep 5 18:47:26 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 11:47:26 -0700 Subject: [Shotwell] 0.11 hangs on Ubuntu Natty startup In-Reply-To: References: Message-ID: On Sat, Sep 3, 2011 at 1:20 PM, Chris Game wrote: > As a follow up, I've posted the gdb stuff on lauchpad, bug no 4097. > > I tried using a Ubuntu Natty live CD and I could install and run Shotwell > fine on that. Is this a Mint issue and difference to Natty I wonder? Sorry > that the subject is a little misleading in that respect! > > As a side remark, it seems harder and harder to find a distro with a > reasonable Gnome setup that runs Shotwell, particularly outside Ubuntu. > Compiling on Fedora is ok, but I don't want to have to do that every month. It's a little hard to say; I've posted a follow-up comment on the ticket you filed about the log. It seems it wasn't attached for some reason. - Eric From eric at yorba.org Mon Sep 5 19:29:21 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 12:29:21 -0700 Subject: [Shotwell] Halting during import In-Reply-To: References: <4E5E0A87.4020402@yorba.org> Message-ID: On Thu, Sep 1, 2011 at 7:21 AM, Paulo J. Matos wrote: > I attach the logs however here are some interesting things: > > [shotwell.log]: > L 4850 2011-09-01 11:16:20 [WRN] ImportPage.vala:1392: Unable to fetch > metadata for /DCIM/100D5000/DSC_0001.NEF: [-1] Error retrieving file object > for /DCIM/100D5000/DSC_0001.NEF: Unspecified error > > > This is strange. What kind of path is that. The actual path should be > /media/4FC5-8E2D/DCIM/... > This error comes from GPhoto. The path is the path to your camera or memory card. Do you get the "unspecified error" every time? > First run halts and I killed it at 11:23:45 (closed to the end of the log). > > [shotwell1.log]: > L 8234 2011-09-01 11:33:27 [CRT] Thumbnail.vala:325: Unable to fetch > low-quality thumbnail for DataView DSC_0126.NEF [DataSource [22034] > /home/pmatos/Pictures/2011/08/**31/DSC_0126.NEF] (scale: 160): Failed to > open file '/home/pmatos/.shotwell/**thumbs/thumbs128/**thumb0000000000005612.jpg': > No such file or directory > > Can't understand what's the problem here. Should check if file exists once > I get back home but if it doesn't exist then I need to understand why it was > not created to start with. > > How does the creation of thumbnails work? I can imagine that a thread is > spawned to create the thumbnail and once that is done, an event is received > and the thumbnail is displayed. Is it something like this? > It sounds like you killed Shotwell during the import, so it didn't create a thumbnail for the image. Is that the case? If so the best thing to do is probably to remove those photos from Shotwell and re-import them. - Eric From brunogirin at gmail.com Mon Sep 5 19:35:13 2011 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 5 Sep 2011 20:35:13 +0100 Subject: [Shotwell] piwigo shotwell plugin In-Reply-To: <20110902193927.588fcbc4@gmail.com> References: <20110902185815.793f33bc@gmail.com> <20110902193122.0a836482@gmail.com> <20110902193927.588fcbc4@gmail.com> Message-ID: On 2 September 2011 20:39, Pierre Willaime wrote: > Le Fri, 2 Sep 2011 12:34:28 -0700, > Jim Nelson a ?crit : > >> Pierre, >> >> Does this ticket describe what you're asking for? >> >> http://redmine.yorba.org/issues/3750 >> >> -- Jim > > Exactly ! > > Sorry did not see this ticket. > > Thanks Pierre, I'm planning to have a look at that ticket as soon as I can (and as soon as the Shotwell source builds on Ubuntu Oneiric). Cheers, Bruno From brunogirin at gmail.com Mon Sep 5 19:47:43 2011 From: brunogirin at gmail.com (Bruno Girin) Date: Mon, 5 Sep 2011 20:47:43 +0100 Subject: [Shotwell] Vagaries of building Shotwell from source Message-ID: Hi all, I'm in a bit of a quandary, trying to build Shotwell from source. I happen to have 2 laptops: one runs Ubuntu Maverick, the other one Oneiric beta. Shotwell won't build on the former because the version of gstreamer is too old while it won't build on the latter because the version of Vala is too recent. Any idea what I can do short of installing Natty in a VM? Thanks, Bruno From eric at yorba.org Mon Sep 5 19:52:08 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 12:52:08 -0700 Subject: [Shotwell] Vagaries of building Shotwell from source In-Reply-To: References: Message-ID: On Mon, Sep 5, 2011 at 12:47 PM, Bruno Girin wrote: > I'm in a bit of a quandary, trying to build Shotwell from source. I > happen to have 2 laptops: one runs Ubuntu Maverick, the other one > Oneiric beta. Shotwell won't build on the former because the version > of gstreamer is too old while it won't build on the latter because the > version of Vala is too recent. Any idea what I can do short of > installing Natty in a VM? > Bruno, I've installed Vala 0.12 on Oneiric before. It's just a matter of building it from source. Alternately, there's a PPA that will let you install a newer GStreamer on Maverick. Some info about that here: http://www.omgubuntu.co.uk/2011/08/shotwell-0-11-lucid-users/ - Eric From eric at yorba.org Mon Sep 5 19:56:26 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 12:56:26 -0700 Subject: [Shotwell] missing dependencies for shotwell 0.11.0? In-Reply-To: <4E63EAC0.4050607@gmail.com> References: <4E63EAC0.4050607@gmail.com> Message-ID: On Sun, Sep 4, 2011 at 2:16 PM, Joseph Bylund wrote: > After moving my .shotwell directory to try from a fresh start I was getting > an > > "GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings > will not be saved or shared with other applications." > > error on natty. Looking at this bug: https://bugs.launchpad.net/** > ubuntu/+source/glib2.0/+bug/**757866 > > I tried installing the dconf libraries which fixed everything. Maybe these > should be added as dependencies of shotwell? > > sudo aptitude install dconf-tools libconf0 libdconf-dbus-1-0 > Hi Joe, I believe libdconf0 is all you need. Isn't this installed by default on Natty? In theory, GSettings can use other backends aside from dconf, and we'd like to support that if it makes sense to do so. - Eric From wmstrome at yahoo.com Mon Sep 5 20:08:54 2011 From: wmstrome at yahoo.com (Murray Strome) Date: Mon, 5 Sep 2011 13:08:54 -0700 (PDT) Subject: [Shotwell] Shotwell Duplicate Handling Message-ID: <1315253334.1322.YahooMailClassic@web160319.mail.bf1.yahoo.com> When I first open Shotwell and pick the photos to import, when it is finished, it gives a report saying something like "XXX duplicate images not imported and YYY not imported" .. because something was wrong with them. It then lists several images and ends with "... and ZZZZZ others). I don't really want duplicated images, but all too often, it loads the poorest quality ones. For example, if there are some full resolution TIFF images, and the same ones as full resolution JPEG, and another set of low resolution JPEG for E-Mail, and Thumbnails for them, it will often load the lowest resolution version. Is there a way to set it so that if there are duplicate images like this, it will pick the highest resolution ones? I am using Shotwell version 0.9.3 with XUbuntu 11.04. Thanks for your help. Murray From eric at yorba.org Mon Sep 5 20:20:43 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 5 Sep 2011 13:20:43 -0700 Subject: [Shotwell] Shotwell Duplicate Handling In-Reply-To: <1315253334.1322.YahooMailClassic@web160319.mail.bf1.yahoo.com> References: <1315253334.1322.YahooMailClassic@web160319.mail.bf1.yahoo.com> Message-ID: On Mon, Sep 5, 2011 at 1:08 PM, Murray Strome wrote: > When I first open Shotwell and pick the photos to import, when it is > > finished, it gives a report saying something like "XXX duplicate images not > > imported and YYY not imported" .. because something was wrong with them. It > > then lists several images and ends with "... and ZZZZZ others). > > > > I don't really want duplicated images, but all too often, it loads the > > poorest quality ones. For example, if there are some full resolution TIFF > > images, and the same ones as full resolution JPEG, and another set of low > > resolution JPEG for E-Mail, and Thumbnails for them, it will often load the > > lowest resolution version. Is there a way to set it so that if there are > > duplicate images like this, it will pick the highest resolution ones? > > > > I am using Shotwell version 0.9.3 with XUbuntu 11.04. > Hi Murray, Are you sure both photos aren't being imported? How is this problem manifesting itself within Shotwell? The way duplicate checking works in Shotwell is it performs a byte-for-byte check on the file. It's not based on filenames or image data or anything like that. - Eric From chrisgame at pobox.com Mon Sep 5 20:44:15 2011 From: chrisgame at pobox.com (Chris Game) Date: Mon, 5 Sep 2011 21:44:15 +0100 (BST) Subject: [Shotwell] 0.11 hangs on Ubuntu Natty startup In-Reply-To: References: Message-ID: Logfile now attached to bug report. As it's only a few bytes, and in plain text, here it is: L 4000 2011-09-04 21:18:29 [MSG] main.vala:388: Shotwell Photo Manager 0.10.1 L 4000 2011-09-04 21:18:29 [MSG] main.vala:73: Verifying database ... L 4000 2011-09-04 21:18:29 [MSG] VideoSupport.vala:360: interpreter state cookie not found; assuming all video thumbnails are out of date L 4000 2011-09-04 21:18:30 [MSG] VideoSupport.vala:360: interpreter state cookie not found; assuming all video thumbnails are out of date Regds, Chris Game On Mon, 5 Sep 2011, Eric Gregory wrote: > On Sat, Sep 3, 2011 at 1:20 PM, Chris Game wrote: > >> As a follow up, I've posted the gdb stuff on lauchpad, bug no 4097. >> >> I tried using a Ubuntu Natty live CD and I could install and run Shotwell >> fine on that. Is this a Mint issue and difference to Natty I wonder? Sorry >> that the subject is a little misleading in that respect! >> >> As a side remark, it seems harder and harder to find a distro with a >> reasonable Gnome setup that runs Shotwell, particularly outside Ubuntu. >> Compiling on Fedora is ok, but I don't want to have to do that every month. > > > It's a little hard to say; I've posted a follow-up comment on the ticket you > filed about the log. It seems it wasn't attached for some reason. > > - Eric > From chrisgame at pobox.com Mon Sep 5 21:27:43 2011 From: chrisgame at pobox.com (Chris Game) Date: Mon, 5 Sep 2011 22:27:43 +0100 (BST) Subject: [Shotwell] 0.11 hangs on Ubuntu Natty startup In-Reply-To: References: Message-ID: Sorry, ignore previous message re log file, I copied the wrong logfile from another system altogether (too many distros on this machine!) I've deleted that one from the report. Hopefully the right logfile is now in the bug report, too big to quote here though. Regds, Chris Game On Mon, 5 Sep 2011, Eric Gregory wrote: > On Sat, Sep 3, 2011 at 1:20 PM, Chris Game wrote: > >> As a follow up, I've posted the gdb stuff on lauchpad, bug no 4097. >> >> I tried using a Ubuntu Natty live CD and I could install and run Shotwell >> fine on that. Is this a Mint issue and difference to Natty I wonder? Sorry >> that the subject is a little misleading in that respect! >> >> As a side remark, it seems harder and harder to find a distro with a >> reasonable Gnome setup that runs Shotwell, particularly outside Ubuntu. >> Compiling on Fedora is ok, but I don't want to have to do that every month. > > > It's a little hard to say; I've posted a follow-up comment on the ticket you > filed about the log. It seems it wasn't attached for some reason. > > - Eric > From jim at yorba.org Mon Sep 5 21:55:42 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 5 Sep 2011 14:55:42 -0700 Subject: [Shotwell] Minor bug in makefile for local install In-Reply-To: <20110905182459.GD10792@fimf-t19.math.ntnu.no> References: <20110905182459.GD10792@fimf-t19.math.ntnu.no> Message-ID: On Mon, Sep 5, 2011 at 11:24 AM, Andrew Stacey wrote: > Hi, > > I just successfully compiled Shotwell 0.11 on Debian squeeze. I installed > it > as a user, rather than system-wide, as I had to install a few updates of > libraries. In the install step, it complained about installing the GConf > stuff as it was trying to install that to the system location instead of > the > user location. > > Can you send us the exact error messages you were seeing during install? > I'd also recommend changing the error message about not finding the > GStreamer > pbutils plugin to say that it's part of the 'plugins-base' package. > That error message is not generated by our Makefile but by pkg-config (which our Makefile invokes to check for dependencies). Unfortunately, the GStreamer package names can be misleading, but that's out of our control. -- Jim From guiyou65 at hotmail.com Mon Sep 5 22:41:26 2011 From: guiyou65 at hotmail.com (Thierry Le Guillou) Date: Tue, 6 Sep 2011 00:41:26 +0200 Subject: [Shotwell] IPTC Tag Message-ID: Could it be possible to add IPTC tag Author as an editable value just like Keywords or Title ? It is very useful when pictures are from different sources. Thierry From andrew.stacey at math.ntnu.no Tue Sep 6 16:29:54 2011 From: andrew.stacey at math.ntnu.no (Andrew Stacey) Date: Tue, 6 Sep 2011 18:29:54 +0200 Subject: [Shotwell] Minor bug in makefile for local install In-Reply-To: References: <20110905182459.GD10792@fimf-t19.math.ntnu.no> Message-ID: <20110906162954.GA23048@fimf-t19.math.ntnu.no> On Mon, Sep 05, 2011 at 02:55:42PM -0700, Jim Nelson wrote: > Can you send us the exact error messages you were seeing during install? Yes, it is: mkdir -p /usr/share/GConf/gsettings mkdir: cannot create directory `/usr/share/GConf': Permission denied make: *** [install] Error 1 > I'd also recommend changing the error message about not finding the > GStreamer pbutils plugin to say that it's part of the 'plugins-base' > package. > > That error message is not generated by our Makefile but by pkg-config > (which our Makefile invokes to check for dependencies). Unfortunately, > the GStreamer package names can be misleading, but that's out of our > control. Ah, well. It was a fairly obvious internet search, I suppose. Andrew From andrew.stacey at math.ntnu.no Tue Sep 6 16:35:04 2011 From: andrew.stacey at math.ntnu.no (Andrew Stacey) Date: Tue, 6 Sep 2011 18:35:04 +0200 Subject: [Shotwell] Converting between "create links" and "copy pictures" Message-ID: <20110906163504.GB23048@fimf-t19.math.ntnu.no> (Apologies if this has been asked before.) I've imported my photos via "create links" but now I'd like to switch over to having Shotwell manage the organisation of the files as well. Is there a way to do this? Obviously, I could just delete the whole database and reimport them, but then I'd lose all the tags and edits, so is there a better way? (I have about 14k photos so doing it one by one wouldn't be acceptable either.) Thanks, Andrew Stacey From guiyou65 at hotmail.com Tue Sep 6 17:59:51 2011 From: guiyou65 at hotmail.com (Thierry Le Guillou) Date: Tue, 6 Sep 2011 19:59:51 +0200 Subject: [Shotwell] IPTC Tag In-Reply-To: References: Message-ID: I understand "eventually" for "all other metadata", but I think that a Pictures manager software should offer Title, Date, Keywords as it is, and Author (or Copyright) wich is a very useful tag when you manage pictures from various origin. I hope the ticket coud find a restrictive issue with the minimum tags pictures management need. I love this soft, that is why ! Thierry Le 06/09/2011 01:44, Eric Gregory a ?crit : > On Mon, Sep 5, 2011 at 3:41 PM, Thierry Le Guillou > > wrote: > > Could it be possible to add IPTC tag Author as an editable value > just like Keywords or Title ? > It is very useful when pictures are from different sources. > Thierry > > > We're eventually planning on adding support for editing these and all > other metadata fields in Shotwell. > > The ticket for this is here: > http://redmine.yorba.org/issues/3103 > > - Eric From eric at yorba.org Tue Sep 6 18:40:09 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 6 Sep 2011 11:40:09 -0700 Subject: [Shotwell] Converting between "create links" and "copy pictures" In-Reply-To: <20110906163504.GB23048@fimf-t19.math.ntnu.no> References: <20110906163504.GB23048@fimf-t19.math.ntnu.no> Message-ID: On Tue, Sep 6, 2011 at 9:35 AM, Andrew Stacey wrote: > (Apologies if this has been asked before.) > > I've imported my photos via "create links" but now I'd like to switch over > to > having Shotwell manage the organisation of the files as well. Is there a > way > to do this? Obviously, I could just delete the whole database and reimport > them, but then I'd lose all the tags and edits, so is there a better way? > > (I have about 14k photos so doing it one by one wouldn't be acceptable > either.) Hi Andrew, If you just move (not copy) the files to Shotwell's pictures folder, then start Shotwell and drag that photo into Shotwell, it will recognize the photos but update their location in the DB. Note that it may take a while for this process since you have so many photos. Is there some particular reason you want to do this? - Eric From jim at yorba.org Tue Sep 6 19:16:09 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 6 Sep 2011 12:16:09 -0700 Subject: [Shotwell] IPTC Tag In-Reply-To: References: Message-ID: Hi Thierry, We have a lot of features we'd like to add to Shotwell, but only so much time to work on it. I do think what you're suggesting is important, so I've created a separate ticket (http://redmine.yorba.org/issues/4101) which is aimed at allowing editing of common metadata fields from the Basic and/or Extended Information panes. I can't promise when this feature will be ready, but we appreciate your suggestion and will keep it in mind as we move forward. -- Jim On Tue, Sep 6, 2011 at 10:59 AM, Thierry Le Guillou wrote: > I understand "eventually" for "all other metadata", but I think that a > Pictures manager software should offer Title, Date, Keywords as it is, and > Author (or Copyright) wich is a very useful tag when you manage pictures > from various origin. > I hope the ticket coud find a restrictive issue with the minimum tags > pictures management need. > I love this soft, that is why ! > Thierry > > > Le 06/09/2011 01:44, Eric Gregory a ?crit : > >> On Mon, Sep 5, 2011 at 3:41 PM, Thierry Le Guillou > guiyou65 at hotmail.com>> wrote: >> >> Could it be possible to add IPTC tag Author as an editable value >> just like Keywords or Title ? >> It is very useful when pictures are from different sources. >> Thierry >> >> >> We're eventually planning on adding support for editing these and all >> other metadata fields in Shotwell. >> >> The ticket for this is here: >> http://redmine.yorba.org/**issues/3103 >> >> - Eric >> > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From guiyou65 at hotmail.com Tue Sep 6 22:10:04 2011 From: guiyou65 at hotmail.com (Thierry Le Guillou) Date: Wed, 7 Sep 2011 00:10:04 +0200 Subject: [Shotwell] Directory location Message-ID: I have my pictures collection stored on /media/data/Pictures and all other common pictures in /home/Thierry/Pictures. So I call "shotwell -d /media/Aux/Pictures" when I want to manage my collection and "shotwell" without argument when I just want to see standard pictures in My images directory. But since the preferences are saved in .gconf/apps/shotwell, the information about the import directory is shared, so it is the same for the two profiles, and then I get a big mess with auto-scan, or I don't auto scan but I have to change the directory each time. So, could it be possible to store the profile information in the same directory than database. So profiles will really be independants and related to the -d option ? Thierry From eric at yorba.org Tue Sep 6 22:58:30 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 6 Sep 2011 15:58:30 -0700 Subject: [Shotwell] Directory location In-Reply-To: References: Message-ID: On Tue, Sep 6, 2011 at 3:10 PM, Thierry Le Guillou wrote: > I have my pictures collection stored on /media/data/Pictures and all other > common pictures in /home/Thierry/Pictures. > So I call "shotwell -d /media/Aux/Pictures" when I want to manage my > collection and "shotwell" without argument when I just want to see standard > pictures in My images directory. > But since the preferences are saved in .gconf/apps/shotwell, the > information about the import directory is shared, so it is the same for the > two profiles, and then I get a big mess with auto-scan, or I don't auto scan > but I have to change the directory each time. > > So, could it be possible to store the profile information in the same > directory than database. So profiles will really be independants and related > to the -d option ? > Thierry > We have a ticket for turning this use-case into a more general feature, where you can have multiple Shotwell "profiles" and each profile can have its own database and preferences. http://redmine.yorba.org/issues/2146 - Eric From jim at yorba.org Tue Sep 6 23:01:50 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 6 Sep 2011 16:01:50 -0700 Subject: [Shotwell] Minor bug in makefile for local install In-Reply-To: <20110906162954.GA23048@fimf-t19.math.ntnu.no> References: <20110905182459.GD10792@fimf-t19.math.ntnu.no> <20110906162954.GA23048@fimf-t19.math.ntnu.no> Message-ID: I see. Unfortunately, that directory is a requirement to install the conversion keyfile for gsettings-data-convert. This is the program that migrates your GConf keys to gsettings. There's no alternate directory to use: http://developer.gnome.org/gio/2.26/ch26s07.html The best we could do is allow for the Shotwell installation to be configured not to install this file. That means, however, that your GConf keys won't be migrated when you run Shotwell, requiring the user to manually change their Preferences to reflect their needs. It also means all publishing keys and session tokens would be lost, requiring the user to log back in when they attempted to share their photos. I've ticketed this here: http://redmine.yorba.org/issues/4102 We'll attempt to get this in to 0.11.1. Cheers, -- Jim On Tue, Sep 6, 2011 at 9:29 AM, Andrew Stacey wrote: > On Mon, Sep 05, 2011 at 02:55:42PM -0700, Jim Nelson wrote: > > Can you send us the exact error messages you were seeing during > install? > > Yes, it is: > > mkdir -p /usr/share/GConf/gsettings mkdir: cannot create directory > `/usr/share/GConf': Permission denied > make: *** [install] Error 1 > > > > I'd also recommend changing the error message about not finding the > > GStreamer pbutils plugin to say that it's part of the 'plugins-base' > > package. > > > > That error message is not generated by our Makefile but by pkg-config > > (which our Makefile invokes to check for dependencies). > Unfortunately, > > the GStreamer package names can be misleading, but that's out of our > > control. > > Ah, well. It was a fairly obvious internet search, I suppose. > > Andrew > From jim at yorba.org Tue Sep 6 23:30:29 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 6 Sep 2011 16:30:29 -0700 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: > What would be necessary for you to apply a patch like this one? Would you > want symlink support to be utterly bulletproof? Broken symlinks should be > noticed and counted as "missing"? Monitors installed on places where > symlinks point? I'm willing to do the legwork if I know what the > requirements are. > > Utterly bulletproof is always good. Getting a patch landed right now is difficult because we need to consider all the use cases for symbolic links, especially the perils and pitfalls. Monitoring each symlink might be overkill. What I should've asked before was, why can't you simply create a symlink from your Pictures directory to the git annex directory? That would solve this problem right away, I think. Library monitoring should work as well. I've attached your patch to the ticket with a link to the message, for future reference: http://redmine.yorba.org/issues/2983 -- Jim From adam at yorba.org Wed Sep 7 02:27:06 2011 From: adam at yorba.org (Adam Dingle) Date: Wed, 07 Sep 2011 06:27:06 +0400 Subject: [Shotwell] Vagaries of building Shotwell from source In-Reply-To: References: Message-ID: <4E66D67A.90402@yorba.org> On 09/05/2011 11:52 PM, Eric Gregory wrote: > On Mon, Sep 5, 2011 at 12:47 PM, Bruno Girin wrote: > >> I'm in a bit of a quandary, trying to build Shotwell from source. I >> happen to have 2 laptops: one runs Ubuntu Maverick, the other one >> Oneiric beta. Shotwell won't build on the former because the version >> of gstreamer is too old while it won't build on the latter because the >> version of Vala is too recent. Any idea what I can do short of >> installing Natty in a VM? >> > Bruno, I've installed Vala 0.12 on Oneiric before. It's just a matter of > building it from source. There's no need to build Vala 0.12 from source on Oneiric: simply install the valac-0.12 package. adam From paulo at matos-sorge.com Wed Sep 7 21:04:52 2011 From: paulo at matos-sorge.com (Paulo Matos) Date: Wed, 7 Sep 2011 21:04:52 +0000 (UTC) Subject: [Shotwell] Wierd date duplicates Message-ID: Hi, I have noticed this before and I thought it would be sorted out with new versions coming but 0.11 is here and the problem persists. I keep having duplicates dates on my side bar. Please find a screenshot at http://tinypic.com/r/als1er/7 so that you see what I mean. Any tips on how to analyze this issue further? Cheers, -- PMatos From eric at yorba.org Wed Sep 7 21:15:11 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 7 Sep 2011 14:15:11 -0700 Subject: [Shotwell] Wierd date duplicates In-Reply-To: References: Message-ID: On Wed, Sep 7, 2011 at 2:04 PM, Paulo Matos wrote: > I have noticed this before and I thought it would be sorted out with new > versions coming but 0.11 is here and the problem persists. I keep having > duplicates dates on my side bar. > > Please find a screenshot at http://tinypic.com/r/als1er/7 so that you see > what I mean. Any tips on how to analyze this issue further? > This is a known issue. Shotwell creates new events every time it imports, instead of adding images to existing events. We have a ticket to change this behavior here: http://redmine.yorba.org/issues/3565 - Eric From ethan.glasser.camp at gmail.com Wed Sep 7 23:04:42 2011 From: ethan.glasser.camp at gmail.com (Ethan) Date: Wed, 7 Sep 2011 19:04:42 -0400 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: On Tue, Sep 6, 2011 at 7:30 PM, Jim Nelson wrote: > What I should've asked before was, why can't you simply create a symlink > from your Pictures directory to the git annex directory? That would solve > this problem right away, I think. Library monitoring should work as well. > That's a good idea but the filenames would be long and ugly instead of the symlink filenames :) Also I'm thinking in terms of XMP sidecars. I'd want the sidecars next to the symlinks to be used, and don't want sidecars next to the symlink targets to be used. But I'll accept that this might be idiosyncratic to my use case. I see two or three decisions to be made in regards to symlinked-file support: - Should a broken symlink count as missing files? I propose that whatever you do for symlinked directories, symlinked files should behave the same way. (The patch I sent you will mark broken symlinks as missing but only on startup.) - Should monitors be installed on symlink targets? I think it would be best if we could but you mentioned a system limit on the number of monitors. I did a test on my system (Ubuntu natty+oneiric, Linux kernel 3.0.0.9) and wrote a program that opens monitors on every directory in a directory tree. I ran it on my home directory and it stopped at 31728 -- this is also the number of directories found by find -type "d". How do you feel about a patch to unconditionally install monitors on symlinked files' directories? If that turns out to cause problems, we can keep those monitors separate and monitor them only as resources allow. These are the only perils and pitfalls I can think of. Do you see any I missed? I think with these changes (and I'll hack them up if you like), symlinks can be as robust as they can be. Ethan From joseph.bylund at gmail.com Thu Sep 8 18:17:40 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Thu, 08 Sep 2011 14:17:40 -0400 Subject: [Shotwell] multithreaded "preparing for upload" Message-ID: <4E6906C4.9000300@gmail.com> I'm not quite sure what's going on on preparing for upload, but it can really take quite a long time at least from a users standpoint. I looked at top while this was going on and noted shotwell was only using one core. Is there something that is being performed for each photo to be uploaded? If so maybe the photos could be split into groups and each core could handle some of the work? Specifically I'm uploading about 80 high res photos to flickr. -Joe From eric at yorba.org Thu Sep 8 18:49:54 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 8 Sep 2011 11:49:54 -0700 Subject: [Shotwell] multithreaded "preparing for upload" In-Reply-To: <4E6906C4.9000300@gmail.com> References: <4E6906C4.9000300@gmail.com> Message-ID: On Thu, Sep 8, 2011 at 11:17 AM, Joseph Bylund wrote: > I'm not quite sure what's going on on preparing for upload, but it can > really take quite a long time at least from a users standpoint. I looked at > top while this was going on and noted shotwell was only using one core. Is > there something that is being performed for each photo to be uploaded? If > so maybe the photos could be split into groups and each core could handle > some of the work? Specifically I'm uploading about 80 high res photos to > flickr. > Each time a photo gets uploaded, it has to be "exported" to the temporary folder. This can take some time for large images and/or cases where you've made changes to the image with Shotwell. The export process tends to be more I/O bound than CPU bound, so multi-threading this operation isn't likely to result in a performance increase. That said, I'd be really interested in how long the images took to upload, and how large they are. We're trying to make Shotwell scale better, and this is an area we hadn't considered. Also depending how large these images are, it might be helpful if you could send us one or more sample images for testing on our side. - Eric From brunogirin at gmail.com Thu Sep 8 21:52:43 2011 From: brunogirin at gmail.com (Bruno Girin) Date: Thu, 08 Sep 2011 22:52:43 +0100 Subject: [Shotwell] Vagaries of building Shotwell from source In-Reply-To: <4E66D67A.90402@yorba.org> References: <4E66D67A.90402@yorba.org> Message-ID: <4E69392B.50909@gmail.com> On 07/09/11 03:27, Adam Dingle wrote: > On 09/05/2011 11:52 PM, Eric Gregory wrote: >> On Mon, Sep 5, 2011 at 12:47 PM, Bruno Girin >> wrote: >> >>> I'm in a bit of a quandary, trying to build Shotwell from source. I >>> happen to have 2 laptops: one runs Ubuntu Maverick, the other one >>> Oneiric beta. Shotwell won't build on the former because the version >>> of gstreamer is too old while it won't build on the latter because the >>> version of Vala is too recent. Any idea what I can do short of >>> installing Natty in a VM? >>> >> Bruno, I've installed Vala 0.12 on Oneiric before. It's just a >> matter of >> building it from source. > > There's no need to build Vala 0.12 from source on Oneiric: simply > install the valac-0.12 package. That's fine, building Vala from source is quite easy so I now have it sorted, thanks! Hopefully I can find time to fix some bugs now. Bruno From eric at yorba.org Thu Sep 8 21:58:44 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 8 Sep 2011 14:58:44 -0700 Subject: [Shotwell] Vagaries of building Shotwell from source In-Reply-To: <4E69392B.50909@gmail.com> References: <4E66D67A.90402@yorba.org> <4E69392B.50909@gmail.com> Message-ID: On Thu, Sep 8, 2011 at 2:52 PM, Bruno Girin wrote: > On 07/09/11 03:27, Adam Dingle wrote: > >> On 09/05/2011 11:52 PM, Eric Gregory wrote: >> >>> On Mon, Sep 5, 2011 at 12:47 PM, Bruno Girin >>> wrote: >>> >>> I'm in a bit of a quandary, trying to build Shotwell from source. I >>>> happen to have 2 laptops: one runs Ubuntu Maverick, the other one >>>> Oneiric beta. Shotwell won't build on the former because the version >>>> of gstreamer is too old while it won't build on the latter because the >>>> version of Vala is too recent. Any idea what I can do short of >>>> installing Natty in a VM? >>>> >>>> Bruno, I've installed Vala 0.12 on Oneiric before. It's just a matter >>> of >>> building it from source. >>> >> >> There's no need to build Vala 0.12 from source on Oneiric: simply install >> the valac-0.12 package. >> > > That's fine, building Vala from source is quite easy so I now have it > sorted, thanks! Hopefully I can find time to fix some bugs now. > Good to hear! We're rolling out Shotwell 0.11.1 today. It's likely there will be a .2 following within a week or thereabouts. Depending what you're fixing now, we might be able to squeeze it into 0.11.2. Something to keep in mind. - Eric From eric at yorba.org Thu Sep 8 23:52:39 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 8 Sep 2011 16:52:39 -0700 Subject: [Shotwell] Shotwell 0.11.1 released Message-ID: Today Yorba has released Shotwell 0.11.1. This is a bug fix release; we recommend all users upgrade. Changelog: * RAW+JPEG pairing now works on file import * Startup crashes fixed * Hierarchical tag issues resolved * RAW developer bugs fixed * Resolved internationalization problems * Various small fixes and enhancements Download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ Binaries for Ubuntu Natty is available at Yorba?s Launchpad PPA: https://launchpad.net/~yorba/+archive/ppa From list at heinrich-muenz.de Fri Sep 9 07:05:43 2011 From: list at heinrich-muenz.de (list at heinrich-muenz.de) Date: Fri, 9 Sep 2011 09:05:43 +0200 (CEST) Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E5F199F.6040807@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> Message-ID: <8908852.7999184.1315551943800.JavaMail.tomcat55@mrmseu1.kundenserver.de> I've tried importing my f-spot database into shotwell 0.11.1 today. Raw+Jpeg works fine now, but there are still the same issues with tag imports from f-spot. Espacially the error ("L 2467 2011-08-31 13:29:24 [WRN] No namespace information for >> XMP-Pr?fix `lr' available") is quite annoying, because it makes shotwell crash. Isn't there any workaround? I'd really like to move from f-spot to shotwell, but I don't want to tag a few thousand photos manually. Heiner From ian at mnementh.co.uk Fri Sep 9 09:19:42 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Fri, 09 Sep 2011 10:19:42 +0100 Subject: [Shotwell] Shotwell 0.11.1 released In-Reply-To: References: Message-ID: <1315559982.1874.0.camel@wirenth> On Thu, 2011-09-08 at 16:52 -0700, Eric Gregory wrote: > Today Yorba has released Shotwell 0.11.1. This is a bug fix release; we > recommend all users upgrade. > > Changelog: > > * RAW+JPEG pairing now works on file import > * Startup crashes fixed > * Hierarchical tag issues resolved Would this include the dragging-a-tag-to-itself-duplicates-it issue? From list at heinrich-muenz.de Fri Sep 9 11:02:49 2011 From: list at heinrich-muenz.de (list at heinrich-muenz.de) Date: Fri, 9 Sep 2011 13:02:49 +0200 (CEST) Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E5F199F.6040807@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> Message-ID: <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> O.K., I've found the solution, and it's not shotwell's fault: In f-spot, some of my tags were containing slashes (e.g. House/Garden or Nature/Landscape). Since shotwell uses slashes to produce a tag hierarchy, it cannot handle this. After changing the respective tags, shotwell now is importing flawlessly. Change at last!!! Thanks for your efforts! From lucas at yorba.org Fri Sep 9 17:59:59 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 9 Sep 2011 10:59:59 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> Message-ID: Hi, Thanks for reporting this! This is indeed a bug, because Shotwell includes code that "sanitizes" (i.e. removes forward slash characters from) tag names on import. Shotwell does this on import from the filesystem and auto-import, but it doesn't properly run the sanitization code during F-Spot import. I've ticketed this issue here:http://redmine.yorba.org/issues/4108 Cheers, Lucas On Fri, Sep 9, 2011 at 4:02 AM, wrote: > > O.K., I've found the solution, and it's not shotwell's fault: In f-spot, some of my tags were containing slashes (e.g. House/Garden or Nature/Landscape). Since shotwell uses slashes to produce a tag hierarchy, it cannot handle this. After changing the respective tags, shotwell now is importing flawlessly. > > Change at last!!! > > Thanks for your efforts! > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Fri Sep 9 18:17:18 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 9 Sep 2011 11:17:18 -0700 Subject: [Shotwell] Shotwell 0.11.1 released In-Reply-To: <1315559982.1874.0.camel@wirenth> References: <1315559982.1874.0.camel@wirenth> Message-ID: Yes, that is fixed: http://redmine.yorba.org/issues/4036 -- Jim On Fri, Sep 9, 2011 at 2:19 AM, Ian Molton wrote: > On Thu, 2011-09-08 at 16:52 -0700, Eric Gregory wrote: > > Today Yorba has released Shotwell 0.11.1. This is a bug fix release; we > > recommend all users upgrade. > > > > Changelog: > > > > * RAW+JPEG pairing now works on file import > > * Startup crashes fixed > > * Hierarchical tag issues resolved > > Would this include the dragging-a-tag-to-itself-duplicates-it issue? > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From brunogirin at gmail.com Fri Sep 9 21:23:49 2011 From: brunogirin at gmail.com (Bruno Girin) Date: Fri, 09 Sep 2011 22:23:49 +0100 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> Message-ID: <4E6A83E5.5050602@gmail.com> Thanks for fixing my naive implementation! I don't think I would have found how to code it properly... Cheers, Bruno On 09/09/11 18:59, Lucas Beeler wrote: > Hi, > > Thanks for reporting this! This is indeed a bug, because Shotwell > includes code that "sanitizes" (i.e. removes forward slash characters > from) tag names on import. Shotwell does this on import from the > filesystem and auto-import, but it doesn't properly run the > sanitization code during F-Spot import. I've ticketed this issue > here:http://redmine.yorba.org/issues/4108 > > Cheers, > Lucas > > On Fri, Sep 9, 2011 at 4:02 AM, wrote: >> O.K., I've found the solution, and it's not shotwell's fault: In f-spot, some of my tags were containing slashes (e.g. House/Garden or Nature/Landscape). Since shotwell uses slashes to produce a tag hierarchy, it cannot handle this. After changing the respective tags, shotwell now is importing flawlessly. >> >> Change at last!!! >> >> Thanks for your efforts! >> >> _______________________________________________ >> 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 lucas at yorba.org Fri Sep 9 21:42:15 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 9 Sep 2011 14:42:15 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E6A83E5.5050602@gmail.com> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: Bruno, your implementation was great! It was just a mild oversight. In fact, I made *exactly* the same mistake when adapting the library monitoring / auto-import code for hierarchical tags! Thank you so much for helping us with this. As you can see from the mailing list traffic, people are definitely using your code to get their F-Spot data into Shotwell and it seems very solid! Lucas On Fri, Sep 9, 2011 at 2:23 PM, Bruno Girin wrote: > Thanks for fixing my naive implementation! I don't think I would have found > how to code it properly... > > Cheers, > > Bruno > > On 09/09/11 18:59, Lucas Beeler wrote: >> >> Hi, >> >> Thanks for reporting this! This is indeed a bug, because Shotwell >> includes code that "sanitizes" (i.e. removes forward slash characters >> from) tag names on import. Shotwell does this on import from the >> filesystem and auto-import, but it doesn't properly run the >> sanitization code during F-Spot import. I've ticketed this issue >> here:http://redmine.yorba.org/issues/4108 >> >> Cheers, >> Lucas >> >> On Fri, Sep 9, 2011 at 4:02 AM, ?wrote: >>> >>> O.K., I've found the solution, and it's not shotwell's fault: In f-spot, >>> some of my tags were containing slashes (e.g. House/Garden or >>> Nature/Landscape). Since shotwell uses slashes to produce a tag hierarchy, >>> it cannot handle this. After changing the respective tags, shotwell now is >>> importing flawlessly. >>> >>> Change at last!!! >>> >>> Thanks for your efforts! >>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From pt at traversin.org Fri Sep 9 21:55:58 2011 From: pt at traversin.org (pt) Date: Fri, 9 Sep 2011 23:55:58 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: On 9 September 2011 23:42, Lucas Beeler wrote: > for helping us with this. As you can see from the mailing list > traffic, people are definitely using your code to get their F-Spot > data into Shotwell and it seems very solid! About the f-spot import, any news on when the flat tags will be correctly imported into the tags hierarchy? (i.e instead of becoming new root-level tags) I reckon this is the ticket #4051, and it makes the f-spot import pretty useless if one had the tags written to the photos metadata -- I am pretty sure I'm not the only one using this option. Maybe for the 0.11.2? Am I being too optimistic? :-) Piergi -- Web: http://traversin.org GNU/Linux user 190604 From lucas at yorba.org Fri Sep 9 23:08:36 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 9 Sep 2011 16:08:36 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: Hi pt, I'm a little unclear about what you mean by "when the flat tags will be imported correctly...instead of becoming new root-level tags." If a tag is a flat tag in F-Spot, whereby "flat tag" I mean that it has no parent, then the correct behavior is to import it as a new root-level tag in Shotwell, because, hey, it was a root-level tag in F-Spot. So I don't understand the problem. Unless I'm missing something, which I very well may be. ;-) Lucas On Fri, Sep 9, 2011 at 2:55 PM, pt wrote: > On 9 September 2011 23:42, Lucas Beeler wrote: >> for helping us with this. As you can see from the mailing list >> traffic, people are definitely using your code to get their F-Spot >> data into Shotwell and it seems very solid! > > About the f-spot import, any news on when the flat tags will be > correctly imported into the tags hierarchy? (i.e instead of becoming > new root-level tags) > > I reckon this is the ticket #4051, and it makes the f-spot import > pretty useless if one had the tags written to the photos metadata -- I > am pretty sure I'm not the only one using this option. > > Maybe for the 0.11.2? Am I being too optimistic? :-) > > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From pt at traversin.org Fri Sep 9 23:20:34 2011 From: pt at traversin.org (pt) Date: Sat, 10 Sep 2011 01:20:34 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: On 10 September 2011 01:08, Lucas Beeler wrote: > I'm a little unclear about what you mean by "when the flat tags will > be imported correctly...instead of becoming new root-level tags." If a > tag is a flat tag in F-Spot, whereby "flat tag" I mean that it has no > parent, then the correct behavior is to import it as a new root-level > tag in Shotwell, because, hey, it was a root-level tag in F-Spot. So I > don't understand the problem. Unless I'm missing something, which I > very well may be. ;-) Sorry, I did not make myself clear: f-spot has a hierarchical tag lists, but writes only 'flat' tags, in the Xmp:Subject field, in a comma separated list. At the moment, when you import from f-spot in shotwell, shotwell gets correctly the tags hierarchy, but then it reads the tags from the photos -- if you had them written in the files metadata -- and for every tag that is not in the top-level in the f-spot hierarchy, shotwell creates a *new* root-level tag, duplicating the one already in the tags tree. I hope this is clear. Any way, we have already a ticket for that, #4051, and I was asking for news, because this bug renders -- for me and for people with tags into the photos metadata -- the import from f-spot impossible. On a partially unrelated note, until one cannot select multiple tags for moving them around the tree in shotwell, adjusting the tags tree after each import would be a PITA. Ciao ciao, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From lucas at yorba.org Fri Sep 9 23:28:23 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 9 Sep 2011 16:28:23 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: Hi pt, The bug you're referring to is actually this one: http://redmine.yorba.org/issues/4081, which is special for the F-Spot case. It should've been fixed in 0.11.1. Are you still seeing this behavior with Shotwell 0.11.1, released last night? Lucas On Fri, Sep 9, 2011 at 4:20 PM, pt wrote: > On 10 September 2011 01:08, Lucas Beeler wrote: >> I'm a little unclear about what you mean by "when the flat tags will >> be imported correctly...instead of becoming new root-level tags." If a >> tag is a flat tag in F-Spot, whereby "flat tag" I mean that it has no >> parent, then the correct behavior is to import it as a new root-level >> tag in Shotwell, because, hey, it was a root-level tag in F-Spot. So I >> don't understand the problem. Unless I'm missing something, which I >> very well may be. ;-) > > > Sorry, I did not make myself clear: f-spot has a hierarchical tag > lists, but writes only 'flat' tags, in the Xmp:Subject field, in a > comma separated list. > > > At the moment, when you import from f-spot in shotwell, shotwell gets > correctly the tags hierarchy, but then it reads the tags from the > photos -- if you had them written in the files metadata -- and for > every tag that is not in the top-level in the f-spot hierarchy, > shotwell creates a *new* root-level tag, duplicating the one already > in the tags tree. I hope this is clear. > > > Any way, we have already a ticket for that, #4051, and I was asking > for news, because this bug renders -- for me and for people with tags > into the photos metadata -- the import from f-spot impossible. > > > On a partially unrelated note, until one cannot select multiple tags > for moving them around the tree in shotwell, adjusting the tags tree > after each import would be a PITA. > > > Ciao ciao, > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From pt at traversin.org Sat Sep 10 00:06:52 2011 From: pt at traversin.org (pt) Date: Sat, 10 Sep 2011 02:06:52 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: Hi Lucas On 10 September 2011 01:28, Lucas Beeler wrote: > > The bug you're referring to is actually this one: > http://redmine.yorba.org/issues/4081, which is special for the F-Spot > case. It should've been fixed in 0.11.1. Are you still seeing this > behavior with Shotwell 0.11.1, released last night? I am aware of this ticket, I tried with 0.11.1 and it was not working. The only difference I saw from the 0.11.0 version is (if I recall correctly) that the latter would duplicate *both* root-level and children tags, while 0.11.1 duplicates 'only' children tags. I don't know why it is set as 'fixed': it is not. Any way the ticket I was referring is the more general #4501. As a side note, the 'resolution' proposed in the ticket description ('we can ignore tags present in the photo files and only use tags from the F-Spot database') is self-contradictory, because this problem exists only 'for any F-Spot user who's storing tags inside photo files'. (As you can imagine, it is long time I am waiting for hierarchical tags to be working to move my collection from f-spot to shotwell. Looks like I'll have to wait more. Unfortunately I'm not developer so I can't help aside from beta-testing.) Ciao ciao, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From adam at yorba.org Sat Sep 10 05:45:40 2011 From: adam at yorba.org (Adam Dingle) Date: Sat, 10 Sep 2011 09:45:40 +0400 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: <4E6AF984.5040201@yorba.org> On 09/10/2011 03:20 AM, pt wrote: > On 10 September 2011 01:08, Lucas Beeler wrote: >> I'm a little unclear about what you mean by "when the flat tags will >> be imported correctly...instead of becoming new root-level tags." If a >> tag is a flat tag in F-Spot, whereby "flat tag" I mean that it has no >> parent, then the correct behavior is to import it as a new root-level >> tag in Shotwell, because, hey, it was a root-level tag in F-Spot. So I >> don't understand the problem. Unless I'm missing something, which I >> very well may be. ;-) > > Sorry, I did not make myself clear: f-spot has a hierarchical tag > lists, but writes only 'flat' tags, in the Xmp:Subject field, in a > comma separated list. > > > At the moment, when you import from f-spot in shotwell, shotwell gets > correctly the tags hierarchy, but then it reads the tags from the > photos -- if you had them written in the files metadata -- and for > every tag that is not in the top-level in the f-spot hierarchy, > shotwell creates a *new* root-level tag, duplicating the one already > in the tags tree. I hope this is clear. > > > Any way, we have already a ticket for that, #4051, and I was asking > for news, because this bug renders -- for me and for people with tags > into the photos metadata -- the import from f-spot impossible. The problem you're describing was #4081: http://redmine.yorba.org/issues/4081 . It was fixed before the 0.11.1 release. > > > On a partially unrelated note, until one cannot select multiple tags > for moving them around the tree in shotwell, adjusting the tags tree > after each import would be a PITA. > Right. That's http://redmine.yorba.org/issues/2275 and is targeted for 0.12. adam From brunogirin at gmail.com Sat Sep 10 10:13:45 2011 From: brunogirin at gmail.com (Bruno Girin) Date: Sat, 10 Sep 2011 11:13:45 +0100 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> Message-ID: <4E6B3859.20808@gmail.com> On 10/09/11 01:06, pt wrote: > Hi Lucas > > > On 10 September 2011 01:28, Lucas Beeler wrote: >> The bug you're referring to is actually this one: >> http://redmine.yorba.org/issues/4081, which is special for the F-Spot >> case. It should've been fixed in 0.11.1. Are you still seeing this >> behavior with Shotwell 0.11.1, released last night? > > I am aware of this ticket, I tried with 0.11.1 and it was not working. > The only difference I saw from the 0.11.0 version is (if I recall > correctly) that the latter would duplicate *both* root-level and > children tags, while 0.11.1 duplicates 'only' children tags. Piergi, What would be really useful to help understand and fix the problem is if you could provide us with an example. Take one of your photos and provide us with the following info: * The tag hierarchy in F-Spot, * The tag entries in the photo metadata, * The resulting tag hierarchy when you import that photo from F-Spot to Shotwell, * What you would have expected the tag hierarchy to be in Shotwell (i.e. where did it go wrong). > I don't know why it is set as 'fixed': it is not. Any way the ticket I > was referring is the more general #4501. That's because your understanding of the problem is different from the developers'. By providing the details above, we can fully understand where the problem is and fix it. Ciao, Bruno From jcasadonte at northbound-train.com Sat Sep 10 19:11:04 2011 From: jcasadonte at northbound-train.com (Joe Casadonte) Date: Sat, 10 Sep 2011 15:11:04 -0400 Subject: [Shotwell] GConf errors in 11.1 Message-ID: <87hb4k8b7b.fsf@terrapin.northbound-train.com> Hi, I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using package from https://launchpad.net/~flexiondotorg/+archive/shotwell). I'm receiving the following errors on startup: ** Message: GConfEngine.vala:188: Error loading or parsing gsettings convert keyfile: Valid key file could not be found in search dirs ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf settings to gsettings... ** Message: GConfEngine.vala:207: Error running gsettings-data-convert: Failed to execute child process "gsettings-data-convert" (No such file or directory) GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. Also, every time I start up I get the "Updating library..." message for about 30 seconds. The package was installed with root privileges, so the directory /usr/share/GConf/gsetting exists (as does the file /usr/share/GConf/gsetting/shotwell.convert). Anything I need to be worried about? Thanks for a great piece of software! -- Regards, joe Joe Casadonte jcasadonte at northbound-train.com From pt at traversin.org Sat Sep 10 19:57:11 2011 From: pt at traversin.org (pt) Date: Sat, 10 Sep 2011 21:57:11 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E6B3859.20808@gmail.com> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> Message-ID: On 10 September 2011 12:13, Bruno Girin wrote: > Piergi, > > What would be really useful to help understand and fix the problem is if you > could provide us with an example. Take one of your photos and provide us > with the following info: > ?* The tag hierarchy in F-Spot, http://traversin.org/shotwell-test/FSpotScreenshot.png > ?* The tag entries in the photo metadata, http://traversin.org/shotwell-test/BeforeImport.txt > ?* The resulting tag hierarchy when you import that photo from F-Spot to > Shotwell, http://traversin.org/shotwell-test/AfterImport.txt http://traversin.org/shotwell-test/AfterImportScreenshot.png > ?* What you would have expected the tag hierarchy to be in Shotwell (i.e. > where did it go wrong). In the words of the ticket #4081: 'When Shotwell imports from the F-Spot database, it will create two copies of each hierarchical tag: one inside the tag hierarchy and one at top level.' Well, it still do in version 0.11.1. I know that English is not my first language, but what I am trying to say is just that what is happening is what is described in the ticket. As in 'not-fixed'. That's what I did: A very simple f-spot database (three photos, see screenshot) exiftool -all:all * > BeforeImport.txt Import in shotwell (see screenshot): shotwell added the children tags both in the correct hierarchy and as top-level tags. exiftool -all:all * > AfterImport.txt Any clue? I've put the three photos (after the shotwell import) in the same directory with a csv version of the output of exiftool as well: http://traversin.org/shotwell-test/ Ciao ciao, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From eric at yorba.org Sat Sep 10 20:22:23 2011 From: eric at yorba.org (Eric Gregory) Date: Sat, 10 Sep 2011 13:22:23 -0700 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: <87hb4k8b7b.fsf@terrapin.northbound-train.com> References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> Message-ID: On Sat, Sep 10, 2011 at 12:11 PM, Joe Casadonte < jcasadonte at northbound-train.com> wrote: > Hi, > > I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using > package from https://launchpad.net/~flexiondotorg/+archive/shotwell > ). > > I'm receiving the following errors on startup: > > ** Message: GConfEngine.vala:188: Error loading or parsing gsettings > convert keyfile: Valid key file could not be found in search dirs > ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf settings > to gsettings... > ** Message: GConfEngine.vala:207: Error running gsettings-data-convert: > Failed to execute child process "gsettings-data-convert" (No such file or > directory) > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > not be saved or shared with other applications. > > Also, every time I start up I get the "Updating library..." message for > about 30 seconds. > > The package was installed with root privileges, so the directory > /usr/share/GConf/gsetting exists (as does the file > /usr/share/GConf/gsetting/shotwell.convert). > > Anything I need to be worried about? Thanks for a great piece of software! > Hi Joe, You're running Shotwell on an unsupported configuration, so we can't offer any detailed help. That said, it sounds like you just don't have gsettings-data-convert installed. Shotwell 0.11 requires GSettings, along with dconf. You might want to work with the manager of that package to ensure Shotwell has the correct requirements for running on Ubuntu 10.04. - Eric From apeitheo at gmail.com Sun Sep 11 03:10:48 2011 From: apeitheo at gmail.com (Brad Hermanson) Date: Sat, 10 Sep 2011 23:10:48 -0400 Subject: [Shotwell] Does not register camera on Slackware: Kodak EasyShare CX7430 Message-ID: <4E6C26B8.3010104@gmail.com> I compiled Shotwell 0.11.1 (and 0.11) on Slackware 13.37 and everything went well except for the fact that it does not fully detect my camera (Kodak EasyShare CX7430). It never shows up on the side bar. I took a look at the logs and found this: L 15060 2011-09-10 22:17:03 [DBG] CameraTable.vala:369: udev event: add on 5-1 L 15060 2011-09-10 22:17:03 [DBG] CameraTable.vala:369: udev event: add on 5-1:1.0 L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:249: Detected 1/1 Kodak CX7430 @ usb:005,005 L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:149: USB ESP: current_camera_count=1 port=usb:005,005 L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:192: USB ESP: No matching bus/device found for port=usb:005,005 L 15060 2011-09-10 22:17:09 [DBG] CameraTable.vala:369: udev event: remove on 5-1:1.0 L 15060 2011-09-10 22:17:09 [DBG] CameraTable.vala:369: udev event: remove on 5-1 I didn't look too deeply into the code, but I put together a patch that fixed the problem (at least for me.. I don't know what ramifications it would have on others). Maybe something isn't configured correctly on my system, but I'm hoping someone knows why this is happening. Here is the patch: --- src/camera/CameraTable.vala 2011-08-23 14:19:18.000000000 -0400 +++ src/camera/CameraTable.vala 2011-09-06 19:42:17.052993293 -0400 @@ -157,6 +157,15 @@ return true; } + // Fix for Kodak camera; camera will not show up otherwise + if (current_camera_count == 1) { + full_port = port; + + debug("USB ESP: port=%s full_port=%s", port, full_port); + + return true; + } + // with more than one camera, skip the mirrored "usb:" port if (port == "usb:") { debug("USB ESP: Skipping %s", port); After adding this patch, the log file shows: L 18721 2011-09-10 23:00:03 [DBG] CameraTable.vala:378: udev event: add on 5-1 L 18721 2011-09-10 23:00:03 [DBG] CameraTable.vala:378: udev event: add on 5-1:1.0 L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:258: Detected 1/1 Kodak CX7430 @ usb:005,008 L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:149: USB ESP: current_camera_count=1 port=usb:005,008 L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:164: USB ESP: port=usb:005,008 full_port=usb:005,008 L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:368: Adding to camera table: Kodak CX7430 @ usb:005,008 This fixes the problem for me and then the camera shows up and I can download photos, etc, and everything works as expected. This same camera with shotwell on a recent version of Ubuntu works perfectly fine... I'm not sure what to make of it. I don't know if Ubuntu has patched Shotwell, or if they simply have something configured differently. I'm going to be making the package available for Slackware users, so if this is a Slackware-specific problem, any hints as to what I've not configured/configured incorrectly would be greatly appreciated. Thank you, Brad From adam at yorba.org Sun Sep 11 06:00:27 2011 From: adam at yorba.org (Adam Dingle) Date: Sun, 11 Sep 2011 10:00:27 +0400 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> Message-ID: <4E6C4E7B.2080708@yorba.org> Piergi, On 09/10/2011 11:57 PM, pt wrote: > Any clue? I've put the three photos (after the shotwell import) in the > same directory with a csv version of the output of exiftool as well: > http://traversin.org/shotwell-test/ Ciao ciao, Piergi I just tested this and you're right: we thought we had fixed this bug in 0.11.1, but it's still present. I've reopened the ticket: http://redmine.yorba.org/issues/4081 Hopefully we can fix this for 0.11.2. adam From list at heinrich-muenz.de Mon Sep 12 05:22:25 2011 From: list at heinrich-muenz.de (Heiner) Date: Mon, 12 Sep 2011 07:22:25 +0200 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: <4E5F199F.6040807@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> Message-ID: <4E6D9711.2010509@heinrich-muenz.de> Is there an easy way to refresh thumbnails (manually or automatically) after editing photos outside shotwell? I've googled around for this and found some older postings saying this should be possible since 0.8, but I can't see it in 0.11.1. From caccolangrifata at gmail.com Mon Sep 12 10:32:18 2011 From: caccolangrifata at gmail.com (caccolangrifata) Date: Mon, 12 Sep 2011 12:32:18 +0200 Subject: [Shotwell] Saved Search - Modified photo Message-ID: <1315823538.7729.3.camel@mind> Hi all! It would be great to ad an option to the Saved Search that make possible to search only modified photo. Cheers! -- Emanuele Grande OpenPGP key: 1024D/BF9328A7 | j.mp/cJTR3C 9F22 91FE F054 185D 3376 910E 62B3 85D6 BF93 28A7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From martin+shotwell at flexion.org Mon Sep 12 12:45:12 2011 From: martin+shotwell at flexion.org (Martin Wimpress) Date: Mon, 12 Sep 2011 13:45:12 +0100 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: <87hb4k8b7b.fsf@terrapin.northbound-train.com> References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> Message-ID: Hi, Have you enabled the GStreamer Developers PPA? * ppa:gstreamer-developers/ppa For Shotwell 0.11 onward this is now a requirement for Lucid and Maverick. Regards, Martin. On Sat, 10 Sep 2011 15:11:04 -0400, Joe Casadonte wrote: > Hi, > > I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using > package from https://launchpad.net/~flexiondotorg/+archive/shotwell). > > I'm receiving the following errors on startup: > > ** Message: GConfEngine.vala:188: Error loading or parsing gsettings > convert keyfile: Valid key file could not be found in search dirs > ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf > settings to gsettings... > ** Message: GConfEngine.vala:207: Error running > gsettings-data-convert: Failed to execute child process > "gsettings-data-convert" (No such file or directory) > GLib-GIO-Message: Using the 'memory' GSettings backend. Your > settings will not be saved or shared with other applications. > > Also, every time I start up I get the "Updating library..." message > for > about 30 seconds. > > The package was installed with root privileges, so the directory > /usr/share/GConf/gsetting exists (as does the file > /usr/share/GConf/gsetting/shotwell.convert). > > Anything I need to be worried about? Thanks for a great piece of > software! -- Regards, Martin. From micketu at gmail.com Mon Sep 12 14:54:51 2011 From: micketu at gmail.com (Mikael Turesson) Date: Mon, 12 Sep 2011 16:54:51 +0200 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> Message-ID: <1315839291.3133.9.camel@turmikubuntu.zf.if.atcsg.net> Hello Martin ! I have the same problem running on X86-64 Lucid. I have the GStreamer devel ppa enabled. You can run shotwell and import photos but you cannot save any property changes in the application. Thanx for your work Martin I really prefer shotwell before F-Spot so if it isn't a quickfix I'll mangage with the situation as is !! Regards Mike m?n 2011-09-12 klockan 13:45 +0100 skrev Martin Wimpress: > Hi, > > Have you enabled the GStreamer Developers PPA? > > * ppa:gstreamer-developers/ppa > > For Shotwell 0.11 onward this is now a requirement for Lucid and > Maverick. > > Regards, Martin. > > On Sat, 10 Sep 2011 15:11:04 -0400, Joe Casadonte wrote: > > Hi, > > > > I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using > > package from https://launchpad.net/~flexiondotorg/+archive/shotwell). > > > > I'm receiving the following errors on startup: > > > > ** Message: GConfEngine.vala:188: Error loading or parsing gsettings > > convert keyfile: Valid key file could not be found in search dirs > > ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf > > settings to gsettings... > > ** Message: GConfEngine.vala:207: Error running > > gsettings-data-convert: Failed to execute child process > > "gsettings-data-convert" (No such file or directory) > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your > > settings will not be saved or shared with other applications. > > > > Also, every time I start up I get the "Updating library..." message > > for > > about 30 seconds. > > > > The package was installed with root privileges, so the directory > > /usr/share/GConf/gsetting exists (as does the file > > /usr/share/GConf/gsetting/shotwell.convert). > > > > Anything I need to be worried about? Thanks for a great piece of > > software! > From joseph.bylund at gmail.com Mon Sep 12 15:09:55 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Mon, 12 Sep 2011 11:09:55 -0400 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: <1315839291.3133.9.camel@turmikubuntu.zf.if.atcsg.net> References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> <1315839291.3133.9.camel@turmikubuntu.zf.if.atcsg.net> Message-ID: <4E6E20C3.2080809@gmail.com> To fix the "GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications." error on natty. Try installing the dconf libraries. sudo aptitude install dconf-tools libdconf0 libdconf-dbus-1-0 For me this silenced the error, and allowed me to save settings. -Joe On 09/12/2011 10:54 AM, Mikael Turesson wrote: > Hello Martin ! > > I have the same problem running on X86-64 Lucid. I have the GStreamer > devel ppa enabled. You can run shotwell and import photos but you cannot > save any property changes in the application. > > Thanx for your work Martin I really prefer shotwell before F-Spot so if > it isn't a quickfix I'll mangage with the situation as is !! > > Regards > Mike > > m?n 2011-09-12 klockan 13:45 +0100 skrev Martin Wimpress: >> Hi, >> >> Have you enabled the GStreamer Developers PPA? >> >> * ppa:gstreamer-developers/ppa >> >> For Shotwell 0.11 onward this is now a requirement for Lucid and >> Maverick. >> >> Regards, Martin. >> >> On Sat, 10 Sep 2011 15:11:04 -0400, Joe Casadonte wrote: >>> Hi, >>> >>> I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using >>> package from https://launchpad.net/~flexiondotorg/+archive/shotwell). >>> >>> I'm receiving the following errors on startup: >>> >>> ** Message: GConfEngine.vala:188: Error loading or parsing gsettings >>> convert keyfile: Valid key file could not be found in search dirs >>> ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf >>> settings to gsettings... >>> ** Message: GConfEngine.vala:207: Error running >>> gsettings-data-convert: Failed to execute child process >>> "gsettings-data-convert" (No such file or directory) >>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your >>> settings will not be saved or shared with other applications. >>> >>> Also, every time I start up I get the "Updating library..." message >>> for >>> about 30 seconds. >>> >>> The package was installed with root privileges, so the directory >>> /usr/share/GConf/gsetting exists (as does the file >>> /usr/share/GConf/gsetting/shotwell.convert). >>> >>> Anything I need to be worried about? Thanks for a great piece of >>> software! > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From micketu at gmail.com Mon Sep 12 16:56:42 2011 From: micketu at gmail.com (Mikael Turesson) Date: Mon, 12 Sep 2011 18:56:42 +0200 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: <4E6E20C3.2080809@gmail.com> References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> <1315839291.3133.9.camel@turmikubuntu.zf.if.atcsg.net> <4E6E20C3.2080809@gmail.com> Message-ID: <1315846602.2257.20.camel@turmikubuntu.zf.if.atcsg.net> Hi Joe, I saw this the first time you posted it but these libs aren't availible for 10.04 lucid(yes I've tried it). Martin has done a good job backport shotwell to the 10.04 LTS ubuntu but I recon it will be harder for him when the yorba team use more of the newer options/libs in later versions of Ubuntu that he has to take into consideration when making up the backported versions. I have no problems with the statement from the yorba team about not supporting older versions of Ubuntu(even thou I think it's a pity) so I'm pleased with the fact that one guy(Martin) is doin all this effort for us that think you don't have to have the latest version all the time. But thank you for the tip Joe I'll remember it when I upgrade. Best Regards Mike m?n 2011-09-12 klockan 11:09 -0400 skrev Joseph Bylund: > To fix the > > "GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings > will not be saved or shared with other applications." > > error on natty. Try installing the dconf libraries. > > sudo aptitude install dconf-tools libdconf0 libdconf-dbus-1-0 > > For me this silenced the error, and allowed me to save settings. > > -Joe > > > On 09/12/2011 10:54 AM, Mikael Turesson wrote: > > Hello Martin ! > > > > I have the same problem running on X86-64 Lucid. I have the GStreamer > > devel ppa enabled. You can run shotwell and import photos but you cannot > > save any property changes in the application. > > > > Thanx for your work Martin I really prefer shotwell before F-Spot so if > > it isn't a quickfix I'll mangage with the situation as is !! > > > > Regards > > Mike > > > > m?n 2011-09-12 klockan 13:45 +0100 skrev Martin Wimpress: > >> Hi, > >> > >> Have you enabled the GStreamer Developers PPA? > >> > >> * ppa:gstreamer-developers/ppa > >> > >> For Shotwell 0.11 onward this is now a requirement for Lucid and > >> Maverick. > >> > >> Regards, Martin. > >> > >> On Sat, 10 Sep 2011 15:11:04 -0400, Joe Casadonte wrote: > >>> Hi, > >>> > >>> I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 (using > >>> package from https://launchpad.net/~flexiondotorg/+archive/shotwell). > >>> > >>> I'm receiving the following errors on startup: > >>> > >>> ** Message: GConfEngine.vala:188: Error loading or parsing gsettings > >>> convert keyfile: Valid key file could not be found in search dirs > >>> ** (process:12177): DEBUG: GConfEngine.vala:191: Converting GConf > >>> settings to gsettings... > >>> ** Message: GConfEngine.vala:207: Error running > >>> gsettings-data-convert: Failed to execute child process > >>> "gsettings-data-convert" (No such file or directory) > >>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your > >>> settings will not be saved or shared with other applications. > >>> > >>> Also, every time I start up I get the "Updating library..." message > >>> for > >>> about 30 seconds. > >>> > >>> The package was installed with root privileges, so the directory > >>> /usr/share/GConf/gsetting exists (as does the file > >>> /usr/share/GConf/gsetting/shotwell.convert). > >>> > >>> Anything I need to be worried about? Thanks for a great piece of > >>> software! > > > > _______________________________________________ > > 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 eric at yorba.org Mon Sep 12 17:51:50 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 12 Sep 2011 10:51:50 -0700 Subject: [Shotwell] Saved Search - Modified photo In-Reply-To: <1315823538.7729.3.camel@mind> References: <1315823538.7729.3.camel@mind> Message-ID: On Mon, Sep 12, 2011 at 3:32 AM, caccolangrifata wrote: > Hi all! > > It would be great to ad an option to the Saved Search that make possible > to search only modified photo. > > Cheers! > -- > Emanuele Grande > OpenPGP key: 1024D/BF9328A7 | j.mp/cJTR3C > 9F22 91FE F054 185D 3376 910E 62B3 85D6 BF93 28A7 Agreed! I filed a ticket on this here: http://redmine.yorba.org/issues/4111 Free free to add comments or suggestions there. - Eric From eric at yorba.org Mon Sep 12 18:08:08 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 12 Sep 2011 11:08:08 -0700 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: <4E6D9711.2010509@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> Message-ID: On Sun, Sep 11, 2011 at 10:22 PM, Heiner wrote: > Is there an easy way to refresh thumbnails (manually or automatically) > after editing photos outside shotwell? I've googled around for this and > found some older postings saying this should be possible since 0.8, but > I can't see it in 0.11.1. > When you say "outside of Shotwell" do you mean you're launching an external editor from within Shotwell, or you're launching the editor outside of Shotwell? The first way, the thumbnail should refresh as soon as you close the editor. The second way, it should eventually refresh, though it may take some time for Shotwell to recognize a change has been made to the file. You can force a thumbnail to refresh by performing an edit within Shotwell, then undoing the edit. This certainly is not a "recommended" way, but it's a viable workaround if you've encountered a bug where thumbnails aren't refreshing. - Eric From jim at yorba.org Mon Sep 12 18:37:55 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 12 Sep 2011 11:37:55 -0700 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> Message-ID: Just to chime in, if you launch an image editor from outside Shotwell and edit a photo while Shotwell is running, the change will only be noticed by Shotwell if you have library monitoring turned on (Edit -> Preferences -> Watch library directory for new files) *and* the photo file is somewhere in your library directory (i.e. the directory listed right above this checkbox). Otherwise, Shotwell will only notice the change the next time you start it. -- Jim On Mon, Sep 12, 2011 at 11:08 AM, Eric Gregory wrote: > On Sun, Sep 11, 2011 at 10:22 PM, Heiner wrote: > > > Is there an easy way to refresh thumbnails (manually or automatically) > > after editing photos outside shotwell? I've googled around for this and > > found some older postings saying this should be possible since 0.8, but > > I can't see it in 0.11.1. > > > > When you say "outside of Shotwell" do you mean you're launching an external > editor from within Shotwell, or you're launching the editor outside of > Shotwell? > > The first way, the thumbnail should refresh as soon as you close the > editor. The second way, it should eventually refresh, though it may take > some time for Shotwell to recognize a change has been made to the file. > > You can force a thumbnail to refresh by performing an edit within Shotwell, > then undoing the edit. This certainly is not a "recommended" way, but it's > a viable workaround if you've encountered a bug where thumbnails aren't > refreshing. > > - Eric > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Mon Sep 12 19:18:28 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 12 Sep 2011 12:18:28 -0700 Subject: [Shotwell] Does not register camera on Slackware: Kodak EasyShare CX7430 In-Reply-To: <4E6C26B8.3010104@gmail.com> References: <4E6C26B8.3010104@gmail.com> Message-ID: Hi Brad, It looks to me that there's something going wrong in the code in Shotwell that matches up the camera's address on the USB bus with the gphoto2 address (which is what we need to use to communicate with gphoto2, which talks to the camera). There's a few things we need you to do to diagnose this problem. First, from the console, run Shotwell like this: $ SHOTWELL_LOG=1 shotwell With Shotwell running, plug in the camera, wait for a ten seconds (presumably Shotwell won't show it), and then unplug the camera. Exit Shotwell. Then find this file: ~/.cache/shotwell/shotwell.log We need this log file. Second, run this command with the camera plugged in: $ sudo lsusb -v > lsusb.txt Third, run this command with the camera plugged in: $ udevadm info --export-db > udev.txt Finally, run this command with the camera plugged in: $ gphoto2 --list-ports > gphoto2.txt (You might need to install the gphoto2 package in order for this last one to work.) Then send us all these files: shotwell.log, lsusb.txt, udev.txt, gphoto2.txt Thanks, -- Jim On Sat, Sep 10, 2011 at 8:10 PM, Brad Hermanson wrote: > I compiled Shotwell 0.11.1 (and 0.11) on Slackware 13.37 and everything > went well except for the fact that it does not fully detect my camera (Kodak > EasyShare CX7430). It never shows up on the side bar. I took a look at the > logs and found this: > > L 15060 2011-09-10 22:17:03 [DBG] CameraTable.vala:369: udev event: add on > 5-1 > L 15060 2011-09-10 22:17:03 [DBG] CameraTable.vala:369: udev event: add on > 5-1:1.0 > L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:249: Detected 1/1 Kodak > CX7430 @ usb:005,005 > L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:149: USB ESP: > current_camera_count=1 port=usb:005,005 > L 15060 2011-09-10 22:17:04 [DBG] CameraTable.vala:192: USB ESP: No > matching bus/device found for port=usb:005,005 > L 15060 2011-09-10 22:17:09 [DBG] CameraTable.vala:369: udev event: remove > on 5-1:1.0 > L 15060 2011-09-10 22:17:09 [DBG] CameraTable.vala:369: udev event: remove > on 5-1 > > I didn't look too deeply into the code, but I put together a patch that > fixed the problem (at least for me.. I don't know what ramifications it > would have on others). Maybe something isn't configured correctly on my > system, but I'm hoping someone knows why this is happening. > > Here is the patch: > > --- src/camera/CameraTable.vala 2011-08-23 14:19:18.000000000 -0400 > +++ src/camera/CameraTable.vala 2011-09-06 19:42:17.052993293 -0400 > @@ -157,6 +157,15 @@ > return true; > } > > + // Fix for Kodak camera; camera will not show up otherwise > + if (current_camera_count == 1) { > + full_port = port; > + > + debug("USB ESP: port=%s full_port=%s", port, full_port); > + > + return true; > + } > + > // with more than one camera, skip the mirrored "usb:" port > if (port == "usb:") { > debug("USB ESP: Skipping %s", port); > > After adding this patch, the log file shows: > > L 18721 2011-09-10 23:00:03 [DBG] CameraTable.vala:378: udev event: add on > 5-1 > L 18721 2011-09-10 23:00:03 [DBG] CameraTable.vala:378: udev event: add on > 5-1:1.0 > L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:258: Detected 1/1 Kodak > CX7430 @ usb:005,008 > L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:149: USB ESP: > current_camera_count=1 port=usb:005,008 > L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:164: USB ESP: > port=usb:005,008 full_port=usb:005,008 > L 18721 2011-09-10 23:00:04 [DBG] CameraTable.vala:368: Adding to camera > table: Kodak CX7430 @ usb:005,008 > > This fixes the problem for me and then the camera shows up and I can > download photos, etc, and everything works as expected. This same camera > with shotwell on a recent version of Ubuntu works perfectly fine... I'm not > sure what to make of it. I don't know if Ubuntu has patched Shotwell, or if > they simply have something configured differently. I'm going to be making > the package available for Slackware users, so if this is a > Slackware-specific problem, any hints as to what I've not > configured/configured incorrectly would be greatly appreciated. > > Thank you, > Brad > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From lucas at yorba.org Mon Sep 12 22:18:54 2011 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 12 Sep 2011 15:18:54 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: <4E6C4E7B.2080708@yorba.org> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: Adam & pt: How did you guys manage to reproduce this? I've tried, tried, and tried again. What's more, when I look at my log file, I see this: L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'carol' from file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'red' from file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'green' from file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'john' from file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'dave' from file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's already known as a hierarchical tag component L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'blue' from file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's already known as a hierarchical tag component which indicates to me that the tag knockout code is doing what it's supposed to. The role of the tag knockout code is to remove flat tags that are merely duplicates of hierarchical tag components so as to prevent child tags from re-appearing as top-level tags during f-spot import -- i.e., the knockout code should've closed #4081. When you run Shotwell with logging turned on, do you see similar messages? Cheers, Lucas On Sat, Sep 10, 2011 at 11:00 PM, Adam Dingle wrote: > Piergi, > > On 09/10/2011 11:57 PM, pt wrote: >> >> Any clue? I've put the three photos (after the shotwell import) in the >> same directory with a csv version of the output of exiftool as well: >> http://traversin.org/shotwell-test/ Ciao ciao, Piergi > > I just tested this and you're right: we thought we had fixed this bug in > 0.11.1, but it's still present. ?I've reopened the ticket: > > http://redmine.yorba.org/issues/4081 > > Hopefully we can fix this for 0.11.2. > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Mon Sep 12 22:27:02 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 12 Sep 2011 15:27:02 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: pt, To chime in, the way to get Shotwell to run with full logging is like this: $ SHOTWELL_LOG=1 shotwell After you exit Shotwell, examine ~/.cache/shotwell/shotwell.log -- Jim On Mon, Sep 12, 2011 at 3:18 PM, Lucas Beeler wrote: > Adam & pt: > > How did you guys manage to reproduce this? I've tried, tried, and > tried again. What's more, when I look at my log file, I see this: > > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'carol' from > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'red' from > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'green' from > file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'john' from > file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from > file '/home/lucas/Pictures/Photos/2011/08/28/green.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'dave' from > file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'friends' from > file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's > already known as a hierarchical tag component > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'blue' from > file '/home/lucas/Pictures/Photos/2011/08/28/blue.jpg' because it's > already known as a hierarchical tag component > > which indicates to me that the tag knockout code is doing what it's > supposed to. The role of the tag knockout code is to remove flat tags > that are merely duplicates of hierarchical tag components so as to > prevent child tags from re-appearing as top-level tags during f-spot > import -- i.e., the knockout code should've closed #4081. When you run > Shotwell with logging turned on, do you see similar messages? > > Cheers, > Lucas > > On Sat, Sep 10, 2011 at 11:00 PM, Adam Dingle wrote: > > Piergi, > > > > On 09/10/2011 11:57 PM, pt wrote: > >> > >> Any clue? I've put the three photos (after the shotwell import) in the > >> same directory with a csv version of the output of exiftool as well: > >> http://traversin.org/shotwell-test/ Ciao ciao, Piergi > > > > I just tested this and you're right: we thought we had fixed this bug in > > 0.11.1, but it's still present. I've reopened the ticket: > > > > http://redmine.yorba.org/issues/4081 > > > > Hopefully we can fix this for 0.11.2. > > > > adam > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > From pt at traversin.org Mon Sep 12 23:40:15 2011 From: pt at traversin.org (pt) Date: Tue, 13 Sep 2011 01:40:15 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: On 13 September 2011 00:18, Lucas Beeler wrote: > Adam & pt: > > How did you guys manage to reproduce this? I've tried, tried, and > tried again. What's more, when I look at my log file, I see this: > > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'carol' from > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's > already known as a hierarchical tag component > > which indicates to me that the tag knockout code is doing what it's > supposed to. The role of the tag knockout code is to remove flat tags > that are merely duplicates of hierarchical tag components so as to > prevent child tags from re-appearing as top-level tags during f-spot > import -- i.e., the knockout code should've closed #4081. When you run > Shotwell with logging turned on, do you see similar messages? I ran shotwell with logging on, and importing those same photos I got the exact same result as you, and a correct tag tree (no duplicates). So initially I was as puzzled as you, because nothing changed in my configuration, then I remembered the computer rule #1: 'the problem is between the keyboard and the chair'. My guess is you have to delete the 'LastKeywordXMP' and 'TagsList' fields added by shotwell to the test photos: my photos were 'after import' so they included hierarchical tags information added by shotwell. I did 'exiftool -all:all= *jpg' on those files, then imported in f-spot and tagged, then imported from s-spot to shotwell and I got the same results as the other day (i.e. duplicate tags). The relevant screenshot is: http://traversin.org/shotwell-test/AfterImportScreenshot2.png (This time I didn't put the top-level tags 'blue, red, green', just the friends' names.) The worst part is that my shotwell.log *does* say it is knocking out the flat tags, but eventually the tags are duplicated as top-level tags. The log file is: http://traversin.org/shotwell-test/shotwell.log The photos in the directory are 'after import', if you want to use them for a test remember to strip the tags added by shotwell, or, even better, all tags. Ciao, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From jim at yorba.org Mon Sep 12 23:50:29 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 12 Sep 2011 16:50:29 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: Thanks for sending this along, Piergi, your troubleshooting is very helpful. It sounds like there is still some kind of issue here, although it may be slightly different than what we fixed in 0.11.1. I'll let Lucas look into this and report back to the list. -- Jim On Mon, Sep 12, 2011 at 4:40 PM, pt wrote: > On 13 September 2011 00:18, Lucas Beeler wrote: > > Adam & pt: > > > > How did you guys manage to reproduce this? I've tried, tried, and > > tried again. What's more, when I look at my log file, I see this: > > > > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'carol' from > > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's > > already known as a hierarchical tag component > > > > which indicates to me that the tag knockout code is doing what it's > > supposed to. The role of the tag knockout code is to remove flat tags > > that are merely duplicates of hierarchical tag components so as to > > prevent child tags from re-appearing as top-level tags during f-spot > > import -- i.e., the knockout code should've closed #4081. When you run > > Shotwell with logging turned on, do you see similar messages? > > > I ran shotwell with logging on, and importing those same photos I got > the exact same result as you, and a correct tag tree (no duplicates). > So initially I was as puzzled as you, because nothing changed in my > configuration, then I remembered the computer rule #1: 'the problem is > between the keyboard and the chair'. > > My guess is you have to delete the 'LastKeywordXMP' and 'TagsList' > fields added by shotwell to the test photos: my photos were 'after > import' so they included hierarchical tags information added by > shotwell. > > I did 'exiftool -all:all= *jpg' on those files, then imported in > f-spot and tagged, then imported from s-spot to shotwell and I got the > same results as the other day (i.e. duplicate tags). > > The relevant screenshot is: > > http://traversin.org/shotwell-test/AfterImportScreenshot2.png > > (This time I didn't put the top-level tags 'blue, red, green', just > the friends' names.) > > The worst part is that my shotwell.log *does* say it is knocking out > the flat tags, but eventually the tags are duplicated as top-level > tags. > > The log file is: > > http://traversin.org/shotwell-test/shotwell.log > > The photos in the directory are 'after import', if you want to use > them for a test remember to strip the tags added by shotwell, or, even > better, all tags. > > Ciao, > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Tue Sep 13 00:46:41 2011 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 12 Sep 2011 17:46:41 -0700 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: pt, Jim, and Adam, Thanks for all your hard sleuthing! I got what I needed and this bug is now fixed in master! Cheers, Lucas On Mon, Sep 12, 2011 at 4:50 PM, Jim Nelson wrote: > Thanks for sending this along, Piergi, your troubleshooting is very > helpful. ?It sounds like there is still some kind of issue here, although it > may be slightly different than what we fixed in 0.11.1. ?I'll let Lucas look > into this and report back to the list. > > -- Jim > > On Mon, Sep 12, 2011 at 4:40 PM, pt wrote: > >> On 13 September 2011 00:18, Lucas Beeler wrote: >> > Adam & pt: >> > >> > How did you guys manage to reproduce this? I've tried, tried, and >> > tried again. What's more, when I look at my log file, I see this: >> > >> > L 31408 2011-09-12 15:12:23 [DBG] knocking out flat tag 'carol' from >> > file '/home/lucas/Pictures/Photos/2011/08/27/red.jpg' because it's >> > already known as a hierarchical tag component >> > >> > which indicates to me that the tag knockout code is doing what it's >> > supposed to. The role of the tag knockout code is to remove flat tags >> > that are merely duplicates of hierarchical tag components so as to >> > prevent child tags from re-appearing as top-level tags during f-spot >> > import -- i.e., the knockout code should've closed #4081. When you run >> > Shotwell with logging turned on, do you see similar messages? >> >> >> I ran shotwell with logging on, and importing those same photos I got >> the exact same result as you, and a correct tag tree (no duplicates). >> So initially I was as puzzled as you, because nothing changed in my >> configuration, then I remembered the computer rule #1: 'the problem is >> between the keyboard and the chair'. >> >> My guess is you have to delete the 'LastKeywordXMP' and 'TagsList' >> fields added by shotwell to the test photos: my photos were 'after >> import' so they included hierarchical tags information added by >> shotwell. >> >> I did 'exiftool -all:all= *jpg' on those files, then imported in >> f-spot and tagged, then imported from s-spot to shotwell and I got the >> same results as the other day (i.e. duplicate tags). >> >> The relevant screenshot is: >> >> http://traversin.org/shotwell-test/AfterImportScreenshot2.png >> >> (This time I didn't put the top-level tags 'blue, red, green', just >> the friends' names.) >> >> The worst part is that my shotwell.log *does* say it is knocking out >> the flat tags, but eventually the tags are duplicated as top-level >> tags. >> >> The log file is: >> >> http://traversin.org/shotwell-test/shotwell.log >> >> The photos in the directory are 'after import', if you want to use >> them for a test remember to strip the tags added by shotwell, or, even >> better, all tags. >> >> Ciao, >> Piergi >> -- >> Web: http://traversin.org >> GNU/Linux user 190604 >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From list at heinrich-muenz.de Tue Sep 13 08:06:52 2011 From: list at heinrich-muenz.de (Heiner) Date: Tue, 13 Sep 2011 10:06:52 +0200 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> Message-ID: <1315901212.2358.1.camel@ubuntu> Am Montag, den 12.09.2011, 11:08 -0700 schrieb Eric Gregory: > > You can force a thumbnail to refresh by performing an edit within > Shotwell, then undoing the edit. This certainly is not a > "recommended" way, but it's a viable workaround if you've encountered > a bug where thumbnails aren't refreshing. Hey, that's quite tricky - but it works well! Thanks Heinrich From pt at traversin.org Tue Sep 13 08:19:16 2011 From: pt at traversin.org (pt) Date: Tue, 13 Sep 2011 10:19:16 +0200 Subject: [Shotwell] Two issues while trying to import from f-spot In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <726035851.8028605.1315566168834.JavaMail.tomcat55@mrmseu1.kundenserver.de> <4E6A83E5.5050602@gmail.com> <4E6B3859.20808@gmail.com> <4E6C4E7B.2080708@yorba.org> Message-ID: On 13 September 2011 02:46, Lucas Beeler wrote: > pt, Jim, and Adam, > > Thanks for all your hard sleuthing! I got what I needed and this bug > is now fixed in master! Hooray! :-) p. -- Web: http://traversin.org GNU/Linux user 190604 From list at heinrich-muenz.de Tue Sep 13 08:19:35 2011 From: list at heinrich-muenz.de (Heiner) Date: Tue, 13 Sep 2011 10:19:35 +0200 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> Message-ID: <1315901975.2358.12.camel@ubuntu> Well, I do have turned on the "watch library" option and the image was inside my library path. But shotwell didn't notice the changes after the next start - although my library was scanned. There also is another strange thumbnail behaviour when I import paired RAW+JPEG photos from any directory: For most photos, shotwell creates the thumbnail using the JPEG file. But in some rare cases the thumbnail is made using the RAW file or rather the embedded JPEG, although there is a developed JPEG as well. If this happens once to a certain photo, it will be the same after deleting and reimporting it. Heinrich Am Montag, den 12.09.2011, 11:37 -0700 schrieb Jim Nelson: > Just to chime in, if you launch an image editor from outside Shotwell > and edit a photo while Shotwell is running, the change will only be > noticed by Shotwell if you have library monitoring turned on (Edit -> > Preferences -> Watch library directory for new files) *and* the photo > file is somewhere in your library directory (i.e. the directory listed > right above this checkbox). Otherwise, Shotwell will only notice the > change the next time you start it. > > -- Jim > > On Mon, Sep 12, 2011 at 11:08 AM, Eric Gregory wrote: > On Sun, Sep 11, 2011 at 10:22 PM, Heiner > wrote: > > > Is there an easy way to refresh thumbnails (manually or > automatically) > > after editing photos outside shotwell? I've googled around > for this and > > found some older postings saying this should be possible > since 0.8, but > > I can't see it in 0.11.1. > > > > > When you say "outside of Shotwell" do you mean you're > launching an external > editor from within Shotwell, or you're launching the editor > outside of > Shotwell? > > The first way, the thumbnail should refresh as soon as you > close the > editor. The second way, it should eventually refresh, though > it may take > some time for Shotwell to recognize a change has been made to > the file. > > You can force a thumbnail to refresh by performing an edit > within Shotwell, > then undoing the edit. This certainly is not a "recommended" > way, but it's > a viable workaround if you've encountered a bug where > thumbnails aren't > refreshing. > > - Eric > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From list at heinrich-muenz.de Tue Sep 13 11:55:05 2011 From: list at heinrich-muenz.de (Heiner) Date: Tue, 13 Sep 2011 13:55:05 +0200 Subject: [Shotwell] Always unsorted photos Message-ID: <4E6F4499.4060700@heinrich-muenz.de> Hi, my library is sorted descending by shot date. That's how it is by default when showing the entire library. But when I select any special event or tag in the sidebar, the respective photos are displayed completely unsorted. I always have to sort them manually by menu. That's quite annoying... Heinrich From ian at mnementh.co.uk Tue Sep 13 12:28:35 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Tue, 13 Sep 2011 13:28:35 +0100 Subject: [Shotwell] Always unsorted photos In-Reply-To: <4E6F4499.4060700@heinrich-muenz.de> References: <4E6F4499.4060700@heinrich-muenz.de> Message-ID: <1315916915.8345.57.camel@wirenth> On Tue, 2011-09-13 at 13:55 +0200, Heiner wrote: > Hi, > > my library is sorted descending by shot date. That's how it is by > default when showing the entire library. But when I select any special > event or tag in the sidebar, the respective photos are displayed > completely unsorted. I always have to sort them manually by menu. That's > quite annoying... Ah yes... I meant to mention this - both my mother and partner noticed this, as did I... It is rather annoying :) -Ian From xavierviader at gmail.com Tue Sep 13 17:01:43 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Tue, 13 Sep 2011 19:01:43 +0200 Subject: [Shotwell] Lucid and shotwell 0.11.1 - question Message-ID: Hi all, thanks to Martin Wimpress I'm enjoying Shotwell 0.11.1 to my Lucid x64. There's just one issue that I don't know ho to sort out...the preferences are never saved. I know it's been commented but I'd like to know: How are stored preferences in shotwell? Is there any text file (plain text) that I could edit by hand and change preferences forever? Thanks Xavi From acummings at gmx.com Tue Sep 13 17:45:57 2011 From: acummings at gmx.com (Alan Cummings) Date: Tue, 13 Sep 2011 13:45:57 -0400 Subject: [Shotwell] Lucid and shotwell 0.11.1 - question In-Reply-To: References: Message-ID: <20110913134557.613c894f@gmx.com> Xavi Viader wrote: > thanks to Martin Wimpress I'm enjoying Shotwell 0.11.1 to my Lucid x64. > There's just one issue that I don't know ho to sort out...the preferences > are never saved. I know it's been commented but I'd like to know: > How are stored preferences in shotwell? > Is there any text file (plain text) that I could edit by hand and change > preferences forever? I think that also part of the problem includes Shotwell not only not saving the preferences but also that its not reading the preferences. I noticed this when I upgraded to 0.11.0 and saw that Shotwell wasn't loading the preferences saved from my previous version. -- Alan. From eric at yorba.org Tue Sep 13 18:31:09 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 13 Sep 2011 11:31:09 -0700 Subject: [Shotwell] Lucid and shotwell 0.11.1 - question In-Reply-To: References: Message-ID: On Tue, Sep 13, 2011 at 10:01 AM, Xavi Viader wrote: > Hi all, > > thanks to Martin Wimpress I'm enjoying Shotwell 0.11.1 to my Lucid x64. > There's just one issue that I don't know ho to sort out...the preferences > are never saved. I know it's been commented but I'd like to know: > How are stored preferences in shotwell? > Is there any text file (plain text) that I could edit by hand and change > preferences forever? > > Thanks > > Xavi > Hi Xavi, Shotwell 0.11 uses GSettings to store its preferences. There's several different storage backends for GSettings, so it depends what you have installed. It's likely that in your case GSettings is using the "memory" backend, which means nothing is ever written to disk. This would explain why it's not remembering anything between sessions. - Eric From eric at yorba.org Tue Sep 13 18:46:24 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 13 Sep 2011 11:46:24 -0700 Subject: [Shotwell] Always unsorted photos In-Reply-To: <1315916915.8345.57.camel@wirenth> References: <4E6F4499.4060700@heinrich-muenz.de> <1315916915.8345.57.camel@wirenth> Message-ID: On Tue, Sep 13, 2011 at 5:28 AM, Ian Molton wrote: > On Tue, 2011-09-13 at 13:55 +0200, Heiner wrote: > > Hi, > > > > my library is sorted descending by shot date. That's how it is by > > default when showing the entire library. But when I select any special > > event or tag in the sidebar, the respective photos are displayed > > completely unsorted. I always have to sort them manually by menu. That's > > quite annoying... > > Ah yes... I meant to mention this - both my mother and partner noticed > this, as did I... > > It is rather annoying :) Good news! This one was already known about and fixed. It's slated for release in 0.11.2 Bug report is here: http://redmine.yorba.org/issues/4030 - Eric From lucas at yorba.org Tue Sep 13 19:58:35 2011 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 13 Sep 2011 12:58:35 -0700 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: <1315901975.2358.12.camel@ubuntu> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> <1315901975.2358.12.camel@ubuntu> Message-ID: Hi Heiner, Just to chime in here: whether the thumbnail is made from the RAW file directly or from an embedded or paired JPEG depends on which RAW developer is currently selected in Shotwell's preferences. If the default developer is set to "Shotwell," then Shotwell will develop the thumbnail and preview images itself, directly from the RAW file. If the default developer is set to "Camera," Shotwell will use either a paired or embedded JPEG (presumably produced by the camera at the time of exposure) to generate the thumbnail and preview images, provided one is available. Lucas On Tue, Sep 13, 2011 at 1:19 AM, Heiner wrote: > Well, I do have turned on the "watch library" option and the image was > inside my library path. But shotwell didn't notice the changes after the > next start - although my library was scanned. > > There also is another strange thumbnail behaviour when I import paired > RAW+JPEG photos from any directory: For most photos, shotwell creates > the thumbnail using the JPEG file. But in some rare cases the thumbnail > is made using the RAW file or rather the embedded JPEG, although there > is a developed JPEG as well. If this happens once to a certain photo, it > will be the same after deleting and reimporting it. > > Heinrich > > Am Montag, den 12.09.2011, 11:37 -0700 schrieb Jim Nelson: >> Just to chime in, if you launch an image editor from outside Shotwell >> and edit a photo while Shotwell is running, the change will only be >> noticed by Shotwell if you have library monitoring turned on (Edit -> >> Preferences -> Watch library directory for new files) *and* the photo >> file is somewhere in your library directory (i.e. the directory listed >> right above this checkbox). ?Otherwise, Shotwell will only notice the >> change the next time you start it. >> >> -- Jim >> >> On Mon, Sep 12, 2011 at 11:08 AM, Eric Gregory wrote: >> ? ? ? ? On Sun, Sep 11, 2011 at 10:22 PM, Heiner >> ? ? ? ? wrote: >> >> ? ? ? ? > Is there an easy way to refresh thumbnails (manually or >> ? ? ? ? automatically) >> ? ? ? ? > after editing photos outside shotwell? I've googled around >> ? ? ? ? for this and >> ? ? ? ? > found some older postings saying this should be possible >> ? ? ? ? since 0.8, but >> ? ? ? ? > I can't see it in 0.11.1. >> ? ? ? ? > >> >> >> ? ? ? ? When you say "outside of Shotwell" do you mean you're >> ? ? ? ? launching an external >> ? ? ? ? editor from within Shotwell, or you're launching the editor >> ? ? ? ? outside of >> ? ? ? ? Shotwell? >> >> ? ? ? ? The first way, the thumbnail should refresh as soon as you >> ? ? ? ? close the >> ? ? ? ? editor. ?The second way, it should eventually refresh, though >> ? ? ? ? it may take >> ? ? ? ? some time for Shotwell to recognize a change has been made to >> ? ? ? ? the file. >> >> ? ? ? ? You can force a thumbnail to refresh by performing an edit >> ? ? ? ? within Shotwell, >> ? ? ? ? then undoing the edit. ?This certainly is not a "recommended" >> ? ? ? ? way, but it's >> ? ? ? ? a viable workaround if you've encountered a bug where >> ? ? ? ? thumbnails aren't >> ? ? ? ? refreshing. >> >> ? ? ? ? ?- Eric >> >> ? ? ? ? _______________________________________________ >> ? ? ? ? Shotwell mailing list >> ? ? ? ? Shotwell at lists.yorba.org >> ? ? ? ? http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Tue Sep 13 21:13:54 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 13 Sep 2011 14:13:54 -0700 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: <1315901975.2358.12.camel@ubuntu> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> <1315901975.2358.12.camel@ubuntu> Message-ID: On Tue, Sep 13, 2011 at 1:19 AM, Heiner wrote: > Well, I do have turned on the "watch library" option and the image was > inside my library path. But shotwell didn't notice the changes after the > next start - although my library was scanned. > > Is the file in your library directory (typically ~/Pictures)? -- Jim From ian at mnementh.co.uk Wed Sep 14 03:06:41 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Wed, 14 Sep 2011 04:06:41 +0100 Subject: [Shotwell] Feature idea Message-ID: <1315969601.8345.69.camel@wirenth> Hey, I shoot a lot of pano and HDR shots. I'd love to be able to tell Shotwell that x source photos belong to y 'processed' photos (I'd like to be able to have shotwell show several exposure configurations or projections for the input files). To be clear, I dont want shotwell (for now) to handle generating the pano/hdr shots - merely to have it collate the source images and present a choice of views of the finished image - let hugin or whatever do the hard work. I want this because otherwise, my holiday shots totalling about 150 images, actually looks like 2000 images, right now. The way I see this working is that during import, I group select the pano components, and right click and choose "set as panorama source". After import, all these images do NOT show individually. Shotwell will pick one image (temporarily) from the group to display as output (so something is visible in the view after import). Later, I can right click the 'image group' and click "render images" and have shotwell launch (for example) hugin, and pass it the images. I create a panorama or HDR image in hugin and hit render/stitch/save. Hugin does its thing, then saves the image and quits. Shotwell updates the view image to the new panorama. Right now, I have to tag all the source images as (say) pano-0001, then manually find them in the filesystem and load them into hugin, process, save, import into the library, and re-tag. Not only is that a pain, but also means in library view I have to scroll through thousands of pano components. Thoughts? -Ian From list at heinrich-muenz.de Wed Sep 14 05:17:51 2011 From: list at heinrich-muenz.de (Heiner) Date: Wed, 14 Sep 2011 07:17:51 +0200 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> <1315901975.2358.12.camel@ubuntu> Message-ID: <4E7038FF.4010406@heinrich-muenz.de> Am 13.09.2011 21:58, schrieb Lucas Beeler: Hi Lucas, the default developer is and was always set to "Camera", and most of the time shotwell's behaviour is as expected. It's just very few photos, where it's different. These photos are paired RAW+JPEG files just like the others, and they are part of an import with other paired RAW+JPEG files which are not affected by this issue. @Jim: Yes, the files are in my library directory. Heinrich > Hi Heiner, > > Just to chime in here: whether the thumbnail is made from the RAW file > directly or from an embedded or paired JPEG depends on which RAW > developer is currently selected in Shotwell's preferences. If the > default developer is set to "Shotwell," then Shotwell will develop the > thumbnail and preview images itself, directly from the RAW file. If > the default developer is set to "Camera," Shotwell will use either a > paired or embedded JPEG (presumably produced by the camera at the time > of exposure) to generate the thumbnail and preview images, provided > one is available. > > Lucas > > From dougie at highmoor.co.uk Wed Sep 14 09:36:24 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 10:36:24 +0100 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) Message-ID: <4E707598.6040505@highmoor.co.uk> I've just, after a bit of a struggle, managed to get Shotwell 0.11.1 running on Linux Mint LXDE. I've been using f-spot for the last few years but things are pretty quiet on that scene at the moment and the introduction of hierarchical tags into shotwell made me decide to give it another try. I'm a bit exasperated because I wanted to parallel run f-spot and shotwell before deciding on whether to switch. My f-spot photos are in /jpegs, and I created a new directory /images for shotwell. In preferences I changed the destination to /images (currently empty) and then for some reason shotwell spent a few minutes 'refreshing library'. shotwell didn't seem to want to remember my setting (changing it back to 'File System') so exited and restarted a couple of times and eventually the setting persisted. I selected import and chose my default f-spot database. The import appeared to be going well but I noticed that nothing was appearing in /images. When I checked shotwell progress I noticed it was periodically writing metadata to the file (a setting I'd enabled), but it was writing the information to the files in their original location (/jpegs). I aborted the import. I know that I can import directly from a folder location but I notice that if I do this it doesn't retain the hierarchical tag structure that I want. One thing I always do with f-spot is run it in debug mode so that I can see what's going on in a terminal window, and there doesn't appear to be a verbose or debug option in shotwell. So, in a nutshell. I want to import my f-spot database and copy them to a new location (although it is a bit academic now as shotwell has overwritten the metadata for a lot of the originals :( ). Is this likely to be a bug or NewUser Error? Dougie From dougie at highmoor.co.uk Wed Sep 14 09:59:33 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 10:59:33 +0100 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) In-Reply-To: <4E707598.6040505@highmoor.co.uk> References: <4E707598.6040505@highmoor.co.uk> Message-ID: <4E707B05.9090806@highmoor.co.uk> On 14/09/2011 10:36, Dougie Nisbet wrote: > When I checked shotwell progress I noticed it was periodically > writing metadata to the file (a setting I'd enabled), but it was > writing the information to the files in their original location > (/jpegs). I aborted the import. After a little experimentation I notice that if Import from Folder is selected, a window pops up asking whether the images should be imported place or copied to a new destination. This window pop-up does not appear when importing from f-spot database. Dougie From dougie at highmoor.co.uk Wed Sep 14 10:27:11 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 11:27:11 +0100 Subject: [Shotwell] Resetting and Starting Again Message-ID: <4E70817F.6030707@highmoor.co.uk> Since I'm still experimenting I've been making a fresh start when things go wrong. To do this I've quite shotwell, then deleted all references to shotwell in my home directory (~/.gconf/apps ; .cache ; and .shotwell). I've also notice that when I quit shotwell it leaves a zombie process behind that's not cleanly killable, so I reboot too. However, when I rerun shotwell it doesn't run it as a new install (no initial import dialogue for instance and it's remembered my preferences), so I'm assuming there's some more information stored somewhere. When it all gets messy, what's the best way of starting over cleanly? Thanks, Dougie From dougie at highmoor.co.uk Wed Sep 14 10:53:22 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 11:53:22 +0100 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) [ LOG FILE ] In-Reply-To: <4E707598.6040505@highmoor.co.uk> References: <4E707598.6040505@highmoor.co.uk> Message-ID: <4E7087A2.2040006@highmoor.co.uk> On 14/09/2011 10:36, Dougie Nisbet wrote: > One thing I always do with f-spot is run it in debug mode so that I > can see what's going on in a terminal window, and there doesn't appear > to be a verbose or debug option in shotwell. Partly answering my own question, I've found a log file in .cache, so running 'tail -f .cache/shotwell/shotwell.log' quite useful to see the discrepancies in my f-spot database as they are processed by the shotwell importer. From martin+shotwell at flexion.org Wed Sep 14 10:58:36 2011 From: martin+shotwell at flexion.org (Martin Wimpress) Date: Wed, 14 Sep 2011 11:58:36 +0100 Subject: [Shotwell] GConf errors in 11.1 In-Reply-To: <1315846602.2257.20.camel@turmikubuntu.zf.if.atcsg.net> References: <87hb4k8b7b.fsf@terrapin.northbound-train.com> <1315839291.3133.9.camel@turmikubuntu.zf.if.atcsg.net> <4E6E20C3.2080809@gmail.com> <1315846602.2257.20.camel@turmikubuntu.zf.if.atcsg.net> Message-ID: <5fd3b9425ca6f8e3c9acfd1a9cbbfa90@flexion.org> Hi, I am going to try and backport d-conf and it's dependencies in order to resolve the issue where Shotwell 0.11 doesn't save preferences on Lucid. No promises though, it looks like a big job. I'll report back on the viability in a couple of days. Regards, Martin. On Mon, 12 Sep 2011 18:56:42 +0200, Mikael Turesson wrote: > Hi Joe, > > I saw this the first time you posted it but these libs aren't > availible > for 10.04 lucid(yes I've tried it). Martin has done a good job > backport > shotwell to the 10.04 LTS ubuntu but I recon it will be harder for > him > when the yorba team use more of the newer options/libs in later > versions > of Ubuntu that he has to take into consideration when making up the > backported versions. I have no problems with the statement from the > yorba team about not supporting older versions of Ubuntu(even thou I > think it's a pity) so I'm pleased with the fact that one guy(Martin) > is > doin all this effort for us that think you don't have to have the > latest > version all the time. > > But thank you for the tip Joe I'll remember it when I upgrade. > > Best Regards > Mike > > m?n 2011-09-12 klockan 11:09 -0400 skrev Joseph Bylund: >> To fix the >> >> "GLib-GIO-Message: Using the 'memory' GSettings backend. Your >> settings >> will not be saved or shared with other applications." >> >> error on natty. Try installing the dconf libraries. >> >> sudo aptitude install dconf-tools libdconf0 libdconf-dbus-1-0 >> >> For me this silenced the error, and allowed me to save settings. >> >> -Joe >> >> >> On 09/12/2011 10:54 AM, Mikael Turesson wrote: >> > Hello Martin ! >> > >> > I have the same problem running on X86-64 Lucid. I have the >> GStreamer >> > devel ppa enabled. You can run shotwell and import photos but you >> cannot >> > save any property changes in the application. >> > >> > Thanx for your work Martin I really prefer shotwell before F-Spot >> so if >> > it isn't a quickfix I'll mangage with the situation as is !! >> > >> > Regards >> > Mike >> > >> > m?n 2011-09-12 klockan 13:45 +0100 skrev Martin Wimpress: >> >> Hi, >> >> >> >> Have you enabled the GStreamer Developers PPA? >> >> >> >> * ppa:gstreamer-developers/ppa >> >> >> >> For Shotwell 0.11 onward this is now a requirement for Lucid >> and >> >> Maverick. >> >> >> >> Regards, Martin. >> >> >> >> On Sat, 10 Sep 2011 15:11:04 -0400, Joe Casadonte wrote: >> >>> Hi, >> >>> >> >>> I just upgraded from 0.10.1 to 0.11.1, running on Ubuntu 10.04 >> (using >> >>> package from >> https://launchpad.net/~flexiondotorg/+archive/shotwell). >> >>> >> >>> I'm receiving the following errors on startup: >> >>> >> >>> ** Message: GConfEngine.vala:188: Error loading or parsing >> gsettings >> >>> convert keyfile: Valid key file could not be found in search >> dirs >> >>> ** (process:12177): DEBUG: GConfEngine.vala:191: Converting >> GConf >> >>> settings to gsettings... >> >>> ** Message: GConfEngine.vala:207: Error running >> >>> gsettings-data-convert: Failed to execute child process >> >>> "gsettings-data-convert" (No such file or directory) >> >>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your >> >>> settings will not be saved or shared with other applications. >> >>> >> >>> Also, every time I start up I get the "Updating library..." >> message >> >>> for >> >>> about 30 seconds. >> >>> >> >>> The package was installed with root privileges, so the directory >> >>> /usr/share/GConf/gsetting exists (as does the file >> >>> /usr/share/GConf/gsetting/shotwell.convert). >> >>> >> >>> Anything I need to be worried about? Thanks for a great piece >> of >> >>> software! >> > >> > _______________________________________________ >> > 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 -- Regards, Martin. From hernan.lopez+ubuntu at gmail.com Wed Sep 14 11:32:53 2011 From: hernan.lopez+ubuntu at gmail.com (Hernan Javier Lopez) Date: Wed, 14 Sep 2011 08:32:53 -0300 Subject: [Shotwell] Feature idea In-Reply-To: <1315969601.8345.69.camel@wirenth> References: <1315969601.8345.69.camel@wirenth> Message-ID: On Wed, Sep 14, 2011 at 00:06, Ian Molton wrote: > Hey, > > I shoot a lot of pano and HDR shots. > > I'd love to be able to tell Shotwell that x source photos belong to y > 'processed' photos (I'd like to be able to have shotwell show several > exposure configurations or projections for the input files). > > To be clear, I dont want shotwell (for now) to handle generating the > pano/hdr shots - merely to have it collate the source images and present > a choice of views of the finished image - let hugin or whatever do the > hard work. > > I want this because otherwise, my holiday shots totalling about 150 > images, actually looks like 2000 images, right now. > > The way I see this working is that during import, I group select the > pano components, and right click and choose "set as panorama source". > > After import, all these images do NOT show individually. > > Shotwell will pick one image (temporarily) from the group to display as > output (so something is visible in the view after import). > > Later, I can right click the 'image group' and click "render images" and > have shotwell launch (for example) hugin, and pass it the images. > > I create a panorama or HDR image in hugin and hit render/stitch/save. > > Hugin does its thing, then saves the image and quits. > > Shotwell updates the view image to the new panorama. > > Right now, I have to tag all the source images as (say) pano-0001, then > manually find them in the filesystem and load them into hugin, process, > save, import into the library, and re-tag. > > Not only is that a pain, but also means in library view I have to scroll > through thousands of pano components. > > Thoughts? > > -Ian +1 From ivoroghair at gmail.com Wed Sep 14 12:10:13 2011 From: ivoroghair at gmail.com (Ivo Roghair) Date: Wed, 14 Sep 2011 14:10:13 +0200 Subject: [Shotwell] Feature idea In-Reply-To: <1315969601.8345.69.camel@wirenth> References: <1315969601.8345.69.camel@wirenth> Message-ID: +1 for me too. Right now, I do this with tags to keep track of them, but I like the idea of keeping things explicitly together. It would be nice if this can be combined with different versions of the image (e.g. different RAW exports, externally modified versions, other HDR renders of the same base images), with an image of your choice as 'key image' to show in the viewer (this can be useful for exporting a bunch of pictures, among which a set, so the key image is the only one exported) I don't do panorama's or HDRs for each image, so I would probably not use an import feature. Rather, I'd select the images when imported and push on some 'create set' button. 2011/9/14 Ian Molton : > Hey, > > I shoot a lot of pano and HDR shots. > > I'd love to be able to tell Shotwell that x source photos belong to y > 'processed' photos (I'd like to be able to have shotwell show several > exposure configurations or projections for the input files). > > To be clear, I dont want shotwell (for now) to handle generating the > pano/hdr shots - merely to have it collate the source images and present > a choice of views of the finished image - let hugin or whatever do the > hard work. > > I want this because otherwise, my holiday shots totalling about 150 > images, actually looks like 2000 images, right now. > > The way I see this working is that during import, I group select the > pano components, and right click and choose "set as panorama source". > > After import, all these images do NOT show individually. > > Shotwell will pick one image (temporarily) from the group to display as > output (so something is visible in the view after import). > > Later, I can right click the 'image group' and click "render images" and > have shotwell launch (for example) hugin, and pass it the images. > > I create a panorama or HDR image in hugin and hit render/stitch/save. > > Hugin does its thing, then saves the image and quits. > > Shotwell updates the view image to the new panorama. > > Right now, I have to tag all the source images as (say) pano-0001, then > manually find them in the filesystem and load them into hugin, process, > save, import into the library, and re-tag. > > Not only is that a pain, but also means in library view I have to scroll > through thousands of pano components. > > Thoughts? > > -Ian > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From martin+shotwell at flexion.org Wed Sep 14 12:33:47 2011 From: martin+shotwell at flexion.org (Martin Wimpress) Date: Wed, 14 Sep 2011 13:33:47 +0100 Subject: [Shotwell] Lucid and shotwell 0.11.1 - question In-Reply-To: References: Message-ID: <8ca474f4665ec0d63e5d1f4ca96343ce@flexion.org> Hi, I am attempting to backport d-conf to Lucid and Maverick which will address the problem of Shotwell 0.11 not saving preferences. I'll report back on how things are going to this list in a couple of days. Regards, Martin. On Tue, 13 Sep 2011 11:31:09 -0700, Eric Gregory wrote: > On Tue, Sep 13, 2011 at 10:01 AM, Xavi Viader > wrote: > >> Hi all, >> >> thanks to Martin Wimpress I'm enjoying Shotwell 0.11.1 to my Lucid >> x64. >> There's just one issue that I don't know ho to sort out...the >> preferences >> are never saved. I know it's been commented but I'd like to know: >> How are stored preferences in shotwell? >> Is there any text file (plain text) that I could edit by hand and >> change >> preferences forever? >> >> Thanks >> >> Xavi >> > > Hi Xavi, > > Shotwell 0.11 uses GSettings to store its preferences. There's > several > different storage backends for GSettings, so it depends what you have > installed. > > It's likely that in your case GSettings is using the "memory" > backend, which > means nothing is ever written to disk. This would explain why it's > not > remembering anything between sessions. > > - Eric > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -- Regards, Martin. From ian at mnementh.co.uk Wed Sep 14 13:22:01 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Wed, 14 Sep 2011 14:22:01 +0100 Subject: [Shotwell] Feature idea In-Reply-To: References: <1315969601.8345.69.camel@wirenth> Message-ID: <1316006521.8345.81.camel@wirenth> On Wed, 2011-09-14 at 14:10 +0200, Ivo Roghair wrote: > > Right now, I do this with tags to keep track of them, but I like the > idea of keeping things explicitly together. :) > It would be nice if this > can be combined with different versions of the image (e.g. different > RAW exports, Thats what I said :) > externally modified versions, other HDR renders of the > same base images), Could be handy. > with an image of your choice as 'key image' to show > in the viewer (this can be useful for exporting a bunch of pictures, > among which a set, so the key image is the only one exported) Thats what I said :) > I don't do panorama's or HDRs for each image, dont know what you mean here. > so I would probably not > use an import feature. Rather, I'd select the images when imported and > push on some 'create set' button. This seems like a good idea for how to phase in implementation. 1) Add a 'group images' option for use with selections, allowing you to select the key image (default, first in set). This should be available during import and in the library. 2) Add a facility to perform operations on grouped images, eg. lighten, darken, etc. - all the existing processing, but as a 'batch mode' 3) Add a 'process with external program' option as a way to allow use of hugin / other software to combine images. This process with you being able to replace the key image with your new processed image. When shotwell supports multiple views of an image (as opposed to the 'you can only have one eduited version' method we have right now), this could be extended to allow multiple processed images to be selected between. -Ian From ivoroghair at gmail.com Wed Sep 14 15:23:55 2011 From: ivoroghair at gmail.com (Ivo Roghair) Date: Wed, 14 Sep 2011 17:23:55 +0200 Subject: [Shotwell] Feature idea In-Reply-To: <1316006521.8345.81.camel@wirenth> References: <1315969601.8345.69.camel@wirenth> <1316006521.8345.81.camel@wirenth> Message-ID: <4E70C70B.20006@gmail.com> >> I don't do panorama's or HDRs for each image, > > dont know what you mean here. I just meant to say that I don't make a HDR or panorama all the time. Usually, I just take single pictures, so I won't mind grouping them by hand. :) From stesind at googlemail.com Wed Sep 14 15:26:50 2011 From: stesind at googlemail.com (Steffen) Date: Wed, 14 Sep 2011 17:26:50 +0200 Subject: [Shotwell] feature proposal is: "multiple selection of tags" In-Reply-To: <1315969601.8345.69.camel@wirenth> References: <1315969601.8345.69.camel@wirenth> Message-ID: <1316014010.6632.8.camel@steffen-MS-7588> Hi, The way to achieve this in a most convenient and flexible way is to use tags. Normally all pictures like from holiday are imported and then tagged/rated. Some will be deleted others like with more than 3 stars are shown to family and friends. Tag some of the pictures as "pano source". Some day when shotwell supports multiple selection of tags you will be able to select the tags "vacation x" and "pano source". Right mouse click and send to folder. So my feature proposal is: "multiple selection of tags" Cheers, Am Mittwoch, den 14.09.2011, 04:06 +0100 schrieb Ian Molton: > Hey, > > I shoot a lot of pano and HDR shots. > > I'd love to be able to tell Shotwell that x source photos belong to y > 'processed' photos (I'd like to be able to have shotwell show several > exposure configurations or projections for the input files). > > To be clear, I dont want shotwell (for now) to handle generating the > pano/hdr shots - merely to have it collate the source images and present > a choice of views of the finished image - let hugin or whatever do the > hard work. > > I want this because otherwise, my holiday shots totalling about 150 > images, actually looks like 2000 images, right now. > > The way I see this working is that during import, I group select the > pano components, and right click and choose "set as panorama source". > > After import, all these images do NOT show individually. > > Shotwell will pick one image (temporarily) from the group to display as > output (so something is visible in the view after import). > > Later, I can right click the 'image group' and click "render images" and > have shotwell launch (for example) hugin, and pass it the images. > > I create a panorama or HDR image in hugin and hit render/stitch/save. > > Hugin does its thing, then saves the image and quits. > > Shotwell updates the view image to the new panorama. > > Right now, I have to tag all the source images as (say) pano-0001, then > manually find them in the filesystem and load them into hugin, process, > save, import into the library, and re-tag. > > Not only is that a pain, but also means in library view I have to scroll > through thousands of pano components. > > Thoughts? > > -Ian > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From ian at mnementh.co.uk Wed Sep 14 15:48:35 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Wed, 14 Sep 2011 16:48:35 +0100 Subject: [Shotwell] feature proposal is: "multiple selection of tags" In-Reply-To: <1316014010.6632.8.camel@steffen-MS-7588> References: <1315969601.8345.69.camel@wirenth> <1316014010.6632.8.camel@steffen-MS-7588> Message-ID: <1316015315.8345.85.camel@wirenth> On Wed, 2011-09-14 at 17:26 +0200, Steffen wrote: > Hi, > > The way to achieve this in a most convenient and flexible way is to use > tags. No. because I dont want them to show up in the tag namespace, and I now have about 90 tags of the form pano-00xx. for now I've 'hidden' them in a 'pano sources' tag hierarchy, but its clumsy and ugly. When I select pano-0017, I want the photos for only image 17 - not every other pano source I have ever taken. I also dont want to have to get future shotwll to show me 'everything EXCEPT 'pano sources', just to look at my library without clutter. Multiple tag selection would be nice /as well/ however - this is already planned though, amiright? :) Tags are NOT the answer to everything. -Ian From stesind at googlemail.com Wed Sep 14 17:33:38 2011 From: stesind at googlemail.com (Steffen) Date: Wed, 14 Sep 2011 19:33:38 +0200 Subject: [Shotwell] feature proposal is: "multiple selection of tags" In-Reply-To: <1316015315.8345.85.camel@wirenth> References: <1315969601.8345.69.camel@wirenth> <1316014010.6632.8.camel@steffen-MS-7588> <1316015315.8345.85.camel@wirenth> Message-ID: <1316021618.6632.21.camel@steffen-MS-7588> Hi, Sure tags is the answer. You run into problems because you mix different information in one tag. Use the tag "pano" and then other tags like for event, place, ... If you click pano and the event together you will only see the few pictures. This is clear and also compatible with other programs. Unfortunately in shotwell one is not able to select more that one tag in the left tree view. Steffen Am Mittwoch, den 14.09.2011, 16:48 +0100 schrieb Ian Molton: > On Wed, 2011-09-14 at 17:26 +0200, Steffen wrote: > > Hi, > > > > The way to achieve this in a most convenient and flexible way is to use > > tags. > > No. because I dont want them to show up in the tag namespace, and I now > have about 90 tags of the form pano-00xx. for now I've 'hidden' them in > a 'pano sources' tag hierarchy, but its clumsy and ugly. > > When I select pano-0017, I want the photos for only image 17 - not every > other pano source I have ever taken. > > I also dont want to have to get future shotwll to show me 'everything > EXCEPT 'pano sources', just to look at my library without clutter. > > Multiple tag selection would be nice /as well/ however - this is already > planned though, amiright? :) > > Tags are NOT the answer to everything. > > -Ian > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From ian at mnementh.co.uk Wed Sep 14 17:46:16 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Wed, 14 Sep 2011 18:46:16 +0100 Subject: [Shotwell] feature proposal is: "multiple selection of tags" In-Reply-To: <1316021618.6632.21.camel@steffen-MS-7588> References: <1315969601.8345.69.camel@wirenth> <1316014010.6632.8.camel@steffen-MS-7588> <1316015315.8345.85.camel@wirenth> <1316021618.6632.21.camel@steffen-MS-7588> Message-ID: <1316022376.8345.90.camel@wirenth> On Wed, 2011-09-14 at 19:33 +0200, Steffen wrote: > > Sure tags is the answer. You run into problems because you mix > different > information in one tag. Use the tag "pano" and then other tags like > for > event, place, ... No. I dont tag location that finely. I took *30* panoramas in Toronto. Thats about 500 shots. tagging them all as Pano, toronto isnt adequate, andI dont have time to look up the name of every street corner. > If you click pano and the event together you will only see the few > pictures. 500 is NOT a few. > This is clear and also compatible with other programs. Make it possible to export panorama sets as tagsets. done. -Ian From eric at yorba.org Wed Sep 14 18:21:50 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 14 Sep 2011 11:21:50 -0700 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: <4E70817F.6030707@highmoor.co.uk> References: <4E70817F.6030707@highmoor.co.uk> Message-ID: On Wed, Sep 14, 2011 at 3:27 AM, Dougie Nisbet wrote: > Since I'm still experimenting I've been making a fresh start when things go > wrong. To do this I've quite shotwell, then deleted all references to > shotwell in my home directory (~/.gconf/apps ; .cache ; and .shotwell). I've > also notice that when I quit shotwell it leaves a zombie process behind > that's not cleanly killable, so I reboot too. However, when I rerun shotwell > it doesn't run it as a new install (no initial import dialogue for instance > and it's remembered my preferences), so I'm assuming there's some more > information stored somewhere. > > When it all gets messy, what's the best way of starting over cleanly? > > Thanks, > > Dougie > Hi Dougie, What can you tell us about this zombie process that's left behind? I'd be curious to know the name of the process and what happens when you try to kill it. To answer your question, depending on the version of Shotwell, prefs used to be stored in GConf but if you're running Shotwell 0.11 or better they're stored in GSettings. Your best bet for these types of issues is to do a "complete remove" of the Shotwell package in your package manager and reinstall. - Eric From lucas at yorba.org Wed Sep 14 18:24:00 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Sep 2011 11:24:00 -0700 Subject: [Shotwell] Feature idea In-Reply-To: <4E70C70B.20006@gmail.com> References: <1315969601.8345.69.camel@wirenth> <1316006521.8345.81.camel@wirenth> <4E70C70B.20006@gmail.com> Message-ID: Composite images are only going to become more common, so I've opened a ticket here: http://redmine.yorba.org/issues/4116 On Wed, Sep 14, 2011 at 8:23 AM, Ivo Roghair wrote: > > >>> I don't do panorama's or HDRs for each image, >> >> dont know what you mean here. > > I just meant to say that I don't make a HDR or panorama all the time. > Usually, I just take single pictures, so I won't mind grouping them by hand. > :) > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Wed Sep 14 18:38:46 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 19:38:46 +0100 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: References: <4E70817F.6030707@highmoor.co.uk> Message-ID: <4E70F4B6.5050902@highmoor.co.uk> On 14/09/2011 19:21, Eric Gregory wrote: > > Hi Dougie, > > What can you tell us about this zombie process that's left behind? I'd > be curious to know the name of the process and what happens when you > try to kill it. > Hi Eric, The Zombie process is a bit strange. I've pasted some information below. As you might expect 'kill -9' has no effect, but if I kill its parent process things do not end well. I lose bits of the Menu bar on the bottom of the screen. dougie at phoenix ~ $ dougie at phoenix ~ $ ps -ef | grep shotwell dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] dougie 2023 1862 0 19:29 pts/0 00:00:00 grep --colour=auto shotwell dougie at phoenix ~ $ dougie at phoenix ~ $ ps -fp1939 UID PID PPID C STIME TTY TIME CMD dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] dougie at phoenix ~ $ dougie at phoenix ~ $ ps -fp1717 UID PID PPID C STIME TTY TIME CMD dougie 1717 1 0 19:14 ? 00:00:03 python /usr/lib/linuxmint/mintMenu/mintMenu.py dougie at phoenix ~ $ dougie at phoenix ~ $ ps -fp1717 | fold UID PID PPID C STIME TTY TIME CMD dougie 1717 1 0 19:14 ? 00:00:03 python /usr/lib/linuxmint/mintMe nu/mintMenu.py --oaf-activate-iid=OAFIID:GNOME_mintMenu_Factory --oaf-ior-fd=18 dougie at phoenix ~ $ > To answer your question, depending on the version of Shotwell, prefs > used to be stored in GConf but if you're running Shotwell 0.11 or > better they're stored in GSettings. Your best bet for these types of > issues is to do a "complete remove" of the Shotwell package in your > package manager and reinstall. > I tried (unsuccessfully) to use the package manager in Linux Mint 10 (Julia) and hit problems that I couldn't get beyond. valac and gstreamer deps IIRC. I tried using the repo on the shotwell website but it installed 0.10 and I'm really keen on the hierarchical tagging. I didn't pursue it because I've been meaning to move to Linux Mint for Debian for some time and I have wiped my PC and run LXDE. I compiled from the source tarball so I'm not sure how to purge before starting over. Anyway, I'm hoping not to have to do that again. Since shotwell overwrote my photos metadata during the import I might as well carry on! It's a lot different to f-spot and there are things I miss, but it's very fast, and I like that a lot! Dougie From lucas at yorba.org Wed Sep 14 18:39:19 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Sep 2011 11:39:19 -0700 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) In-Reply-To: <4E707B05.9090806@highmoor.co.uk> References: <4E707598.6040505@highmoor.co.uk> <4E707B05.9090806@highmoor.co.uk> Message-ID: Hi Dougie, > One thing I always do with f-spot is run it > in debug mode so that I can see what's > going on in a terminal window, and there > doesn't appear to be a verbose or debug > option in shotwell. To achieve this, turn logging on in Shotwell. This is as simple as setting the environment variable SHOTWELL_LOG=1 before invoking Shotwell. Your debug output will end up in ~/.cache/shotwell/shotwell.log. > I want to import my f-spot database > and copy them to a new location F-Spot import wasn't designed to work this way, particularly since F-Spot stores photos by default in the ~/Pictures directory, which Shotwell considers its library directory. So it's not as if the "copy to library" notion that applies to file import really applies to F-Spot import. The use case for F-Spot import was users who wanted to switch from using F-Spot to using Shotwell in one fell swoop. Specifically, the F-Spot import feature was added when Shotwell became the default photo manager in Ubuntu. Since F-Spot had previously been the default photo manager, we didn't want to leave former F-Spot users out in the cold. If you'd like, you could always backup your F-Spot photo directory (which is usually ~/Pictures/Photos) and your F-Spot data directory (which is usually ~/.config/f-spot), then use Shotwell for a while, and if you don't prefer Shotwell, simply restore your state from your backup and go back to running F-Spot. Just my two cents. Lucas From joseph.bylund at gmail.com Wed Sep 14 18:38:08 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Wed, 14 Sep 2011 14:38:08 -0400 Subject: [Shotwell] Feature idea In-Reply-To: References: <1315969601.8345.69.camel@wirenth> <1316006521.8345.81.camel@wirenth> <4E70C70B.20006@gmail.com> Message-ID: <4E70F490.5070106@gmail.com> Can anyone comment on how cameras that do the in-camera-panning-panorama thing do this? What do you actually get off the card? A jpg? How about having shotwell automatically tag images with an aspect ratio greater than a user specifiable parameter (which I suppose should default to just wider/taller than the aspect ratio commonly seen in consumer cameras). And while I'm thinking about it, is there a method to have shotwell (tag|show only) photos taken with a specific camera? For those of us without eidetic memory it might be easier to find a photo if you know, "well I know I was carrying my compact camera because I left the slr at home". Apologies if I'm distracting the thread. -Joe On 09/14/2011 02:24 PM, Lucas Beeler wrote: > Composite images are only going to become more common, so I've opened > a ticket here: http://redmine.yorba.org/issues/4116 > > On Wed, Sep 14, 2011 at 8:23 AM, Ivo Roghair wrote: >>>> I don't do panorama's or HDRs for each image, >>> dont know what you mean here. >> I just meant to say that I don't make a HDR or panorama all the time. >> Usually, I just take single pictures, so I won't mind grouping them by hand. >> :) >> _______________________________________________ >> 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 lucas at yorba.org Wed Sep 14 18:53:59 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Sep 2011 11:53:59 -0700 Subject: [Shotwell] Refresh Thumbnails In-Reply-To: <4E7038FF.4010406@heinrich-muenz.de> References: <1314779854.2291.8.camel@ubuntu> <4E5DF746.5040306@yorba.org> <4E5E1F3B.6080408@heinrich-muenz.de> <4E5F199F.6040807@heinrich-muenz.de> <4E6D9711.2010509@heinrich-muenz.de> <1315901975.2358.12.camel@ubuntu> <4E7038FF.4010406@heinrich-muenz.de> Message-ID: > There also is another strange > thumbnail behaviour when I import > paired RAW+JPEG photos from > any directory: For most photos, > shotwell creates the thumbnail using > the JPEG file. But in some rare > cases the thumbnail is made using > the RAW file or rather the embedded > JPEG Just to make sure: the RAW file and its paired JPEG have the same basename, minus the file extension (i.e., "DSCF001.CR2" and "DSCF001.JPG") right? And you're importing both files in the same import operation right? One other thing to try is to run Shotwell with logging turned on and to reproduce this behavior such that any debug output associated with the error is captured in the log file. You can do this by setting the environment variable SHOTWELL_LOG=1 before running Shotwell. This will create a diagnostic log file at ~/.cache/shotwell/shotwell.log. Lucas On Tue, Sep 13, 2011 at 10:17 PM, Heiner wrote: > Am 13.09.2011 21:58, schrieb Lucas Beeler: > > Hi Lucas, > > the default developer is and was always set to "Camera", and most of the > time shotwell's behaviour is as expected. It's just very few photos, > where it's different. These photos are paired RAW+JPEG files just like > the others, and they are part of an import with other paired RAW+JPEG > files which are not affected by this issue. > > @Jim: > Yes, the files are in my library directory. > > Heinrich > >> Hi Heiner, >> >> Just to chime in here: whether the thumbnail is made from the RAW file >> directly or from an embedded or paired JPEG depends on which RAW >> developer is currently selected in Shotwell's preferences. If the >> default developer is set to "Shotwell," then Shotwell will develop the >> thumbnail and preview images itself, directly from the RAW file. If >> the default developer is set to "Camera," Shotwell will use either a >> paired or embedded JPEG (presumably produced by the camera at the time >> of exposure) to generate the thumbnail and preview images, provided >> one is available. >> >> Lucas >> >> > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Wed Sep 14 18:56:31 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 19:56:31 +0100 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) In-Reply-To: References: <4E707598.6040505@highmoor.co.uk> <4E707B05.9090806@highmoor.co.uk> Message-ID: <4E70F8DF.2030503@highmoor.co.uk> On 14/09/2011 19:39, Lucas Beeler wrote: > > F-Spot import wasn't designed to work this way, particularly since > F-Spot stores photos by default in the ~/Pictures directory, which > Shotwell considers its library directory. So it's not as if the "copy > to library" notion that applies to file import really applies to > F-Spot import. The use case for F-Spot import was users who wanted to > switch from using F-Spot to using Shotwell in one fell swoop. It's a bit academic now but I wonder if I could have achieved it if I'd imported my f-spot database and unselected 'Write Metadata to files', then followed the guidelines in the shotwell FAQ for moving photos to a different location. Then once all ok copy the original f-spot photos back to their own location. Dougie From eric at yorba.org Wed Sep 14 19:02:02 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 14 Sep 2011 12:02:02 -0700 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: <4E70F4B6.5050902@highmoor.co.uk> References: <4E70817F.6030707@highmoor.co.uk> <4E70F4B6.5050902@highmoor.co.uk> Message-ID: On Wed, Sep 14, 2011 at 11:38 AM, Dougie Nisbet wrote: > The Zombie process is a bit strange. I've pasted some information below. > As you might expect 'kill -9' has no effect, but if I kill its parent > process things do not end well. I lose bits of the Menu bar on the bottom of > the screen. > > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -ef | grep shotwell > dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] > dougie 2023 1862 0 19:29 pts/0 00:00:00 grep --colour=auto shotwell > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1939 > UID PID PPID C STIME TTY TIME CMD > dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1717 > UID PID PPID C STIME TTY TIME CMD > dougie 1717 1 0 19:14 ? 00:00:03 python > /usr/lib/linuxmint/mintMenu/mintMenu.py > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1717 | fold > UID PID PPID C STIME TTY TIME CMD > dougie 1717 1 0 19:14 ? 00:00:03 python > /usr/lib/linuxmint/mintMe > nu/mintMenu.py --oaf-activate-iid=OAFIID:GNOME_mintMenu_Factory > --oaf-ior-fd=18 > dougie at phoenix ~ $ > > Does this happen if you run from the command line or just from the menu? I tried (unsuccessfully) to use the package manager in Linux Mint 10 > (Julia) and hit problems that I couldn't get beyond. valac and gstreamer > deps IIRC. I tried using the repo on the shotwell website but it installed > 0.10 and I'm really keen on the hierarchical tagging. I didn't pursue it > because I've been meaning to move to Linux Mint for Debian for some time and > I have wiped my PC and run LXDE. I compiled from the source tarball so I'm > not sure how to purge before starting over. > I've just been told the way to do this is to run make uninstall, then log out and log back in. The settings should be gone. > Anyway, I'm hoping not to have to do that again. Since shotwell overwrote > my photos metadata during the import I might as well carry on! It's a lot > different to f-spot and there are things I miss, but it's very fast, and I > like that a lot! > Glad to hear it! - Eric From lucas at yorba.org Wed Sep 14 19:02:05 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Sep 2011 12:02:05 -0700 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) In-Reply-To: <4E70F8DF.2030503@highmoor.co.uk> References: <4E707598.6040505@highmoor.co.uk> <4E707B05.9090806@highmoor.co.uk> <4E70F8DF.2030503@highmoor.co.uk> Message-ID: > It's a bit academic now but I wonder > if I could have achieved it if I'd imported > my f-spot database and unselected > 'Write Metadata to files', then followed > the guidelines in the shotwell FAQ for > moving photos to a different location. > Then once all ok copy the original f-spot > photos back to their own location. That might work! Lucas From dougie at highmoor.co.uk Wed Sep 14 19:06:47 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 20:06:47 +0100 Subject: [Shotwell] Duplicating on a second machine Message-ID: <4E70FB47.1010306@highmoor.co.uk> One thing I do with f-spot is duplicate my photos on my netbook. I use rsync to update the photos on my netbook and to copy the f-spot database over too. Then on the netbook I basically use f-spot as a read-only photo viewer to get the benefit of tag lookups. This becomes even more attractive with shotwell as it's so much faster than f-spot for retrieving photos by tags. Would it be feasible to synchronise my shotwell setup on a second machine and if so, what should I rsync over? Thanks, Dougie From dougie at highmoor.co.uk Wed Sep 14 19:11:01 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 14 Sep 2011 20:11:01 +0100 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: References: <4E70817F.6030707@highmoor.co.uk> <4E70F4B6.5050902@highmoor.co.uk> Message-ID: <4E70FC45.6030506@highmoor.co.uk> On 14/09/2011 20:02, Eric Gregory wrote: > On Wed, Sep 14, 2011 at 11:38 AM, Dougie Nisbet > wrote: > > The Zombie process is a bit strange. I've pasted some information > below. As you might expect 'kill -9' has no effect, but if I kill > its parent process things do not end well. I lose bits of the Menu > bar on the bottom of the screen. > > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -ef | grep shotwell > dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] > > dougie 2023 1862 0 19:29 pts/0 00:00:00 grep > --colour=auto shotwell > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1939 > UID PID PPID C STIME TTY TIME CMD > dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] > > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1717 > UID PID PPID C STIME TTY TIME CMD > dougie 1717 1 0 19:14 ? 00:00:03 python > /usr/lib/linuxmint/mintMenu/mintMenu.py > dougie at phoenix ~ $ > dougie at phoenix ~ $ ps -fp1717 | fold > UID PID PPID C STIME TTY TIME CMD > dougie 1717 1 0 19:14 ? 00:00:03 python > /usr/lib/linuxmint/mintMe > nu/mintMenu.py > --oaf-activate-iid=OAFIID:GNOME_mintMenu_Factory --oaf-ior-fd=18 > dougie at phoenix ~ $ > > > Does this happen if you run from the command line or just from the menu? > I think it's both, but I shall check. > I tried (unsuccessfully) to use the package manager in Linux Mint > 10 (Julia) and hit problems that I couldn't get beyond. valac and > gstreamer deps IIRC. I tried using the repo on the shotwell > website but it installed 0.10 and I'm really keen on the > hierarchical tagging. I didn't pursue it because I've been meaning > to move to Linux Mint for Debian for some time and I have wiped my > PC and run LXDE. I compiled from the source tarball so I'm not > sure how to purge before starting over. > > > I've just been told the way to do this is to run make uninstall, then > log out and log back in. The settings should be gone. > Ah well, there's the rub. It took me ages to get it to compile (problems with gstreamer deps mainly) and I can't for the life of me figure out what loose wire I finally fiddled with that caused it to compile, and I'm not keen on risking it! However, I'm currently installing it on my netbook on a clean install of LXDE, so I shall pay more attention this time. Dougie From eric at yorba.org Wed Sep 14 19:18:52 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 14 Sep 2011 12:18:52 -0700 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: <4E70FC45.6030506@highmoor.co.uk> References: <4E70817F.6030707@highmoor.co.uk> <4E70F4B6.5050902@highmoor.co.uk> <4E70FC45.6030506@highmoor.co.uk> Message-ID: On Wed, Sep 14, 2011 at 12:11 PM, Dougie Nisbet wrote: > > Ah well, there's the rub. It took me ages to get it to compile (problems > with gstreamer deps mainly) and I can't for the life of me figure out what > loose wire I finally fiddled with that caused it to compile, and I'm not > keen on risking it! However, I'm currently installing it on my netbook on a > clean install of LXDE, so I shall pay more attention this time. > > Dougie > "make install" and "make uninstall" don't involve compiling the program; you can run make once and make install/uninstall repeatedly. So unless the hiccup was in the install stage, you should be safe. - Eric From lucas at yorba.org Wed Sep 14 19:24:29 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Sep 2011 12:24:29 -0700 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: <4E70FB47.1010306@highmoor.co.uk> References: <4E70FB47.1010306@highmoor.co.uk> Message-ID: > Would it be feasible to synchronise > my shotwell setup on a second > machine and if so, what should I > rsync over? This isn't actually supported, but in theory you'd need to sync two things: first, your photo files (which I'm assuming are in ~/Pictures) and second, your entire ~/.shotwell/ directory, where the Shotwell database and thumbnails are stored. Lucas From clanlaw at googlemail.com Wed Sep 14 19:32:38 2011 From: clanlaw at googlemail.com (Colin Law) Date: Wed, 14 Sep 2011 20:32:38 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> Message-ID: On 14 September 2011 20:24, Lucas Beeler wrote: >> Would it be feasible to synchronise >> my shotwell setup on a second >> machine and if so, what should I >> rsync over? > > This isn't actually supported, but in theory you'd need to sync two > things: first, your photo files (which I'm assuming are in ~/Pictures) > and second, your entire ~/.shotwell/ directory, where the Shotwell > database and thumbnails are stored. I do exactly that with no problems. I take care not to have shotwell running on either when I sync, and also that I have the same version of shotwell on both machines. I only ever sync from my master machine to the slave (not back again) so the worst that can happen is that the slave one might get messed up. Colin -- gplus.to/clanlaw From jim at yorba.org Wed Sep 14 21:52:17 2011 From: jim at yorba.org (Jim Nelson) Date: Wed, 14 Sep 2011 14:52:17 -0700 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> Message-ID: If you get this to work, I'd be curious to hear all the details. -- Jim On Wed, Sep 14, 2011 at 12:32 PM, Colin Law wrote: > On 14 September 2011 20:24, Lucas Beeler wrote: > >> Would it be feasible to synchronise > >> my shotwell setup on a second > >> machine and if so, what should I > >> rsync over? > > > > This isn't actually supported, but in theory you'd need to sync two > > things: first, your photo files (which I'm assuming are in ~/Pictures) > > and second, your entire ~/.shotwell/ directory, where the Shotwell > > database and thumbnails are stored. > > I do exactly that with no problems. I take care not to have shotwell > running on either when I sync, and also that I have the same version > of shotwell on both machines. I only ever sync from my master machine > to the slave (not back again) so the worst that can happen is that the > slave one might get messed up. > > Colin > > -- > gplus.to/clanlaw > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Sep 14 21:56:08 2011 From: jim at yorba.org (Jim Nelson) Date: Wed, 14 Sep 2011 14:56:08 -0700 Subject: [Shotwell] Import not respecting destination setting (Copy into new location) In-Reply-To: <4E707598.6040505@highmoor.co.uk> References: <4E707598.6040505@highmoor.co.uk> Message-ID: Regarding the settings not persisting, others (who are running Ubuntu Lucid Lynx) have seen this problem as well. It's because they haven't installed a full set of dconf packages, which is how gsettings persist configuration information. Without it, gsettings defaults to a memory-based backing, which, as you might guess, go away when the program exits. More information in this thread: http://lists.yorba.org/pipermail/shotwell/2011-September/002958.html -- Jim On Wed, Sep 14, 2011 at 2:36 AM, Dougie Nisbet wrote: > I've just, after a bit of a struggle, managed to get Shotwell 0.11.1 > running on Linux Mint LXDE. I've been using f-spot for the last few years > but things are pretty quiet on that scene at the moment and the introduction > of hierarchical tags into shotwell made me decide to give it another try. > > I'm a bit exasperated because I wanted to parallel run f-spot and shotwell > before deciding on whether to switch. My f-spot photos are in /jpegs, and I > created a new directory /images for shotwell. > > In preferences I changed the destination to /images (currently empty) and > then for some reason shotwell spent a few minutes 'refreshing library'. > shotwell didn't seem to want to remember my setting (changing it back to > 'File System') so exited and restarted a couple of times and eventually the > setting persisted. > > I selected import and chose my default f-spot database. The import appeared > to be going well but I noticed that nothing was appearing in /images. When I > checked shotwell progress I noticed it was periodically writing metadata to > the file (a setting I'd enabled), but it was writing the information to the > files in their original location (/jpegs). I aborted the import. > > I know that I can import directly from a folder location but I notice that > if I do this it doesn't retain the hierarchical tag structure that I want. > > One thing I always do with f-spot is run it in debug mode so that I can see > what's going on in a terminal window, and there doesn't appear to be a > verbose or debug option in shotwell. > > So, in a nutshell. I want to import my f-spot database and copy them to a > new location (although it is a bit academic now as shotwell has overwritten > the metadata for a lot of the originals :( ). Is this likely to be a bug or > NewUser Error? > > Dougie > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From clanlaw at googlemail.com Thu Sep 15 08:06:54 2011 From: clanlaw at googlemail.com (Colin Law) Date: Thu, 15 Sep 2011 09:06:54 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> Message-ID: On 14 September 2011 22:52, Jim Nelson wrote: > If you get this to work, I'd be curious to hear all the details. As I said it is already working well for me. The commands I run are rsync -avi --delete --stats /home/my_user_name/Pictures/ my_user_name at eeyore.local:/home/my_user_name/Pictures rsync -avi --delete --stats /home/my_user_name/.shotwell/ my_user_name at eeyore.local:/home/my_user_name/.shotwell Where obviously you have to put the correct user name and replace eeyore with the name of machine you are writing to. To avoid having to enter passwords every time then setup ssh keys. While testing the commands you can include -n and it will tell you what it would do, but without actually doing it. In fact I have a script which I run that first runs the commands with -n so I can check it looks ok, then asks for confirmation to proceed to run the commands without -n. Colin > On Wed, Sep 14, 2011 at 12:32 PM, Colin Law wrote: >> >> On 14 September 2011 20:24, Lucas Beeler wrote: >> >> Would it be feasible to synchronise >> >> my shotwell setup on a second >> >> machine and if so, what should I >> >> rsync over? >> > >> > This isn't actually supported, but in theory you'd need to sync two >> > things: first, your photo files (which I'm assuming are in ~/Pictures) >> > and second, your entire ~/.shotwell/ directory, where the Shotwell >> > database and thumbnails are stored. >> >> I do exactly that with no problems. ?I take care not to have shotwell >> running on either when I sync, and also that I have the same version >> of shotwell on both machines. ?I only ever sync from my master machine >> to the slave (not back again) so the worst that can happen is that the >> slave one might get messed up. -- gplus.to/clanlaw From stesind at googlemail.com Thu Sep 15 11:04:26 2011 From: stesind at googlemail.com (Steffen) Date: Thu, 15 Sep 2011 13:04:26 +0200 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> Message-ID: <1316084666.2495.2.camel@steffen-MS-7588> Why to sync the .shotwell folder too? Just sync the picture folder. Then let watch Shotwell this folder automatically. That whay you would be able so sync only some pictures. From clanlaw at googlemail.com Thu Sep 15 11:32:11 2011 From: clanlaw at googlemail.com (Colin Law) Date: Thu, 15 Sep 2011 12:32:11 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: <1316084666.2495.2.camel@steffen-MS-7588> References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> Message-ID: On 15 September 2011 12:04, Steffen wrote: > Why to sync the .shotwell folder too? Just sync the picture folder. Then > let watch Shotwell this folder automatically. That whay you would be > able so sync only some pictures. Because I want tags and so on to be available on the slave machine also. Colin -- gplus.to/clanlaw From ian at mnementh.co.uk Thu Sep 15 11:44:30 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Thu, 15 Sep 2011 12:44:30 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: <1316084666.2495.2.camel@steffen-MS-7588> References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> Message-ID: <1316087070.1826.0.camel@wirenth> On Thu, 2011-09-15 at 13:04 +0200, Steffen wrote: > Why to sync the .shotwell folder too? Just sync the picture folder. Then > let watch Shotwell this folder automatically. That whay you would be > able so sync only some pictures. Tags? From el.cameleon.1 at gmail.com Thu Sep 15 11:56:55 2011 From: el.cameleon.1 at gmail.com (Vincent) Date: Thu, 15 Sep 2011 13:56:55 +0200 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: <1316087070.1826.0.camel@wirenth> References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> Message-ID: why don't you simply check the option to store tags in the pictures (which should be checked by default in my opinion)? 2011/9/15 Ian Molton > On Thu, 2011-09-15 at 13:04 +0200, Steffen wrote: > > Why to sync the .shotwell folder too? Just sync the picture folder. Then > > let watch Shotwell this folder automatically. That whay you would be > > able so sync only some pictures. > > Tags? > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From ian at mnementh.co.uk Thu Sep 15 12:16:20 2011 From: ian at mnementh.co.uk (Ian Molton) Date: Thu, 15 Sep 2011 13:16:20 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> Message-ID: <1316088980.1826.2.camel@wirenth> On Thu, 2011-09-15 at 13:56 +0200, Vincent wrote: > why don't you simply check the option to store tags in the pictures (which > should be checked by default in my opinion)? I'm really glad your opinion isnt in use :-) I use Shotwell because it NEVER writes data to my photos. If they are never written to, they will never (barring fs corruption) be destroyed. This is the only safe default, and all software should be safe by default. -Ian From dougie at highmoor.co.uk Thu Sep 15 12:23:48 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 15 Sep 2011 13:23:48 +0100 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> Message-ID: <4E71EE54.3080602@highmoor.co.uk> I'm guessing, but I suspect that tag hierarchy might not be honoured. Area images in a watched directory treated like an import? Would there be much of a saving to using a watched folder instead of rsyncing the .shotwell folder? I've been doing it for a couple of years with f-spot and planned doing the same with shotwell. A simple one-liner when I boot up the netbook and everything's tidy. rsync -ar kitchen:/jpegs/ /jpegs && rsync -ar kitchen:/home/dougie/.shotwell/ /home/dougie/.shotwell Dougie On 15/09/2011 12:56, Vincent wrote: > why don't you simply check the option to store tags in the pictures (which > should be checked by default in my opinion)? > > 2011/9/15 Ian Molton > >> On Thu, 2011-09-15 at 13:04 +0200, Steffen wrote: >>> Why to sync the .shotwell folder too? Just sync the picture folder. Then >>> let watch Shotwell this folder automatically. That whay you would be >>> able so sync only some pictures. >> Tags? >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Thu Sep 15 12:37:07 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 15 Sep 2011 13:37:07 +0100 Subject: [Shotwell] duplicate tags Message-ID: <4E71F173.30409@highmoor.co.uk> Looking at my imported collection I can see the hierarchical tags from f-spot's database, as well as loads of tags in a flat structure. It seems that I have duplicate tags (though none on the same level). This was something that wasn't possible in f-spot and I'm wondering whether this is WAD and duplicate tags are ok (I can think of where this might be handy in a hierarchical tag bundle) or whether it's something I need to worry about. Dougie From dougie at highmoor.co.uk Thu Sep 15 13:09:48 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 15 Sep 2011 14:09:48 +0100 Subject: [Shotwell] Resetting and Starting Again In-Reply-To: <4E70FC45.6030506@highmoor.co.uk> References: <4E70817F.6030707@highmoor.co.uk> <4E70F4B6.5050902@highmoor.co.uk> <4E70FC45.6030506@highmoor.co.uk> Message-ID: <4E71F91C.6080106@highmoor.co.uk> On 14/09/2011 20:11, Dougie Nisbet wrote: > On 14/09/2011 20:02, Eric Gregory wrote: >> On Wed, Sep 14, 2011 at 11:38 AM, Dougie Nisbet >> > wrote: >> >> The Zombie process is a bit strange. I've pasted some information >> below. As you might expect 'kill -9' has no effect, but if I kill >> its parent process things do not end well. I lose bits of the Menu >> bar on the bottom of the screen. >> >> dougie at phoenix ~ $ >> dougie at phoenix ~ $ ps -ef | grep shotwell >> dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] >> >> dougie 2023 1862 0 19:29 pts/0 00:00:00 grep >> --colour=auto shotwell >> dougie at phoenix ~ $ >> dougie at phoenix ~ $ ps -fp1939 >> UID PID PPID C STIME TTY TIME CMD >> dougie 1939 1717 5 19:17 ? 00:00:39 [shotwell] >> >> dougie at phoenix ~ $ >> dougie at phoenix ~ $ ps -fp1717 >> UID PID PPID C STIME TTY TIME CMD >> dougie 1717 1 0 19:14 ? 00:00:03 python >> /usr/lib/linuxmint/mintMenu/mintMenu.py >> dougie at phoenix ~ $ >> dougie at phoenix ~ $ ps -fp1717 | fold >> UID PID PPID C STIME TTY TIME CMD >> dougie 1717 1 0 19:14 ? 00:00:03 python >> /usr/lib/linuxmint/mintMe >> nu/mintMenu.py >> --oaf-activate-iid=OAFIID:GNOME_mintMenu_Factory --oaf-ior-fd=18 >> dougie at phoenix ~ $ >> >> >> Does this happen if you run from the command line or just from the menu? >> > > I think it's both, but I shall check. It's both. From monnier at iro.umontreal.ca Thu Sep 15 13:19:51 2011 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Thu, 15 Sep 2011 09:19:51 -0400 Subject: [Shotwell] Duplicating on a second machine References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> <1316088980.1826.2.camel@wirenth> Message-ID: >> why don't you simply check the option to store tags in the pictures (which >> should be checked by default in my opinion)? > I'm really glad your opinion isnt in use :-) > I use Shotwell because it NEVER writes data to my photos. > If they are never written to, they will never (barring fs corruption) be > destroyed. > This is the only safe default, and all software should be safe by > default. But tags should somehow be written down somewhere in a standard place, so that you can use the same photos in different applications and the info you set up in one is available to the other. I hate it when an application tries to "lock me in" by keeping the data in a proprietary format. I think Shotwell should aim to make its database fully redundant, like a cache, in the sense that it can be reconstructed from the data in Pictures. Stefan From dougie at highmoor.co.uk Thu Sep 15 13:33:09 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 15 Sep 2011 14:33:09 +0100 Subject: [Shotwell] duplicate tags In-Reply-To: <4E71F173.30409@highmoor.co.uk> References: <4E71F173.30409@highmoor.co.uk> Message-ID: <4E71FE95.8090608@highmoor.co.uk> On 15/09/2011 13:37, Dougie Nisbet wrote: > I'm wondering whether this is WAD and duplicate tags are ok (I can > think of where this might be handy in a hierarchical tag bundle) or > whether it's something I need to worry about. Hmmm, maybe not so useful. If I select an image and Ctrl-T to allocate a tag. Type in the tag, it auto-completes, and I select it. But which tag has it chosen? From pt at traversin.org Thu Sep 15 13:53:05 2011 From: pt at traversin.org (pt) Date: Thu, 15 Sep 2011 15:53:05 +0200 Subject: [Shotwell] duplicate tags In-Reply-To: <4E71FE95.8090608@highmoor.co.uk> References: <4E71F173.30409@highmoor.co.uk> <4E71FE95.8090608@highmoor.co.uk> Message-ID: On 15 September 2011 15:33, Dougie Nisbet wrote: > On 15/09/2011 13:37, Dougie Nisbet wrote: >> >> ?I'm wondering whether this is WAD and duplicate tags are ok (I can think >> of where this might be handy in a hierarchical tag bundle) or whether it's >> something I need to worry about. There are open tickets for that: #4051 and #4081 (the latter apparently solved, but I didn't try it yet) > Hmmm, maybe not so useful. If I select an image and Ctrl-T to allocate a > tag. Type in the tag, it auto-completes, and I select it. But which tag has > it chosen? I totally agree on this one. *Maybe* we should disallow having same-name tags on different levels, until we have a robust solution for that. It could be a setting in preferences. The MWG guidelines state homonyms should be handled, though. Piergi -- Web: http://traversin.org GNU/Linux user 190604 From lucas at yorba.org Thu Sep 15 16:27:19 2011 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 15 Sep 2011 09:27:19 -0700 Subject: [Shotwell] duplicate tags In-Reply-To: References: <4E71F173.30409@highmoor.co.uk> <4E71FE95.8090608@highmoor.co.uk> Message-ID: Hi Guys, The long term plan is to have comprehensive facilities in Shotwell for autocompletion and tag disambiguation even when you have multiple tags with the same names at different places in the tag hierarchy. There are a variety of tickets related to this in Yorba's redmine database, some mentioned by pt, but there's also #3911. We wish we could have done all of this in one release, but we're an open-source not-for-profit, so we don't have a huge amount of resources to throw around. Alas. Lucas On Thu, Sep 15, 2011 at 6:53 AM, pt wrote: > On 15 September 2011 15:33, Dougie Nisbet wrote: >> On 15/09/2011 13:37, Dougie Nisbet wrote: >>> >>> ?I'm wondering whether this is WAD and duplicate tags are ok (I can think >>> of where this might be handy in a hierarchical tag bundle) or whether it's >>> something I need to worry about. > > There are open tickets for that: #4051 and #4081 (the latter > apparently solved, but I didn't try it yet) > >> Hmmm, maybe not so useful. If I select an image and Ctrl-T to allocate a >> tag. Type in the tag, it auto-completes, and I select it. But which tag has >> it chosen? > > I totally agree on this one. > *Maybe* we should disallow having same-name tags on different levels, > until we have a robust solution for that. It could be a setting in > preferences. > > The MWG guidelines state homonyms should be handled, though. > > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Thu Sep 15 16:31:30 2011 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 15 Sep 2011 09:31:30 -0700 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> <1316088980.1826.2.camel@wirenth> Message-ID: Just to chime in about writing hierarchical tags to files: as of today, Shotwell will write full tag hierarchy information into the photo files when the "write metadata to files" option is selected. It stores this information in two XMP fields understood by at least digiKam and most Microsoft applications. Be aware that many other applications may not be able to interpret hierarchical tag information though. Cheers, Lucas From pt at traversin.org Thu Sep 15 17:39:18 2011 From: pt at traversin.org (pt) Date: Thu, 15 Sep 2011 19:39:18 +0200 Subject: [Shotwell] duplicate tags In-Reply-To: References: <4E71F173.30409@highmoor.co.uk> <4E71FE95.8090608@highmoor.co.uk> Message-ID: On 15 September 2011 18:27, Lucas Beeler wrote: > > The long term plan is to have comprehensive facilities in Shotwell for > autocompletion and tag disambiguation even when you have multiple tags > with the same names at different places in the tag hierarchy. There > are a variety of tickets related to this in Yorba's redmine database, > some mentioned by pt, but there's also #3911. Excellent! > We wish we could have done all of this in one release, but we're an > open-source not-for-profit, so we don't have a huge amount of > resources to throw around. Alas. I don't think anybody was complaining, me surely not. Plus, as far as my experience goes, not-for-profit organisations usually do better than multi-millionaires companies. Keep up the good work! p. -- Web: http://traversin.org GNU/Linux user 190604 From jim at yorba.org Thu Sep 15 18:37:54 2011 From: jim at yorba.org (Jim Nelson) Date: Thu, 15 Sep 2011 11:37:54 -0700 Subject: [Shotwell] Duplicating on a second machine In-Reply-To: References: <4E70FB47.1010306@highmoor.co.uk> <1316084666.2495.2.camel@steffen-MS-7588> <1316087070.1826.0.camel@wirenth> <1316088980.1826.2.camel@wirenth> Message-ID: This is the perpetual debate in photo management software: If you want to keep the photos pristine, you have to store the metadata elsewhere. But if you store the metadata elsewhere, other applications may not be able to use it. As Lucas pointed out, even if we write hierarchical tags to the photo files (which is possible by selecting the option in the Preferences dialog), not all photo apps would understand them. Likewise, one piece of metadata Shotwell keeps for all photos is a list of transformations (rotation, crop, color correction, etc.) If this was stored with the photo, other applications would (or should) honor these transformations when displaying the photo. I don't know of any thorough, open way of storing photo transformations that is widely honored (with the exception of rotation). We certainly don't want to lock anyone in to Shotwell, we just are trying to work through all these requirements in a way that allows most users to get what they want out of it. We do have some tickets that will allow Shotwell to be even more flexible in this regard: http://redmine.yorba.org/issues/1879 http://redmine.yorba.org/issues/3800 http://redmine.yorba.org/issues/3642 -- Jim On Thu, Sep 15, 2011 at 6:19 AM, Stefan Monnier wrote: > >> why don't you simply check the option to store tags in the pictures > (which > >> should be checked by default in my opinion)? > > I'm really glad your opinion isnt in use :-) > > I use Shotwell because it NEVER writes data to my photos. > > If they are never written to, they will never (barring fs corruption) be > > destroyed. > > This is the only safe default, and all software should be safe by > > default. > > But tags should somehow be written down somewhere in a standard place, > so that you can use the same photos in different applications and the > info you set up in one is available to the other. > I hate it when an application tries to "lock me in" by keeping the data > in a proprietary format. > I think Shotwell should aim to make its database fully redundant, like > a cache, in the sense that it can be reconstructed from the data > in Pictures. > > > Stefan > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From oliver at first.in-berlin.de Fri Sep 16 13:27:21 2011 From: oliver at first.in-berlin.de (oliver) Date: Fri, 16 Sep 2011 15:27:21 +0200 Subject: [Shotwell] Non-destructive editing Message-ID: <20110916132721.GA5686@siouxsie> Hello, it seems the non-destructive editing only holds for short moments. When I edited one picture and looked at the next, I could not make the changes of the former picture undone. Also, when non-destructive editing is really possible with shotwell, then saving the editing sequence, instead of the resulting picture. With the save eediting sequence, the editing could be done on the fly from the src pic and with the recipe/editing sequence. And much space would be saved too, because only the editing recipe must be saved, not the whole resulting filr (or files, if many). So, the concept should be changed, otherwise the "non-destructive editing feature" is not really offering, what it seems to offer. Saving a resulting file should be done only explicitly by the user (for example if the reulting file is needed as seperate entity, e.,g. for mailing it to someone). Otherwise the needed disk space is growing without need. And with a saved editing recipe, this might be reused on other pictures too, so for a bunch of files one can create such a recipe/workflow ONCE and apply often. Even after a new start of shotwell, so it's then independent of the session. Ciao, Oliver From dougie at highmoor.co.uk Fri Sep 16 17:53:57 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Fri, 16 Sep 2011 18:53:57 +0100 Subject: [Shotwell] import modifies image files Message-ID: <4E738D35.7020403@highmoor.co.uk> I'm slightly alarmed. I had pretty much decided to take the plunge and migrate directly from f-spot to shotwell until I was faced with a mixture of hierarchical and flat tags. I use tags a lot and suddenly things were looking very messy and a bit scary, so I decided to go back to f-spot while I still could, with the view of revisiting shotwell in a more methodical manner. With this in mind, and with the view of parallel running f-spot and shotwell for a bit, I deleted and reinstalled. This time when I asked shotwell to import my f-spot database, I made sure it did not have "Write to Image File" checked. Then I kicked off the import. However the imported files are being shown as modified, and when I look at the exif data using exiftool I can see a File Modification Time coinciding with the import. Is shotwell modifying the images even though I've asked it not to, and if so, in what way? Thanks, Dougie PS: An annoyance with this behaviour is that I do a nightly backup of my image directory to another machine using 'rsync'. And now after the import the backup will think every single image has changed and transfer the lot. From jim at yorba.org Fri Sep 16 20:17:17 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 16 Sep 2011 13:17:17 -0700 Subject: [Shotwell] import modifies image files In-Reply-To: <4E738D35.7020403@highmoor.co.uk> References: <4E738D35.7020403@highmoor.co.uk> Message-ID: This is happening due to a limitation of F-Spot and it's tag writer. F-Spot doesn't write the hierarchical tag structure into the file, merely each component of the hierarchy as a flat list, like so: /Vacation/California/San Francisco is written as Vacation, California, San Francisco Which we can't distinguish from the photo being tagged as "Vacation", "California", and "San Francisco". We do read in the hierarchy from the F-Spot database and use that, but if we ever have to examine the file again to reflect its metadata in the Shotwell database, all these tags are added as root-level. Users in the past found this to be undesirable. To get around this, we were writing the hierarchy we found in the database back to the file, which is what you're seeing. On second consideration, we realize that this is problematic, especially for the user that's not expecting us to touch their files in any way. We believe we have a better solution in hand and hope to have this ready for 0.11.2: http://redmine.yorba.org/issues/4051 -- Jim On Fri, Sep 16, 2011 at 10:53 AM, Dougie Nisbet wrote: > I'm slightly alarmed. I had pretty much decided to take the plunge and > migrate directly from f-spot to shotwell until I was faced with a mixture of > hierarchical and flat tags. I use tags a lot and suddenly things were > looking very messy and a bit scary, so I decided to go back to f-spot while > I still could, with the view of revisiting shotwell in a more methodical > manner. > > With this in mind, and with the view of parallel running f-spot and > shotwell for a bit, I deleted and reinstalled. This time when I asked > shotwell to import my f-spot database, I made sure it did not have "Write to > Image File" checked. Then I kicked off the import. However the imported > files are being shown as modified, and when I look at the exif data using > exiftool I can see a File Modification Time coinciding with the import. > > Is shotwell modifying the images even though I've asked it not to, and if > so, in what way? > > Thanks, > > Dougie > > PS: An annoyance with this behaviour is that I do a nightly backup of my > image directory to another machine using 'rsync'. And now after the import > the backup will think every single image has changed and transfer the lot. > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From pt at traversin.org Fri Sep 16 21:25:01 2011 From: pt at traversin.org (pt) Date: Fri, 16 Sep 2011 23:25:01 +0200 Subject: [Shotwell] Bug #4051: imported non-hierarchical tag should match existing hierarchical tag Message-ID: This ticket is marked as ``fixed''. I'm extremely happy for that :-) I have one question, though: how this handles homonym tags on different levels? I don't have any duplicate tag in my tree, but I was wondering if there is a priority in choosing the tag based on the position on the tree or something else. Thanks for the good work, can't wait to try this one out. Piergi -- Web: http://traversin.org GNU/Linux user 190604 From dougie at highmoor.co.uk Fri Sep 16 21:29:39 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Fri, 16 Sep 2011 22:29:39 +0100 Subject: [Shotwell] duplicate tags In-Reply-To: References: <4E71F173.30409@highmoor.co.uk> <4E71FE95.8090608@highmoor.co.uk> Message-ID: <4E73BFC3.2000600@highmoor.co.uk> On 15/09/2011 18:39, pt wrote: > >> We wish we could have done all of this in one release, but we're an >> open-source not-for-profit, so we don't have a huge amount of >> resources to throw around. Alas. > I don't think anybody was complaining, me surely not. > Plus, as far as my experience goes, not-for-profit organisations > usually do better than multi-millionaires companies. absolutely. well said! From eric at yorba.org Fri Sep 16 21:36:35 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 16 Sep 2011 14:36:35 -0700 Subject: [Shotwell] Non-destructive editing In-Reply-To: <20110916132721.GA5686@siouxsie> References: <20110916132721.GA5686@siouxsie> Message-ID: On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: > it seems the non-destructive editing only holds for short moments. > > When I edited one picture and looked at the next, > I could not make the changes of the former picture > undone. > This sounds like a possible bug in the undo/redo stack. Do you have a sequence of steps that makes this occur? If so you could file a bug (or just e-mail, that's fine too). We only write changes to disk when you "export" a photo. Did you try reverting all changes to the photo? Or if you just want to temporarily see the original photo, you can hold down the Shift key when the photo is open. > Also, when non-destructive editing is really possible with > shotwell, then saving the editing sequence, instead of the resulting > picture. > With the save eediting sequence, the editing could be done on the fly > from the src pic and with the recipe/editing sequence. > And much space would be saved too, because only the editing recipe must be > saved, > not the whole resulting filr (or files, if many). > Good news -- this is exactly what Shotwell does today! The bad news is you can't enable/disable individual steps in the transformation "recipe" or apply those changes in a batch to other photos. The second part isn't as straightforward as it sounds, since photos with different dimension and color profiles can't use the same underlying transformation data for certain types of transformations. - Eric From lucas at yorba.org Fri Sep 16 21:38:14 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 16 Sep 2011 14:38:14 -0700 Subject: [Shotwell] Bug #4051: imported non-hierarchical tag should match existing hierarchical tag In-Reply-To: References: Message-ID: > how this handles homonym tags on different levels? Right now, it's sorta exciting: if you have multiple tags with the same name in different tree locations, you can never be quite sure which one you're gonna get. ;-) Cheers, Lucas On Fri, Sep 16, 2011 at 2:25 PM, pt wrote: > This ticket is marked as ``fixed''. I'm extremely happy for that :-) > > I have one question, though: how this handles homonym tags on different levels? > I don't have any duplicate tag in my tree, but I was wondering if > there is a priority in choosing the tag based on the position on the > tree or something else. > > Thanks for the good work, can't wait to try this one out. > Piergi > -- > Web: http://traversin.org > GNU/Linux user 190604 > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From christophe.drevet at gmail.com Sat Sep 17 12:32:46 2011 From: christophe.drevet at gmail.com (Christophe Drevet) Date: Sat, 17 Sep 2011 14:32:46 +0200 Subject: [Shotwell] merging several photo directories into one Message-ID: Hi all, I have a somewhat big photo database (9000+). Photos are stored in multiple directories on a single machine for historical reasons. They also are not organized in the same way. Some directories use Year/Month/Day, others Year/Month, and others totally different schemes. Now, I have a big disk with a lot of space available. I would like to move all my photos in a single place and using a single scheme (Year/Month). I don't see a way to do this with shotwell. I don't see how to do it at all, actually. Any help would be greatly appreciated. Regards, -- Christophe. From oliver at first.in-berlin.de Sat Sep 17 12:37:12 2011 From: oliver at first.in-berlin.de (oliver) Date: Sat, 17 Sep 2011 14:37:12 +0200 Subject: [Shotwell] Non-destructive editing In-Reply-To: References: <20110916132721.GA5686@siouxsie> Message-ID: <20110917123712.GG1714@siouxsie> On Fri, Sep 16, 2011 at 02:36:35PM -0700, Eric Gregory wrote: > On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: > > > it seems the non-destructive editing only holds for short moments. > > > > When I edited one picture and looked at the next, > > I could not make the changes of the former picture > > undone. > > > > This sounds like a possible bug in the undo/redo stack. Do you have a > sequence of steps that makes this occur? If so you could file a bug (or just > e-mail, that's fine too). Hmhhh, it seems the problem occurs, if shotwell was quitted. When started next, the Undo-hierarchy is not available. > > We only write changes to disk when you "export" a photo. Did you try > reverting all changes to the photo? Or if you just want to temporarily see > the original photo, you can hold down the Shift key when the photo is open. Yeah, this works fine. Thank you for the hint. :-) If the Undo-hierarchy also could be used after quitting and executing shotwell again, then this would be nice. > > > > > Also, when non-destructive editing is really possible with > > shotwell, then saving the editing sequence, instead of the resulting > > picture. > > With the save eediting sequence, the editing could be done on the fly > > from the src pic and with the recipe/editing sequence. > > And much space would be saved too, because only the editing recipe must be > > saved, > > not the whole resulting filr (or files, if many). > > > > Good news -- this is exactly what Shotwell does today! OK, fine. :-) > > The bad news is you can't enable/disable individual steps in the > transformation "recipe" or apply those changes in a batch to other photos. Not so fine. This would be really nice. > The second part isn't as straightforward as it sounds, since photos with > different dimension and color profiles can't use the same underlying > transformation data for certain types of transformations. Hmhh, but at least for some transformations this would work: "enhance" the picture and "red eyes removel" for example couold just be done - independent of the picture size, I think. When cutting a picture is done, this could maybe be done via pixel-coordinates, or relative coordinates. At least the later should also work with pictures of many different sizes. Such a "recipe" or "workflow" could be tried on a picture, and applied if it is possible, otherwise not applied, or the user could be asked, what to do, if a step in this list of editing commands could not be applied. Ciao, Oliver From oliver at first.in-berlin.de Sat Sep 17 12:46:24 2011 From: oliver at first.in-berlin.de (oliver) Date: Sat, 17 Sep 2011 14:46:24 +0200 Subject: [Shotwell] merging several photo directories into one In-Reply-To: References: Message-ID: <20110917124624.GH1714@siouxsie> On Sat, Sep 17, 2011 at 02:32:46PM +0200, Christophe Drevet wrote: > Hi all, > > I have a somewhat big photo database (9000+). Photos are stored in > multiple directories on a single machine for historical reasons. They > also are not organized in the same way. Some directories use > Year/Month/Day, others Year/Month, and others totally different > schemes. > > Now, I have a big disk with a lot of space available. I would like to > move all my photos in a single place and using a single scheme > (Year/Month). I don't see a way to do this with shotwell. I don't see > how to do it at all, actually. [...] You want to have a picture directory, which has subdirectories for year and month and you want to put files from different directories with different subdirectory-structure into the one and new directory with that new structure scheme? Do I understand correctly? You could use Perl or some other programming language to achieve this. Which OS do you use? Or you could just import the files into shotwell. AFAIK shotwell uses $PICTURE_PATH//// as a scheme (like fspot and digikam AFAIK both also do), and that makes sense to me. So, you could just import all files (with COPYING) and this should do it... ...but you looked only for $PICTURE_PATH/// and not for $PICTURE_PATH//// If you are fine with Year/Month/Day, you could just import the pics, as mentioned above... Ciao, Oliver From christophe.drevet at gmail.com Sat Sep 17 13:51:43 2011 From: christophe.drevet at gmail.com (Christophe Drevet) Date: Sat, 17 Sep 2011 15:51:43 +0200 Subject: [Shotwell] merging several photo directories into one In-Reply-To: <20110917124624.GH1714@siouxsie> References: <20110917124624.GH1714@siouxsie> Message-ID: 2011/9/17 oliver : > > You want to have a picture directory, which has subdirectories > for year and month and you want to put files from different > directories with different subdirectory-structure into the one and new > directory with that new structure scheme? > > Do I understand correctly? That's exactly what I meant. > > You could use Perl or some other programming language to achieve this. > Which OS do you use? I'm using Debian GNU/Linux. Yes, maybe I'll have to do that. > > Or you could just import the files into shotwell. Yes, it would do the trick but? my photos are already in shotwell. And there are dozens of tags, events. As I think about it now, I guess I could just tell shotwell to save all metadata within the photos, start a blank shotwell session and import all photos. Maybe this will work... I'll try that. Thanks anyway. -- Christophe. From pt at traversin.org Sat Sep 17 14:04:20 2011 From: pt at traversin.org (pt) Date: Sat, 17 Sep 2011 16:04:20 +0200 Subject: [Shotwell] merging several photo directories into one In-Reply-To: <20110917124624.GH1714@siouxsie> References: <20110917124624.GH1714@siouxsie> Message-ID: On 17 September 2011 14:46, oliver wrote: > On Sat, Sep 17, 2011 at 02:32:46PM +0200, Christophe Drevet wrote: >> >> Now, I have a big disk with a lot of space available. I would like to >> move all my photos in a single place and using a single scheme >> (Year/Month). I don't see a way to do this with shotwell. I don't see >> how to do it at all, actually. If you are importing into Shotwell, just go to Edit->Preferences->Library and under 'Importing' choose 'Year/Month' as directory structure. Otherwise you could use exiftool. >From the exiftool man page: ========= exiftool '-Directory References: Message-ID: <1316271536.1887.9.camel@mind> To store my photo I use Rapid-Photo-downloader, is much more flexible than Shotwell to import task (that's the main and unique task for RPD so...). There's an option that permits to import photo from external disk to some path (your huge disk). So I think you should do: 1. Change Shotwell library path to new one (uncheck "Watch library") 2. Use RPD to copy the photos to the huge HD 3. Recheck "Watch Library" in Shotwell In this case Shotwell should recognize the new path for the photos already in the DB and your tags/vote/ecc. should be save. Anyway backup your .shotwell folder before start :) Il giorno sab, 17/09/2011 alle 14.32 +0200, Christophe Drevet ha scritto: > Hi all, > > I have a somewhat big photo database (9000+). Photos are stored in > multiple directories on a single machine for historical reasons. They > also are not organized in the same way. Some directories use > Year/Month/Day, others Year/Month, and others totally different > schemes. > > Now, I have a big disk with a lot of space available. I would like to > move all my photos in a single place and using a single scheme > (Year/Month). I don't see a way to do this with shotwell. I don't see > how to do it at all, actually. > > Any help would be greatly appreciated. > > Regards, -- Emanuele Grande OpenPGP key: 1024D/BF9328A7 | j.mp/cJTR3C 9F22 91FE F054 185D 3376 910E 62B3 85D6 BF93 28A7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From christophe.drevet at gmail.com Sat Sep 17 17:52:23 2011 From: christophe.drevet at gmail.com (Christophe Drevet) Date: Sat, 17 Sep 2011 19:52:23 +0200 Subject: [Shotwell] merging several photo directories into one In-Reply-To: <1316271536.1887.9.camel@mind> References: <1316271536.1887.9.camel@mind> Message-ID: Thank you all. I think I'll try RPD. I?didn't know this soft. I?didn't know either that exiftool could do this task. Anyway, thanks for your help. Best regards, -- Christophe. From adam at yorba.org Mon Sep 19 00:15:11 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 19 Sep 2011 04:15:11 +0400 Subject: [Shotwell] merging several photo directories into one In-Reply-To: References: <20110917124624.GH1714@siouxsie> Message-ID: <4E76898F.3010307@yorba.org> On 09/17/2011 05:51 PM, Christophe Drevet wrote: > 2011/9/17 oliver: >> You want to have a picture directory, which has subdirectories >> for year and month and you want to put files from different >> directories with different subdirectory-structure into the one and new >> directory with that new structure scheme? >> >> Do I understand correctly? > That's exactly what I meant. >> You could use Perl or some other programming language to achieve this. >> Which OS do you use? > I'm using Debian GNU/Linux. Yes, maybe I'll have to do that. >> Or you could just import the files into shotwell. > Yes, it would do the trick but? my photos are already in shotwell. And > there are dozens of tags, events. > > As I think about it now, I guess I could just tell shotwell to save > all metadata within the photos, start a blank shotwell session and > import all photos. Maybe this will work... I'll try that. That won't work, since Shotwell can't currently store all metadata within photos. It *can* store tags there, but can't store photo edits or event information, for example. So if you start a blank Shotwell session and reimport all your photos, you'll lose any edits that you've made to your photos from within Shotwell. It would be great if Shotwell could reorganize all your photos into a directory structure of your choice automatically. It can't do that yet, but we'd like to get there eventually: http://redmine.yorba.org/issues/2170 In the meantime, about the best you can do (as suggested elsewhere in this thread) is to use an external tool to rearrange the photos, then reimport the photos (either manually or via auto-import) into your *existing* Shotwell library. Then Shotwell should recognize the photos' new locations and all the metadata should tag along (so to speak). As someone else suggested, it's not a bad idea to back up your database before you try this. adam From adam at yorba.org Mon Sep 19 00:31:18 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 19 Sep 2011 04:31:18 +0400 Subject: [Shotwell] Non-destructive editing In-Reply-To: <20110917123712.GG1714@siouxsie> References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> Message-ID: <4E768D56.3060807@yorba.org> On 09/17/2011 04:37 PM, oliver wrote: > On Fri, Sep 16, 2011 at 02:36:35PM -0700, Eric Gregory wrote: >> On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: >> >> This sounds like a possible bug in the undo/redo stack. Do you have a >> sequence of steps that makes this occur? If so you could file a bug (or just >> e-mail, that's fine too). > Hmhhh, it seems the problem occurs, if shotwell was quitted. > When started next, the Undo-hierarchy is not available. I'm not aware of any other GNOME application that persists the undo hierarchy across sessions, so I don't think that Shotwell needs to either. The undo mechanism is not intended to allow you to go back and revert recent changes to individual photos; it simply allows you to, well, undo the last step that you did globally (just like in other GNOME apps). We could conceivably modify Shotwell someday to keep track of the order of changes you've made to each photo and to revert recent changes. But if we do implement that, the user interface will probably not be through Edit->Undo. >> We only write changes to disk when you "export" a photo. Did you try >> reverting all changes to the photo? Or if you just want to temporarily see >> the original photo, you can hold down the Shift key when the photo is open. > Yeah, this works fine. > Thank you for the hint. :-) > > If the Undo-hierarchy also could be used after quitting and executing shotwell > again, then this would be nice. Again, we probably won't implement this as discussed above. >>> Also, when non-destructive editing is really possible with >>> shotwell, then saving the editing sequence, instead of the resulting >>> picture. >>> With the save eediting sequence, the editing could be done on the fly >>> from the src pic and with the recipe/editing sequence. >>> And much space would be saved too, because only the editing recipe must be >>> saved, >>> not the whole resulting filr (or files, if many). >>> >> Good news -- this is exactly what Shotwell does today! > OK, fine. :-) > >> The bad news is you can't enable/disable individual steps in the >> transformation "recipe" or apply those changes in a batch to other photos. > Not so fine. > This would be really nice. Well, to be clear you *can* enable/disable individual steps in the transformation recipe. For example, suppose that you've cropped a photo, and adjusted its tint, and used the histogram sliders to change its dynamic range. Shotwell remembers that you've made all these changes, and you can go back and adjust any one individually afterward. To disable any of these changes, simply move the associated slider back to its default position. (Shotwell does not, however, remember the *order* in which you made changes to each photo.) > >> The second part isn't as straightforward as it sounds, since photos with >> different dimension and color profiles can't use the same underlying >> transformation data for certain types of transformations. > Hmhh, but at least for some transformations this would work: > "enhance" the picture and "red eyes removel" for example > couold just be done - independent of the picture size, I think. > > When cutting a picture is done, this could maybe be done > via pixel-coordinates, or relative coordinates. > > At least the later should also work with pictures of many different sizes. > > Such a "recipe" or "workflow" could be tried on a picture, and > applied if it is possible, otherwise not applied, or the user > could be asked, what to do, if a step in this list of editing commands > could not be applied. Yes - this might be nice to have. This is http://redmine.yorba.org/issues/2517 . adam From oliver at first.in-berlin.de Mon Sep 19 00:45:22 2011 From: oliver at first.in-berlin.de (oliver) Date: Mon, 19 Sep 2011 02:45:22 +0200 Subject: [Shotwell] Non-destructive editing In-Reply-To: <4E768D56.3060807@yorba.org> References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> <4E768D56.3060807@yorba.org> Message-ID: <20110919004522.GA8887@siouxsie> On Mon, Sep 19, 2011 at 04:31:18AM +0400, Adam Dingle wrote: > On 09/17/2011 04:37 PM, oliver wrote: > >On Fri, Sep 16, 2011 at 02:36:35PM -0700, Eric Gregory wrote: > >>On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: > >> > >>This sounds like a possible bug in the undo/redo stack. Do you have a > >>sequence of steps that makes this occur? If so you could file a bug (or just > >>e-mail, that's fine too). > >Hmhhh, it seems the problem occurs, if shotwell was quitted. > >When started next, the Undo-hierarchy is not available. > > I'm not aware of any other GNOME application that persists the undo > hierarchy across sessions, so I don't think that Shotwell needs to > either. The undo mechanism is not intended to allow you to go back > and revert recent changes to individual photos; it simply allows you > to, well, undo the last step that you did globally (just like in > other GNOME apps). We could conceivably modify Shotwell someday to > keep track of the order of changes you've made to each photo and to > revert recent changes. But if we do implement that, the user > interface will probably not be through Edit->Undo. [...] With Shift-key I can SEE the original file. How can I export it? If I want the original back, I have to look it up via path-to-file. So when changes to a picture were made, only the changed version can be exported, it seems. Pressing shift and clicking to the export functionality did not export the original. The file is not gone, but accessing the original is not easy. Ciao, Oliver From jonas at bushart.org Mon Sep 19 06:46:32 2011 From: jonas at bushart.org (Jonas Bushart) Date: Mon, 19 Sep 2011 08:46:32 +0200 Subject: [Shotwell] Non-destructive editing In-Reply-To: <20110919004522.GA8887@siouxsie> References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> <4E768D56.3060807@yorba.org> <20110919004522.GA8887@siouxsie> Message-ID: <4E76E548.9010706@bushart.org> Exporting the original photo is very easy. Open the export dialog (CTRL+SHIFT+E) and select "unmodified" (first option, "Unver?ndert" im Deutschen). This exports the original photo file. Jonas Am 19.09.2011 02:45, schrieb oliver: > On Mon, Sep 19, 2011 at 04:31:18AM +0400, Adam Dingle wrote: >> On 09/17/2011 04:37 PM, oliver wrote: >>> On Fri, Sep 16, 2011 at 02:36:35PM -0700, Eric Gregory wrote: >>>> On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: >>>> >>>> This sounds like a possible bug in the undo/redo stack. Do you have a >>>> sequence of steps that makes this occur? If so you could file a bug (or just >>>> e-mail, that's fine too). >>> Hmhhh, it seems the problem occurs, if shotwell was quitted. >>> When started next, the Undo-hierarchy is not available. >> >> I'm not aware of any other GNOME application that persists the undo >> hierarchy across sessions, so I don't think that Shotwell needs to >> either. The undo mechanism is not intended to allow you to go back >> and revert recent changes to individual photos; it simply allows you >> to, well, undo the last step that you did globally (just like in >> other GNOME apps). We could conceivably modify Shotwell someday to >> keep track of the order of changes you've made to each photo and to >> revert recent changes. But if we do implement that, the user >> interface will probably not be through Edit->Undo. > [...] > > With Shift-key I can SEE the original file. > How can I export it? > > If I want the original back, I have to look it up via > path-to-file. > > So when changes to a picture were made, only the changed version > can be exported, it seems. > > Pressing shift and clicking to the export functionality > did not export the original. > > The file is not gone, but accessing the original is not easy. > > Ciao, > Oliver > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From oliver at first.in-berlin.de Mon Sep 19 08:46:19 2011 From: oliver at first.in-berlin.de (oliver) Date: Mon, 19 Sep 2011 10:46:19 +0200 Subject: [Shotwell] Non-destructive editing In-Reply-To: <4E76E548.9010706@bushart.org> References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> <4E768D56.3060807@yorba.org> <20110919004522.GA8887@siouxsie> <4E76E548.9010706@bushart.org> Message-ID: <20110919084618.GA4218@siouxsie> Hello, The menue is misleading here. The "Unver?ndert" ("unmodified") is one option of "Format", and I can select - "Unver?ndert" (unchanged) - "Aktuell" (current) - "JPEG" - "PNG" - "TIFF" - "BMP" If "Unver?ndert" means original importet picture and "Aktuell" means changed picture (current state), then these two options have the wrong categories. They are not a format and only the other options are correct. This is misleading and wrong. There should be one format-entry and one for the status of the picture (which btw. could even be a complete history). Ciao, Oliver On Mon, Sep 19, 2011 at 08:46:32AM +0200, Jonas Bushart wrote: > Exporting the original photo is very easy. Open the export dialog > (CTRL+SHIFT+E) and select "unmodified" (first option, "Unver?ndert" > im Deutschen). This exports the original photo file. > > Jonas > > Am 19.09.2011 02:45, schrieb oliver: > >On Mon, Sep 19, 2011 at 04:31:18AM +0400, Adam Dingle wrote: > >>On 09/17/2011 04:37 PM, oliver wrote: > >>>On Fri, Sep 16, 2011 at 02:36:35PM -0700, Eric Gregory wrote: > >>>>On Fri, Sep 16, 2011 at 6:27 AM, oliver wrote: > >>>> > >>>>This sounds like a possible bug in the undo/redo stack. Do you have a > >>>>sequence of steps that makes this occur? If so you could file a bug (or just > >>>>e-mail, that's fine too). > >>>Hmhhh, it seems the problem occurs, if shotwell was quitted. > >>>When started next, the Undo-hierarchy is not available. > >> > >>I'm not aware of any other GNOME application that persists the undo > >>hierarchy across sessions, so I don't think that Shotwell needs to > >>either. The undo mechanism is not intended to allow you to go back > >>and revert recent changes to individual photos; it simply allows you > >>to, well, undo the last step that you did globally (just like in > >>other GNOME apps). We could conceivably modify Shotwell someday to > >>keep track of the order of changes you've made to each photo and to > >>revert recent changes. But if we do implement that, the user > >>interface will probably not be through Edit->Undo. > >[...] > > > >With Shift-key I can SEE the original file. > >How can I export it? > > > >If I want the original back, I have to look it up via > >path-to-file. > > > >So when changes to a picture were made, only the changed version > >can be exported, it seems. > > > >Pressing shift and clicking to the export functionality > >did not export the original. > > > >The file is not gone, but accessing the original is not easy. > > > >Ciao, > > Oliver > >_______________________________________________ > >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 xavierviader at gmail.com Mon Sep 19 09:56:05 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Mon, 19 Sep 2011 11:56:05 +0200 Subject: [Shotwell] question- database placement Message-ID: Hi all, I'm using a computer with 2 users and I'd like to share shotwell database, is it possible? Or it's always /home//.shotwell/data/ I'd like to have this as my mate and me threat the same pictures and it's a shame to repeat the job. Thanks xavi From xavierviader at gmail.com Mon Sep 19 10:01:54 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Mon, 19 Sep 2011 12:01:54 +0200 Subject: [Shotwell] =?iso-8859-1?q?question-=B4database_information?= Message-ID: Hi, I have a desktop computer where I use mainly shotwell but sometimes I work (using a share) with my laptop using the same library placement (on the network, of course). Is it possible to copy shotwell database to my laptop to don't lose all information done in the main computer? Is shotwell storing information by image without path? thanks xavi From el.cameleon.1 at gmail.com Mon Sep 19 14:11:13 2011 From: el.cameleon.1 at gmail.com (Vincent) Date: Mon, 19 Sep 2011 16:11:13 +0200 Subject: [Shotwell] question- database placement In-Reply-To: References: Message-ID: 2011/9/19 Xavi Viader > Hi vincent, > thanks for your answer but the link doesn't work: > > http://trac.yorba.org/wiki/Shotwell/multiplecomputeruser > Since the migration to redmine, the link has changed. I have found it on the new wiki. It is now: http://redmine.yorba.org/projects/shotwell/wiki/Shotwellmultiplecomputeruser Please keep us informed of your comments and thought about this subject, I am sure this is something which interest a lot of those who use Shotwell at home. From dougie at highmoor.co.uk Mon Sep 19 17:04:10 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 19 Sep 2011 18:04:10 +0100 Subject: [Shotwell] Cropping and Rejections Message-ID: <4E77760A.5080102@highmoor.co.uk> Hi, a couple of quick questions. I've checked the bugs and FAQ so apologies if already answered. Cropping: shotwell does the same as f-spot. i.e. It doesn't remember the last setting for cropping constraint. I usually select 'original photo', and have to keep selecting it as it's not remembered from photo to photo. Would it be possible for shotwell to 'remember last used setting'? Rejection Tag. Is there a shortcut key for tagging a photo as rejected? (This isn't much of an issue as I simply want to mark photos for later deletion, and I can do that using the star system. i.e. "1 star" means "delete later". Dougie PS: Perhaps off-topic, but one of the things I'm missing from f-spot is the 'straighten' feature. It was very simply. I've tried using straighten in the gimp and although it's possible it seems a bit long-winded. I'm fairly sure it's not possible in gthumb. Is there another editing tool I can use in the meantime (I could use f-spot itself I suppose) to straighten images as I believe a straighten facility is in the pipeline for shotwell sometime anyway. From roumano at gmail.com Mon Sep 19 19:25:51 2011 From: roumano at gmail.com (Roumano) Date: Mon, 19 Sep 2011 21:25:51 +0200 Subject: [Shotwell] Glibc invalid pointer Message-ID: <1316460351.1512.9.camel@roumano> I using the 0.11.1 version (build by gentoo) on a Gentoo 64 bits Linux, Linux roumano 2.6.39-gentoo-r3 #1 SMP Thu Jul 28 00:50:57 CEST 2011 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux I see lot of (50 times for 20 000 pictures) these kind of output on the terminal when launch shotwell for the first time (or a fresh configuration via mv ~/.xnview{,.old} && shotwell Output : ~ $ shotwell *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000002509c80 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000006b52670 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000006f64890 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000006f9bb80 *** No accelerated IMDCT transform found No accelerated IMDCT transform found *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000007a4e400 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000007cb9160 *** No accelerated IMDCT transform found No accelerated IMDCT transform found *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000007e13f40 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000007dd3fc0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x00000000088c35d0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x00000000087f7390 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000007c715a0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x00000000076b63b0 *** No accelerated IMDCT transform found Failed to play the file: couldn't get state. No accelerated IMDCT transform found *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000009732380 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000009726770 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x00000000097da410 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000008fabf50 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000009872820 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x00000000082653e0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000a109800 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000a55d5a0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000affc000 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000b099fe0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000b08cc30 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ac4cb30 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000a8d9230 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000af69580 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000b1e7160 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x0000000008e63b80 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000b8682b0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000b52aa80 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000c346c30 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000c117f90 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000c52c6a0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000cc20a40 *** No accelerated IMDCT transform found No accelerated IMDCT transform found *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000c8a1f00 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ceffae0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000d82fee0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000d5b0cd0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000dc91440 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000dc3c0e0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e339700 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e406820 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e74e650 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e31e600 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e895130 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e699ab0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e9a67c0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000e99d280 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ec8fa30 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ee15430 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000f0b6750 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ee9f210 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000f0feae0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000f9bdde0 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000ec77380 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000fa73940 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000f930570 *** *** glibc detected *** shotwell: free(): invalid pointer: 0x000000000fcf1f70 *** Can i help you more (launch shotwell under gdb ? how ? Regards From roumano at gmail.com Mon Sep 19 19:28:12 2011 From: roumano at gmail.com (Roumano) Date: Mon, 19 Sep 2011 21:28:12 +0200 Subject: [Shotwell] Raw + JPG file in library Message-ID: <1316460492.1512.10.camel@roumano> Hi, It's a already 2 known bug ? On the library, if a pictures it's collection of raw + jpeg - Then the tags will not be export on the picture (of the jpeg only as raw don't support it) even if we select the option export tag to files - Also, if we remove the raw file via external command, shotwell will also remove the jpeg file : can't see this file on shotwell Regards From dougie at highmoor.co.uk Mon Sep 19 19:50:39 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 19 Sep 2011 20:50:39 +0100 Subject: [Shotwell] Things I'm liking about Shotwell Message-ID: <4E779D0F.5020703@highmoor.co.uk> Speed Stability Hovering the mouse over the tag list shows an expanded tag list if the list size exceeds available space As above, but for title Robust handling of exif data ( big problem with f-spot http://www.bluecedar.org.uk/?p=120 ) Fast retrieval based on event/time From armooo at armooo.net Mon Sep 19 21:57:34 2011 From: armooo at armooo.net (Jason Michalski) Date: Mon, 19 Sep 2011 17:57:34 -0400 Subject: [Shotwell] RAW + JPEG priorities Message-ID: Hello, I have been shooting RAW + JPEG with a D90 and have my default developer set to camera using Shotwell 0.11.1. When importing my photos the two versions are being correctly grouped. Unfortunately the embedded preview from the RAW is being displayed and used for sharing and publishing. This version has the same resolution, but it a lower JPEG quality and lacks exif data. Switching the developer from camera to shotwell and back seems to switch it to using the JPEG. Thanks -- jason $exiv2 -pp DSC_0268.NEF Preview 1: image/tiff, 160x120 pixels, 57600 bytes Preview 2: image/jpeg, 570x375 pixels, 99615 bytes Preview 3: image/jpeg, 4288x2848 pixels, 1817874 bytes $ ls DSC_0268* DSC_0268.NEF DSC_0268_NEF_embedded.jpg DSC_0268_NEF.jpg From jim at yorba.org Mon Sep 19 22:38:57 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 19 Sep 2011 15:38:57 -0700 Subject: [Shotwell] RAW + JPEG priorities In-Reply-To: References: Message-ID: I've been working with RAW+JPEG today and can reproduce this as well. I've reported it at http://redmine.yorba.org/issues/4149 I don't think we'll have time to fix this in 0.11.2. This will most likely be fixed in 0.12. -- Jim On Mon, Sep 19, 2011 at 2:57 PM, Jason Michalski wrote: > Hello, > > I have been shooting RAW + JPEG with a D90 and have my default > developer set to camera using Shotwell 0.11.1. When importing my > photos the two versions are being correctly grouped. Unfortunately the > embedded preview from the RAW is being displayed and used for sharing > and publishing. This version has the same resolution, but it a lower > JPEG quality and lacks exif data. Switching the developer from camera > to shotwell and back seems to switch it to using the JPEG. > > Thanks > > -- jason > > $exiv2 -pp DSC_0268.NEF > Preview 1: image/tiff, 160x120 pixels, 57600 bytes > Preview 2: image/jpeg, 570x375 pixels, 99615 bytes > Preview 3: image/jpeg, 4288x2848 pixels, 1817874 bytes > > $ ls DSC_0268* > DSC_0268.NEF DSC_0268_NEF_embedded.jpg DSC_0268_NEF.jpg > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From roumano at gmail.com Tue Sep 20 05:37:46 2011 From: roumano at gmail.com (Roumano) Date: Tue, 20 Sep 2011 07:37:46 +0200 Subject: [Shotwell] Glibc invalid pointer In-Reply-To: References: <1316460351.1512.9.camel@roumano> Message-ID: <1316497066.1496.10.camel@roumano> Hi, I'm not a gdb expert, but i already have try to run it via gdb I think, No segfault are reported, so the BT fonction is not usefull... I run it twice & don't get the useful information as you can see below. Otherwise, this problem only appear first time i'm launching shotwell (so only on the import phase) & the 'No accelerated IMDCT transform found' seem not be related to this issue (invalid pointer : 50 times , No accelerated IMDCT transform found : 8 times, & on the same sequences) roumano at roumano ~ $ gdb shotwell GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/shotwell...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/shotwell [Thread debugging using libthread_db enabled] [New Thread 0x7fffd9d80700 (LWP 2398)] [New Thread 0x7fffd9378700 (LWP 2399)] [New Thread 0x7fffd8b77700 (LWP 2400)] [New Thread 0x7fffd8376700 (LWP 2401)] [New Thread 0x7fffd7b75700 (LWP 2402)] [New Thread 0x7fffd7374700 (LWP 2403)] [New Thread 0x7fffd6b73700 (LWP 2404)] [New Thread 0x7fffd6372700 (LWP 2405)] [New Thread 0x7fffd5b71700 (LWP 2406)] ** Message: pygobject_register_sinkfunc is deprecated (GstObject) [New Thread 0x7fffd4547700 (LWP 2409)] [New Thread 0x7fffd3d46700 (LWP 2410)] [New Thread 0x7fffd3545700 (LWP 2411)] [New Thread 0x7fffd2d44700 (LWP 2412)] [New Thread 0x7fffd2543700 (LWP 2413)] [New Thread 0x7fffd1d42700 (LWP 2414)] [Thread 0x7fffd1d42700 (LWP 2414) exited] [Thread 0x7fffd3d46700 (LWP 2410) exited] [Thread 0x7fffd4547700 (LWP 2409) exited] [Thread 0x7fffd2543700 (LWP 2413) exited] [Thread 0x7fffd3545700 (LWP 2411) exited] [New Thread 0x7fffd3545700 (LWP 2415)] [New Thread 0x7fffd2543700 (LWP 2416)] [New Thread 0x7fffd4547700 (LWP 2417)] [New Thread 0x7fffd3d46700 (LWP 2418)] [New Thread 0x7fffd1d42700 (LWP 2419)] [New Thread 0x7fffd1541700 (LWP 2420)] [New Thread 0x7fffd0d40700 (LWP 2421)] [Thread 0x7fffd3545700 (LWP 2415) exited] [Thread 0x7fffd3d46700 (LWP 2418) exited] [New Thread 0x7fffd3d46700 (LWP 2426)] [New Thread 0x7fffd3545700 (LWP 2427)] [New Thread 0x7fffcc9d7700 (LWP 2428)] [New Thread 0x7fffcc1d6700 (LWP 2429)] [Thread 0x7fffd1541700 (LWP 2420) exited] [New Thread 0x7fffd1541700 (LWP 2430)] [New Thread 0x7fffcb9d5700 (LWP 2431)] [New Thread 0x7fffcb1d4700 (LWP 2432)] [New Thread 0x7fffca9d3700 (LWP 2433)] [Thread 0x7fffcc9d7700 (LWP 2428) exited] [Thread 0x7fffd3d46700 (LWP 2426) exited] [Thread 0x7fffd3545700 (LWP 2427) exited] [Thread 0x7fffd2543700 (LWP 2416) exited] [New Thread 0x7fffd2543700 (LWP 2438)] [New Thread 0x7fffd3545700 (LWP 2439)] [New Thread 0x7fffcc9d7700 (LWP 2440)] [New Thread 0x7fffd3d46700 (LWP 2441)] *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x000000000521af70 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x0000000005379c40 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x00000000054a0800 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x000000000537de70 *** [Thread 0x7fffcc9d7700 (LWP 2440) exited] [Thread 0x7fffd3545700 (LWP 2439) exited] [Thread 0x7fffd2543700 (LWP 2438) exited] [Thread 0x7fffcc1d6700 (LWP 2429) exited] [Thread 0x7fffca9d3700 (LWP 2433) exited] [Thread 0x7fffd1d42700 (LWP 2419) exited] [Thread 0x7fffcb1d4700 (LWP 2432) exited] [Thread 0x7fffcb9d5700 (LWP 2431) exited] [Thread 0x7fffd0d40700 (LWP 2421) exited] [Thread 0x7fffd4547700 (LWP 2417) exited] [Thread 0x7fffd1541700 (LWP 2430) exited] [New Thread 0x7fffd1541700 (LWP 2446)] [New Thread 0x7fffd4547700 (LWP 2447)] [New Thread 0x7fffd0d40700 (LWP 2448)] [New Thread 0x7fffcb9d5700 (LWP 2449)] [New Thread 0x7fffd3545700 (LWP 2450)] [New Thread 0x7fffd2543700 (LWP 2451)] [New Thread 0x7fffcc5e1700 (LWP 2457)] [New Thread 0x7fffcb1d4700 (LWP 2458)] [New Thread 0x7fffc9ed6700 (LWP 2459)] [New Thread 0x7fffc8e8f700 (LWP 2460)] [New Thread 0x7fffc868e700 (LWP 2461)] [Thread 0x7fffc8e8f700 (LWP 2460) exited] [Thread 0x7fffcb1d4700 (LWP 2458) exited] [Thread 0x7fffc9ed6700 (LWP 2459) exited] [Thread 0x7fffcc5e1700 (LWP 2457) exited] [Thread 0x7fffd1541700 (LWP 2446) exited] [Thread 0x7fffcb9d5700 (LWP 2449) exited] [Thread 0x7fffd0d40700 (LWP 2448) exited] [Thread 0x7fffd3545700 (LWP 2450) exited] [Thread 0x7fffd2543700 (LWP 2451) exited] [Thread 0x7fffd4547700 (LWP 2447) exited] [Thread 0x7fffd3d46700 (LWP 2441) exited] [New Thread 0x7fffd3d46700 (LWP 2462)] [New Thread 0x7fffd4547700 (LWP 2463)] [New Thread 0x7fffd2543700 (LWP 2464)] [New Thread 0x7fffd3545700 (LWP 2465)] [New Thread 0x7fffd1548700 (LWP 2466)] [New Thread 0x7fffd0d47700 (LWP 2467)] ^Z Program received signal SIGTSTP, Stopped (user). 0x00007ffff522eb41 in ?? () from /usr/lib/libpango-1.0.so.0 (gdb) bt #0 0x00007ffff522eb41 in ?? () from /usr/lib/libpango-1.0.so.0 #1 0x00007ffff5234286 in pango_layout_get_iter () from /usr/lib/libpango-1.0.so.0 #2 0x00007ffff52394b4 in pango_renderer_draw_layout () from /usr/lib/libpango-1.0.so.0 #3 0x00007ffff5c18bf8 in ?? () from /usr/lib/libpangocairo-1.0.so.0 #4 0x0000000000599292 in checkerboard_item_paint () #5 0x00000000005997a5 in ?? () #6 0x00007ffff6211518 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x00007ffff4caf2aa in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #8 0x00007ffff4cc5363 in ?? () from /usr/lib/libgobject-2.0.so.0 #9 0x00007ffff4cc6a2c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #10 0x00007ffff4cc71a3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #11 0x00007ffff6327bff in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x00007ffff620aca6 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x00007ffff5e64ff2 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #14 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #15 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #16 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #17 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #18 0x00007ffff5e61abb in ?? () from /usr/lib/libgdk-x11-2.0.so.0 ---Type to continue, or q to quit---q Quit (gdb) roumano at roumano ~ $ gdb shotwell GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/shotwell...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/shotwell [Thread debugging using libthread_db enabled] [New Thread 0x7fffd9d80700 (LWP 2492)] [New Thread 0x7fffd9378700 (LWP 2493)] [New Thread 0x7fffd8b77700 (LWP 2494)] [New Thread 0x7fffd8376700 (LWP 2495)] [New Thread 0x7fffd7b75700 (LWP 2496)] [New Thread 0x7fffd7374700 (LWP 2497)] [New Thread 0x7fffd6b73700 (LWP 2498)] [New Thread 0x7fffd6372700 (LWP 2499)] [New Thread 0x7fffd5b71700 (LWP 2500)] [New Thread 0x7fffd4547700 (LWP 2501)] [New Thread 0x7fffd3d46700 (LWP 2502)] [New Thread 0x7fffd3545700 (LWP 2503)] [New Thread 0x7fffd2d44700 (LWP 2504)] [New Thread 0x7fffd2543700 (LWP 2505)] [Thread 0x7fffd3545700 (LWP 2503) exited] [Thread 0x7fffd2543700 (LWP 2505) exited] [Thread 0x7fffd2d44700 (LWP 2504) exited] [Thread 0x7fffd3d46700 (LWP 2502) exited] [New Thread 0x7fffd3d46700 (LWP 2507)] [New Thread 0x7fffd2d44700 (LWP 2508)] [New Thread 0x7fffd2543700 (LWP 2509)] [New Thread 0x7fffd3545700 (LWP 2510)] [New Thread 0x7fffd1d42700 (LWP 2511)] [New Thread 0x7fffd1541700 (LWP 2512)] [New Thread 0x7fffd0d40700 (LWP 2513)] [New Thread 0x7fffcd644700 (LWP 2521)] [New Thread 0x7fffcce43700 (LWP 2522)] [New Thread 0x7fffcb985700 (LWP 2524)] [New Thread 0x7fffcb184700 (LWP 2525)] [New Thread 0x7fffca983700 (LWP 2526)] *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x000000000520dea0 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x00000000050ab6e0 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x0000000005277870 *** *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: 0x0000000004906af0 *** [Thread 0x7fffcce43700 (LWP 2522) exited] [Thread 0x7fffcb184700 (LWP 2525) exited] [Thread 0x7fffca983700 (LWP 2526) exited] [Thread 0x7fffcb985700 (LWP 2524) exited] [New Thread 0x7fffcb985700 (LWP 2535)] [New Thread 0x7fffca983700 (LWP 2537)] [New Thread 0x7fffcb184700 (LWP 2538)] [New Thread 0x7fffcce43700 (LWP 2539)] [Thread 0x7fffcb184700 (LWP 2538) exited] [Thread 0x7fffca983700 (LWP 2537) exited] [Thread 0x7fffcd644700 (LWP 2521) exited] [Thread 0x7fffcb985700 (LWP 2535) exited] ^Z Program received signal SIGTSTP, Stopped (user). 0x00007ffff37241f3 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff37241f3 in poll () from /lib64/libc.so.6 #1 0x00007ffff4388fb9 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007ffff4389765 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #3 0x00007ffff620aed7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #4 0x000000000069026c in application_start () #5 0x000000000057e285 in library_exec () #6 0x000000000057ec51 in _vala_main () #7 0x000000000057ee69 in main () (gdb) Le lundi 19 septembre 2011 ? 13:14 -0700, Clinton Rogers a ?crit : > Hi Roumano, > > This does appear to be rather serious, and if we could get more > information from you about how it happens, it might help us fix it. > To run Shotwell from within GDB, please do the following: > 1. From the command line, run 'gdb shotwell'. > 2. After some copyright and debugging information scrolls past, > you should see a prompt that looks like '(gdb)'. At this > prompt, type 'run'. Shotwell should start at this point. > 3. Try performing the operation that triggers the errors below > again. > 4. Once you see the errors start to appear on the console, press > Ctrl+Z. This will temporarily halt Shotwell. > 5. At the '(gdb)' prompt, type 'bt'. This should cause GDB to > display what functions were being called at the time Shotwell > was stopped. You can also type 'continue' to cause Shotwell to > resume. > If you don't mind me asking, was this during import? What kinds of > photos were being imported at the time? The 'No accelerated IMDCT > transform found' messages make me wonder if the problem lies within > libraw. > > Thank you for taking time to report this to us. > > Cheers, > -c > > On Mon, Sep 19, 2011 at 12:25 PM, Roumano wrote: > I using the 0.11.1 version (build by gentoo) on a Gentoo 64 > bits Linux, > > Linux roumano 2.6.39-gentoo-r3 #1 SMP Thu Jul 28 00:50:57 CEST > 2011 > x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel > GNU/Linux > > I see lot of (50 times for 20 000 pictures) these kind > of output > on the > terminal when launch shotwell for the first time (or a > fresh > configuration via mv ~/.xnview{,.old} && shotwell > > Output : > ~ $ shotwell > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000002509c80 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000006b52670 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000006f64890 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000006f9bb80 *** > No accelerated IMDCT transform found > No accelerated IMDCT transform found > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000007a4e400 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000007cb9160 *** > No accelerated IMDCT transform found > No accelerated IMDCT transform found > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000007e13f40 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000007dd3fc0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x00000000088c35d0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x00000000087f7390 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000007c715a0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x00000000076b63b0 *** > No accelerated IMDCT transform found > Failed to play the file: couldn't get state. > No accelerated IMDCT transform found > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000009732380 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000009726770 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x00000000097da410 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000008fabf50 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000009872820 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x00000000082653e0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000a109800 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000a55d5a0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000affc000 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000b099fe0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000b08cc30 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ac4cb30 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000a8d9230 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000af69580 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000b1e7160 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x0000000008e63b80 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000b8682b0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000b52aa80 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000c346c30 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000c117f90 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000c52c6a0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000cc20a40 *** > No accelerated IMDCT transform found > No accelerated IMDCT transform found > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000c8a1f00 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ceffae0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000d82fee0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000d5b0cd0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000dc91440 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000dc3c0e0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e339700 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e406820 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e74e650 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e31e600 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e895130 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e699ab0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e9a67c0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000e99d280 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ec8fa30 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ee15430 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000f0b6750 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ee9f210 *** > > > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000f0feae0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000f9bdde0 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000ec77380 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000fa73940 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000f930570 *** > *** glibc detected *** shotwell: free(): invalid pointer: > 0x000000000fcf1f70 *** > > Can i help you more (launch shotwell under gdb ? how ? > > Regards > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Tue Sep 20 08:57:42 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 20 Sep 2011 09:57:42 +0100 Subject: [Shotwell] (more) things I'm liking about Shotwell In-Reply-To: <4E779D0F.5020703@highmoor.co.uk> References: <4E779D0F.5020703@highmoor.co.uk> Message-ID: <4E785586.4060601@highmoor.co.uk> When I upload to zenfolio (e.g. http://www.fellandforest.co.uk/p1024195889 ), caption (title) and keywords are being detected by Zf. No extra work to do! From progman32 at gmail.com Tue Sep 20 09:31:59 2011 From: progman32 at gmail.com (Giacomo Ferrari) Date: Tue, 20 Sep 2011 02:31:59 -0700 Subject: [Shotwell] Use shotwell DB across multiple machines Message-ID: Hey folks, So count me as another guy trying to get shotwell to work reasonably across 2 machines. I've got my photos directory duplicated on both machines (and sync'd using the Unison file synchronizer). My current setup is just to have shotwell write metadata to files. Tags work great. Events are a real problem, though. Is there any way of exporting events? I've tried copying over photos.db from one machine to the other, but that just results in 90% of my photos ending up in the "missing photos" bin (even though I've pointed shotwell to the proper directory and activated auto-import). The photos that are spared from the "missing photos" bin don't have any membership information, either. Not sure why that is. Is there any way of accomplishing my desired scenario in the current version? If not, are there any new plans to implement library sync (http://redmine.yorba.org/issues/1292) or writing event metadata to the file (http://redmine.yorba.org/issues/3567 or http://redmine.yorba.org/issues/3038)? If not, may I ask why the export of events was not added to the file metadata writer? If the answer is just "time," perhaps I can contribute a patch. Thanks, and great work so far. I can't wait to see 1.0. Giacomo Ferrari From armooo at armooo.net Tue Sep 20 13:11:38 2011 From: armooo at armooo.net (Jason Michalski) Date: Tue, 20 Sep 2011 09:11:38 -0400 Subject: [Shotwell] RAW + JPEG priorities In-Reply-To: References: Message-ID: Thanks I will keep an eye on the bug. -- jason On Mon, Sep 19, 2011 at 6:38 PM, Jim Nelson wrote: > I've been working with RAW+JPEG today and can reproduce this as well.? I've > reported it at http://redmine.yorba.org/issues/4149 > > I don't think we'll have time to fix this in 0.11.2.? This will most likely > be fixed in 0.12. > > -- Jim > > On Mon, Sep 19, 2011 at 2:57 PM, Jason Michalski wrote: >> >> Hello, >> >> I have been shooting RAW + JPEG with a D90 and have my default >> developer set to camera using Shotwell 0.11.1. When importing my >> photos the two versions are being correctly grouped. Unfortunately the >> embedded preview from the RAW is being displayed and used for sharing >> and publishing. This version has the same resolution, but it a lower >> JPEG quality and lacks exif data. Switching the developer from camera >> to shotwell and back seems to switch it to using the JPEG. >> >> Thanks >> >> -- jason >> >> $exiv2 -pp DSC_0268.NEF >> Preview 1: image/tiff, 160x120 pixels, 57600 bytes >> Preview 2: image/jpeg, 570x375 pixels, 99615 bytes >> Preview 3: image/jpeg, 4288x2848 pixels, 1817874 bytes >> >> $ ls ?DSC_0268* >> DSC_0268.NEF ?DSC_0268_NEF_embedded.jpg ?DSC_0268_NEF.jpg >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From clinton at yorba.org Tue Sep 20 19:11:50 2011 From: clinton at yorba.org (Clinton Rogers) Date: Tue, 20 Sep 2011 12:11:50 -0700 Subject: [Shotwell] Use shotwell DB across multiple machines In-Reply-To: References: Message-ID: Good morning Giacomo, On Tue, Sep 20, 2011 at 2:31 AM, Giacomo Ferrari wrote: > Hey folks, > > So count me as another guy trying to get shotwell to work reasonably across > 2 machines. I've got my photos directory duplicated on both machines (and > sync'd using the Unison file synchronizer). My current setup is just to > have > shotwell write metadata to files. Tags work great. Events are a real > problem, though. Is there any way of exporting events? At the moment, not as such. For image files with exposure dates and times in their metadata, events are automatically generated based on those dates and times, and for photos without either incorrect dates or without any exposure timestamp, the user can manually create or move them around, as you know. The trouble is that Shotwell's current design is such that it 'thinks' of the photos that make up an event as properties of the event itself, rather than event membership being a property of each individual photo. Having the event membership get written to each image's metadata as described in http://redmine.yorba.org/issues/3567 would help. > I've tried copying > over photos.db from one machine to the other, but that just results in 90% > of my photos ending up in the "missing photos" bin (even though I've > pointed > shotwell to the proper directory and activated auto-import). The photos > that > are spared from the "missing photos" bin don't have any membership > information, either. When you're using the copied photo.db in its new home, are the images arranged with the same directory structure as on the original machine? I tried manually moving, then putting back already-imported and sorted photos on this machine and it worked, so it seems like this should work across machines as long as the directory structure is the same. One thing to remember here is that photo.db stores image fully-qualified file names, rather than just relative to the user's home. So it would work for me moving from my work machine's Fedora install to the Ubuntu one (in both cases, the path to my home is /home/clinton), but it would break on my home machine (/home/gp2xdev). > Is there any way of accomplishing > my desired scenario in the current version? If not, are there any new plans > to implement library sync (http://redmine.yorba.org/issues/1292) or > writing > event metadata to the file (http://redmine.yorba.org/issues/3567 or > http://redmine.yorba.org/issues/3038)? > I don't believe any of these have been timetabled yet, but the capability to move or sync one's Shotwell-managed photo library between multiple computers is one of the most frequently-requested capabilities that we don't have yet, as you're no doubt aware, so it is a priority, and we do hope to implement this soon. > > If not, may I ask why the export of events was not added to the file > metadata writer? If the answer is just "time," perhaps I can contribute a > patch. > If you'd like to try your hand at this, we'd be happy to review your patch. > Thanks, and great work so far. I can't wait to see 1.0. > > We're glad you like it. Thanks for taking time to write to us! Cheers, -c From clanlaw at googlemail.com Tue Sep 20 19:31:45 2011 From: clanlaw at googlemail.com (Colin Law) Date: Tue, 20 Sep 2011 20:31:45 +0100 Subject: [Shotwell] Use shotwell DB across multiple machines In-Reply-To: References: Message-ID: On 20 September 2011 10:31, Giacomo Ferrari wrote: > Hey folks, > > So count me as another guy trying to get shotwell to work reasonably across > 2 machines. I've got my photos directory duplicated on both machines (and > sync'd using the Unison file synchronizer). My current setup is just to have > shotwell write metadata to files. Tags work great. Events are a real > problem, though. Is there any way of exporting events? I've tried copying > over photos.db from one machine to the other, but that just results in 90% > of my photos ending up in the "missing photos" bin (even though I've pointed > shotwell to the proper directory and activated auto-import). The photos that > are spared from the "missing photos" bin don't have any membership > information, either. Not sure why that is. Is there any way of accomplishing > my desired scenario in the current version? If not, are there any new plans > to implement library sync (http://redmine.yorba.org/issues/1292) or writing > event metadata to the file (http://redmine.yorba.org/issues/3567 or > http://redmine.yorba.org/issues/3038)? As discussed in a previous thread I have absolutely no problems with this, by copying the pictures directory and the whole .shotwell directory. As Clinton has pointed out, however, this does require the same directory structure on the two machines. Colin From jim at yorba.org Tue Sep 20 21:24:16 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 20 Sep 2011 14:24:16 -0700 Subject: [Shotwell] (more) things I'm liking about Shotwell In-Reply-To: <4E785586.4060601@highmoor.co.uk> References: <4E779D0F.5020703@highmoor.co.uk> <4E785586.4060601@highmoor.co.uk> Message-ID: Thanks for noticing all this, Dougie! We appreciate it. -- Jim On Tue, Sep 20, 2011 at 1:57 AM, Dougie Nisbet wrote: > When I upload to zenfolio (e.g. http://www.fellandforest.co.** > uk/p1024195889 ), caption > (title) and keywords are being detected by Zf. No extra work to do! > > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From clinton at yorba.org Tue Sep 20 21:59:11 2011 From: clinton at yorba.org (Clinton Rogers) Date: Tue, 20 Sep 2011 14:59:11 -0700 Subject: [Shotwell] Glibc invalid pointer In-Reply-To: <1316497066.1496.10.camel@roumano> References: <1316460351.1512.9.camel@roumano> <1316497066.1496.10.camel@roumano> Message-ID: Hi again, If you saw those errors only during the initial import and you were importing either camera raw images or videos at the time, and did not get a full crash as a result of them, there's an excellent chance that they're not cause for alarm, but rather something like http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ#When-I-run-Shotwell-I-see-funny-messages-on-the-console . IMDCT is short for inverse modified discrete cosine transform; it's one of several math operations commonly used in signal processing, most notably video compression. Most likely, one of the libraries we use encountered something it didn't quite like, but could recover from, while creating thumbnails of your images and/or videos, and printed out some debug output about it. If, when you use Shotwell, it works normally and all your files look like they should, then this is probably what happened, and, again, there's most likely no need to worry about them. As for how to correct it, it may be that some of the libraries we rely on are configured and compiled slightly differently on Gentoo, resulting in seemingly-unusual error messages; it may be helpful to take a look at how Shotwell's dependencies were built. I hope this helps, but if you have any other questions, please feel free to write again; every bit of feedback we get helps us make our software that much better. Cheers, -c On Mon, Sep 19, 2011 at 10:37 PM, Roumano wrote: > Hi, > > I'm not a gdb expert, but i already have try to run it via gdb > I think, No segfault are reported, so the BT fonction is not > usefull... > > I run it twice & don't get the useful information as you can see below. > > Otherwise, this problem only appear first time i'm launching shotwell > (so only on the import phase) & the 'No accelerated IMDCT transform > found' seem not be related to this issue (invalid pointer : 50 times , > No accelerated IMDCT transform found : 8 times, & on the same sequences) > > > > > roumano at roumano ~ $ gdb shotwell > GNU gdb (Gentoo 7.2 p1) 7.2 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/bin/shotwell...(no debugging symbols > found)...done. > (gdb) run > Starting program: /usr/bin/shotwell > [Thread debugging using libthread_db enabled] > [New Thread 0x7fffd9d80700 (LWP 2398)] > [New Thread 0x7fffd9378700 (LWP 2399)] > [New Thread 0x7fffd8b77700 (LWP 2400)] > [New Thread 0x7fffd8376700 (LWP 2401)] > [New Thread 0x7fffd7b75700 (LWP 2402)] > [New Thread 0x7fffd7374700 (LWP 2403)] > [New Thread 0x7fffd6b73700 (LWP 2404)] > [New Thread 0x7fffd6372700 (LWP 2405)] > [New Thread 0x7fffd5b71700 (LWP 2406)] > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > [New Thread 0x7fffd4547700 (LWP 2409)] > [New Thread 0x7fffd3d46700 (LWP 2410)] > [New Thread 0x7fffd3545700 (LWP 2411)] > [New Thread 0x7fffd2d44700 (LWP 2412)] > [New Thread 0x7fffd2543700 (LWP 2413)] > [New Thread 0x7fffd1d42700 (LWP 2414)] > [Thread 0x7fffd1d42700 (LWP 2414) exited] > [Thread 0x7fffd3d46700 (LWP 2410) exited] > [Thread 0x7fffd4547700 (LWP 2409) exited] > [Thread 0x7fffd2543700 (LWP 2413) exited] > [Thread 0x7fffd3545700 (LWP 2411) exited] > [New Thread 0x7fffd3545700 (LWP 2415)] > [New Thread 0x7fffd2543700 (LWP 2416)] > [New Thread 0x7fffd4547700 (LWP 2417)] > [New Thread 0x7fffd3d46700 (LWP 2418)] > [New Thread 0x7fffd1d42700 (LWP 2419)] > [New Thread 0x7fffd1541700 (LWP 2420)] > [New Thread 0x7fffd0d40700 (LWP 2421)] > [Thread 0x7fffd3545700 (LWP 2415) exited] > [Thread 0x7fffd3d46700 (LWP 2418) exited] > [New Thread 0x7fffd3d46700 (LWP 2426)] > [New Thread 0x7fffd3545700 (LWP 2427)] > [New Thread 0x7fffcc9d7700 (LWP 2428)] > [New Thread 0x7fffcc1d6700 (LWP 2429)] > [Thread 0x7fffd1541700 (LWP 2420) exited] > [New Thread 0x7fffd1541700 (LWP 2430)] > [New Thread 0x7fffcb9d5700 (LWP 2431)] > [New Thread 0x7fffcb1d4700 (LWP 2432)] > [New Thread 0x7fffca9d3700 (LWP 2433)] > [Thread 0x7fffcc9d7700 (LWP 2428) exited] > [Thread 0x7fffd3d46700 (LWP 2426) exited] > [Thread 0x7fffd3545700 (LWP 2427) exited] > [Thread 0x7fffd2543700 (LWP 2416) exited] > [New Thread 0x7fffd2543700 (LWP 2438)] > [New Thread 0x7fffd3545700 (LWP 2439)] > [New Thread 0x7fffcc9d7700 (LWP 2440)] > [New Thread 0x7fffd3d46700 (LWP 2441)] > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x000000000521af70 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x0000000005379c40 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x00000000054a0800 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x000000000537de70 *** > [Thread 0x7fffcc9d7700 (LWP 2440) exited] > [Thread 0x7fffd3545700 (LWP 2439) exited] > [Thread 0x7fffd2543700 (LWP 2438) exited] > [Thread 0x7fffcc1d6700 (LWP 2429) exited] > [Thread 0x7fffca9d3700 (LWP 2433) exited] > [Thread 0x7fffd1d42700 (LWP 2419) exited] > [Thread 0x7fffcb1d4700 (LWP 2432) exited] > [Thread 0x7fffcb9d5700 (LWP 2431) exited] > [Thread 0x7fffd0d40700 (LWP 2421) exited] > [Thread 0x7fffd4547700 (LWP 2417) exited] > [Thread 0x7fffd1541700 (LWP 2430) exited] > [New Thread 0x7fffd1541700 (LWP 2446)] > [New Thread 0x7fffd4547700 (LWP 2447)] > [New Thread 0x7fffd0d40700 (LWP 2448)] > [New Thread 0x7fffcb9d5700 (LWP 2449)] > [New Thread 0x7fffd3545700 (LWP 2450)] > [New Thread 0x7fffd2543700 (LWP 2451)] > [New Thread 0x7fffcc5e1700 (LWP 2457)] > [New Thread 0x7fffcb1d4700 (LWP 2458)] > [New Thread 0x7fffc9ed6700 (LWP 2459)] > [New Thread 0x7fffc8e8f700 (LWP 2460)] > [New Thread 0x7fffc868e700 (LWP 2461)] > [Thread 0x7fffc8e8f700 (LWP 2460) exited] > [Thread 0x7fffcb1d4700 (LWP 2458) exited] > [Thread 0x7fffc9ed6700 (LWP 2459) exited] > [Thread 0x7fffcc5e1700 (LWP 2457) exited] > [Thread 0x7fffd1541700 (LWP 2446) exited] > [Thread 0x7fffcb9d5700 (LWP 2449) exited] > [Thread 0x7fffd0d40700 (LWP 2448) exited] > [Thread 0x7fffd3545700 (LWP 2450) exited] > [Thread 0x7fffd2543700 (LWP 2451) exited] > [Thread 0x7fffd4547700 (LWP 2447) exited] > [Thread 0x7fffd3d46700 (LWP 2441) exited] > [New Thread 0x7fffd3d46700 (LWP 2462)] > [New Thread 0x7fffd4547700 (LWP 2463)] > [New Thread 0x7fffd2543700 (LWP 2464)] > [New Thread 0x7fffd3545700 (LWP 2465)] > [New Thread 0x7fffd1548700 (LWP 2466)] > [New Thread 0x7fffd0d47700 (LWP 2467)] > ^Z > Program received signal SIGTSTP, Stopped (user). > 0x00007ffff522eb41 in ?? () from /usr/lib/libpango-1.0.so.0 > (gdb) bt > #0 0x00007ffff522eb41 in ?? () from /usr/lib/libpango-1.0.so.0 > #1 0x00007ffff5234286 in pango_layout_get_iter () > from /usr/lib/libpango-1.0.so.0 > #2 0x00007ffff52394b4 in pango_renderer_draw_layout () > from /usr/lib/libpango-1.0.so.0 > #3 0x00007ffff5c18bf8 in ?? () from /usr/lib/libpangocairo-1.0.so.0 > #4 0x0000000000599292 in checkerboard_item_paint () > #5 0x00000000005997a5 in ?? () > #6 0x00007ffff6211518 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 > #7 0x00007ffff4caf2aa in g_closure_invoke () > from /usr/lib/libgobject-2.0.so.0 > #8 0x00007ffff4cc5363 in ?? () from /usr/lib/libgobject-2.0.so.0 > #9 0x00007ffff4cc6a2c in g_signal_emit_valist () > from /usr/lib/libgobject-2.0.so.0 > #10 0x00007ffff4cc71a3 in g_signal_emit () > from /usr/lib/libgobject-2.0.so.0 > #11 0x00007ffff6327bff in ?? () from /usr/lib/libgtk-x11-2.0.so.0 > #12 0x00007ffff620aca6 in gtk_main_do_event () > from /usr/lib/libgtk-x11-2.0.so.0 > #13 0x00007ffff5e64ff2 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #14 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #15 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #16 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #17 0x00007ffff5e64f9f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #18 0x00007ffff5e61abb in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > ---Type to continue, or q to quit---q > Quit > (gdb) > > > roumano at roumano ~ $ gdb shotwell > GNU gdb (Gentoo 7.2 p1) 7.2 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/bin/shotwell...(no debugging symbols > found)...done. > (gdb) run > Starting program: /usr/bin/shotwell > [Thread debugging using libthread_db enabled] > [New Thread 0x7fffd9d80700 (LWP 2492)] > [New Thread 0x7fffd9378700 (LWP 2493)] > [New Thread 0x7fffd8b77700 (LWP 2494)] > [New Thread 0x7fffd8376700 (LWP 2495)] > [New Thread 0x7fffd7b75700 (LWP 2496)] > [New Thread 0x7fffd7374700 (LWP 2497)] > [New Thread 0x7fffd6b73700 (LWP 2498)] > [New Thread 0x7fffd6372700 (LWP 2499)] > [New Thread 0x7fffd5b71700 (LWP 2500)] > [New Thread 0x7fffd4547700 (LWP 2501)] > [New Thread 0x7fffd3d46700 (LWP 2502)] > [New Thread 0x7fffd3545700 (LWP 2503)] > [New Thread 0x7fffd2d44700 (LWP 2504)] > [New Thread 0x7fffd2543700 (LWP 2505)] > [Thread 0x7fffd3545700 (LWP 2503) exited] > [Thread 0x7fffd2543700 (LWP 2505) exited] > [Thread 0x7fffd2d44700 (LWP 2504) exited] > [Thread 0x7fffd3d46700 (LWP 2502) exited] > [New Thread 0x7fffd3d46700 (LWP 2507)] > [New Thread 0x7fffd2d44700 (LWP 2508)] > [New Thread 0x7fffd2543700 (LWP 2509)] > [New Thread 0x7fffd3545700 (LWP 2510)] > [New Thread 0x7fffd1d42700 (LWP 2511)] > [New Thread 0x7fffd1541700 (LWP 2512)] > [New Thread 0x7fffd0d40700 (LWP 2513)] > [New Thread 0x7fffcd644700 (LWP 2521)] > [New Thread 0x7fffcce43700 (LWP 2522)] > [New Thread 0x7fffcb985700 (LWP 2524)] > [New Thread 0x7fffcb184700 (LWP 2525)] > [New Thread 0x7fffca983700 (LWP 2526)] > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x000000000520dea0 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x00000000050ab6e0 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x0000000005277870 *** > *** glibc detected *** /usr/bin/shotwell: free(): invalid pointer: > 0x0000000004906af0 *** > [Thread 0x7fffcce43700 (LWP 2522) exited] > [Thread 0x7fffcb184700 (LWP 2525) exited] > [Thread 0x7fffca983700 (LWP 2526) exited] > [Thread 0x7fffcb985700 (LWP 2524) exited] > [New Thread 0x7fffcb985700 (LWP 2535)] > [New Thread 0x7fffca983700 (LWP 2537)] > [New Thread 0x7fffcb184700 (LWP 2538)] > [New Thread 0x7fffcce43700 (LWP 2539)] > [Thread 0x7fffcb184700 (LWP 2538) exited] > [Thread 0x7fffca983700 (LWP 2537) exited] > [Thread 0x7fffcd644700 (LWP 2521) exited] > [Thread 0x7fffcb985700 (LWP 2535) exited] > ^Z > Program received signal SIGTSTP, Stopped (user). > 0x00007ffff37241f3 in poll () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff37241f3 in poll () from /lib64/libc.so.6 > #1 0x00007ffff4388fb9 in ?? () from /usr/lib/libglib-2.0.so.0 > #2 0x00007ffff4389765 in g_main_loop_run () > from /usr/lib/libglib-2.0.so.0 > #3 0x00007ffff620aed7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #4 0x000000000069026c in application_start () > #5 0x000000000057e285 in library_exec () > #6 0x000000000057ec51 in _vala_main () > #7 0x000000000057ee69 in main () > (gdb) > > > Le lundi 19 septembre 2011 ? 13:14 -0700, Clinton Rogers a ?crit : > > Hi Roumano, > > > > This does appear to be rather serious, and if we could get more > > information from you about how it happens, it might help us fix it. > > To run Shotwell from within GDB, please do the following: > > 1. From the command line, run 'gdb shotwell'. > > 2. After some copyright and debugging information scrolls past, > > you should see a prompt that looks like '(gdb)'. At this > > prompt, type 'run'. Shotwell should start at this point. > > 3. Try performing the operation that triggers the errors below > > again. > > 4. Once you see the errors start to appear on the console, press > > Ctrl+Z. This will temporarily halt Shotwell. > > 5. At the '(gdb)' prompt, type 'bt'. This should cause GDB to > > display what functions were being called at the time Shotwell > > was stopped. You can also type 'continue' to cause Shotwell to > > resume. > > If you don't mind me asking, was this during import? What kinds of > > photos were being imported at the time? The 'No accelerated IMDCT > > transform found' messages make me wonder if the problem lies within > > libraw. > > > > Thank you for taking time to report this to us. > > > > Cheers, > > -c > > > > On Mon, Sep 19, 2011 at 12:25 PM, Roumano wrote: > > I using the 0.11.1 version (build by gentoo) on a Gentoo 64 > > bits Linux, > > > > Linux roumano 2.6.39-gentoo-r3 #1 SMP Thu Jul 28 00:50:57 CEST > > 2011 > > x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel > > GNU/Linux > > > > I see lot of (50 times for 20 000 pictures) these kind > > of output > > on the > > terminal when launch shotwell for the first time (or a > > fresh > > configuration via mv ~/.xnview{,.old} && shotwell > > > > Output : > > ~ $ shotwell > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000002509c80 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000006b52670 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000006f64890 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000006f9bb80 *** > > No accelerated IMDCT transform found > > No accelerated IMDCT transform found > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000007a4e400 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000007cb9160 *** > > No accelerated IMDCT transform found > > No accelerated IMDCT transform found > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000007e13f40 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000007dd3fc0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x00000000088c35d0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x00000000087f7390 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000007c715a0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x00000000076b63b0 *** > > No accelerated IMDCT transform found > > Failed to play the file: couldn't get state. > > No accelerated IMDCT transform found > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000009732380 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000009726770 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x00000000097da410 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000008fabf50 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000009872820 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x00000000082653e0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000a109800 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000a55d5a0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000affc000 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000b099fe0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000b08cc30 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ac4cb30 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000a8d9230 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000af69580 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000b1e7160 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x0000000008e63b80 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000b8682b0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000b52aa80 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000c346c30 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000c117f90 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000c52c6a0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000cc20a40 *** > > No accelerated IMDCT transform found > > No accelerated IMDCT transform found > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000c8a1f00 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ceffae0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000d82fee0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000d5b0cd0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000dc91440 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000dc3c0e0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e339700 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e406820 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e74e650 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e31e600 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e895130 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e699ab0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e9a67c0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000e99d280 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ec8fa30 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ee15430 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000f0b6750 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ee9f210 *** > > > > > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000f0feae0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000f9bdde0 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000ec77380 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000fa73940 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000f930570 *** > > *** glibc detected *** shotwell: free(): invalid pointer: > > 0x000000000fcf1f70 *** > > > > Can i help you more (launch shotwell under gdb ? how ? > > > > Regards > > > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > From lucas at yorba.org Tue Sep 20 22:25:17 2011 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 20 Sep 2011 15:25:17 -0700 Subject: [Shotwell] Shotwell 0.11.2 Released! Message-ID: Yorba has just released Shotwell 0.11.2, a bug-fix release. We recommend that all users upgrade. Features of this release include: * Improved stability working with hierarchical tags * Importing hierarchical tags from F-Spot doesn't generate duplicate top-level tags * Fixed "server redirect contained no session key" errors in the Facebook Connector * Corrected problems with item counts over mixed media * Various small fixes and enhancements Download a source tarball from the Shotwell home page at: http://www.yorba.org/shotwell/ Binaries for Ubuntu Natty is available at Yorba?s Launchpad PPA: https://launchpad.net/~yorba/+archive/ppa From dougie at highmoor.co.uk Wed Sep 21 07:35:48 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 21 Sep 2011 08:35:48 +0100 Subject: [Shotwell] crash on f-spot import (0.11.2) Message-ID: <4E7993D4.3080904@highmoor.co.uk> I've just installed the newest shotwell and decided to start-over and get it to import my f-spot database. Things looked ok during the 'Preparing' stage, then when the import itself began shotwell crashed. This is what appeared on the terminal: Error: Directory Canon: Next pointer is out of bounds; ignored. XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. Error: Directory Canon: Next pointer is out of bounds; ignored. Error: Directory Canon: Next pointer is out of bounds; ignored. Error: Directory Canon: Next pointer is out of bounds; ignored. ** ERROR:hashmap.c:2280:gee_hash_map_node_iterator_next: assertion failed: (self->_stamp == self->_map->priv->_stamp) Aborted dougie at phoenix ~ $ The images it appears to have failed on (I've kept a copy of ~/.cache/shotwell.log too if that's any help) look like very old scanned photos that probably have dodgy exif data. Dougie From dougie at highmoor.co.uk Wed Sep 21 09:41:27 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 21 Sep 2011 10:41:27 +0100 Subject: [Shotwell] crash on f-spot import (0.11.2) In-Reply-To: <4E7993D4.3080904@highmoor.co.uk> References: <4E7993D4.3080904@highmoor.co.uk> Message-ID: <4E79B147.3050505@highmoor.co.uk> On 21/09/2011 08:35, Dougie Nisbet wrote: > Things looked ok during the 'Preparing' stage, then when the import > itself began shotwell crashed. While trying to get more information about this crash I decided to try and do a clean re-install of shotwell. Despite clearing out everything that looked like it might be relevant and rebooting the 'import to' setting in Preferences persisted. i.e. It is set to /images (which is what I want, but for simplicity I was trying for a clean install). It's been bugging me where this is being stored and I've noticed on the output (with debug set) the following line: L 25045 2011-09-21 10:26:33 [DBG] LibraryWindow.vala:295: on_library_monitor_installed: /images I've pasted the full log below but the line above would suggest to me that the import to destination of '/images' is being stored somewhere. I just can't find where. As for the crash, I've tried removing some suspect photos from f-spot, and unchecking 'Write metadata to file' in shotwell, but the crash persists. It doesn't seem to be consistent where it crashes. Dougie L 25045 2011-09-21 10:26:32 [MSG] main.vala:416: Shotwell Photo Manager 0.11.2 L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:313: Searching /home/dougie/.gnome2/shotwell/plugins for plugins ... L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:135: Unable to search directory /home/dougie/.gnome2/shotwell/plugins for plugins: No such file or directory L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:313: Searching /usr/local/lib/shotwell/plugins for plugins ... L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:313: Searching /usr/local/lib/shotwell/plugins/builtin for plugins ... L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:421: Loaded SPIT module "Core Slideshow Transitions 0.11.2" (org.yorba.shotwell.transitions) [/usr/local/lib/shotwell/plugins/builtin/shotwell-transitions.so] L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:421: Loaded SPIT module "Core Publishing Services 0.11.2" (org.yorba.shotwell.publishing.core_services) [/usr/local/lib/shotwell/plugins/builtin/shotwell-publishing.so] L 25045 2011-09-21 10:26:33 [DBG] shotwell-publishing-extras.vala:69: bound shotwell-extras language support directory '/usr/local/share/locale'. L 25045 2011-09-21 10:26:33 [DBG] Plugins.vala:421: Loaded SPIT module "Shotwell Extra Publishing Services 0.11.2" (org.yorba.shotwell.publishing.extras) [/usr/local/lib/shotwell/plugins/builtin/shotwell-publishing-extras.so] L 25045 2011-09-21 10:26:33 [MSG] main.vala:73: Verifying database ... L 25045 2011-09-21 10:26:33 [DBG] Db.vala:40: Database schema version 14 created by app version 0.11.2 L 25045 2011-09-21 10:26:33 [MSG] VideoSupport.vala:329: interpreter state cookie not found; assuming all video thumbnails are out of date L 25045 2011-09-21 10:26:33 [DBG] Upgrades.vala:82: Could not delete mimics: /home/dougie/.shotwell/mimics is not a directory L 25045 2011-09-21 10:26:33 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'DISPLAY_BASIC_PROPERTIES' changed. L 25045 2011-09-21 10:26:33 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'EVENTS_SORT_ASCENDING' changed. L 25045 2011-09-21 10:26:33 [DBG] LibraryWindow.vala:295: on_library_monitor_installed: /images L 25045 2011-09-21 10:26:33 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'SHOW_WELCOME_DIALOG' changed. L 25045 2011-09-21 10:26:33 [DBG] main.vala:224: 0.856115 seconds to Gtk.main() L 25045 2011-09-21 10:26:41 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'BG_COLOR_NAME' changed. L 25045 2011-09-21 10:26:41 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'AUTO_IMPORT_FROM_LIBRARY' changed. L 25045 2011-09-21 10:26:41 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'COMMIT_METADATA_TO_MASTERS' changed. L 25045 2011-09-21 10:26:41 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'DIRECTORY_PATTERN' changed. From dougie at highmoor.co.uk Wed Sep 21 15:05:48 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 21 Sep 2011 16:05:48 +0100 Subject: [Shotwell] Monitoring what shotwell is doing (AKA "has it crashed?" Message-ID: <4E79FD4C.1040801@highmoor.co.uk> Back on 0.11.1 and I am doing some tag housekeeping. I'm not surprised that when I drag a tag hierarchy to the top-level (I assume that's what I'm doing when I drag it onto the TAGS tag), that things go quiet for a while. I've noticed before that the shotwell window greys out when it has a lot to do, and the log file (even with debug on) doesn't really give much away. Sometimes it can take ages (e.g. 40+ minutes) to move a tag bundle and it's only through watching the photos.db file timestamp continually updating that I've assumed that shotwell hasn't crashed. Perhaps a status indicator could help, or is there a command that can be used to watch the database directly? Hang on, it's just come back. This tag tidy-up could take a while .... Dougie From roumano at gmail.com Wed Sep 21 15:13:58 2011 From: roumano at gmail.com (Roumano) Date: Wed, 21 Sep 2011 17:13:58 +0200 Subject: [Shotwell] Monitoring what shotwell is doing (AKA "has it crashed?" In-Reply-To: <4E79FD4C.1040801@highmoor.co.uk> References: <4E79FD4C.1040801@highmoor.co.uk> Message-ID: <1316618038.1531.0.camel@roumano> Hi, It can be usefull, feature already created on the bug tracker : http://redmine.yorba.org/issues/3316 : Suggestion: display a 'please wait' type message if writing tags takes longer than three seconds. Regards Le mercredi 21 septembre 2011 ? 16:05 +0100, Dougie Nisbet a ?crit : > Back on 0.11.1 and I am doing some tag housekeeping. I'm not surprised > that when I drag a tag hierarchy to the top-level (I assume that's what > I'm doing when I drag it onto the TAGS tag), that things go quiet for a > while. I've noticed before that the shotwell window greys out when it > has a lot to do, and the log file (even with debug on) doesn't really > give much away. Sometimes it can take ages (e.g. 40+ minutes) to move a > tag bundle and it's only through watching the photos.db file timestamp > continually updating that I've assumed that shotwell hasn't crashed. > Perhaps a status indicator could help, or is there a command that can be > used to watch the database directly? Hang on, it's just come back. This > tag tidy-up could take a while .... > > Dougie > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From dougie at highmoor.co.uk Wed Sep 21 15:42:36 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 21 Sep 2011 16:42:36 +0100 Subject: [Shotwell] Monitoring what shotwell is doing (AKA "has it crashed?" In-Reply-To: <1316618038.1531.0.camel@roumano> References: <4E79FD4C.1040801@highmoor.co.uk> <1316618038.1531.0.camel@roumano> Message-ID: <4E7A05EC.5050406@highmoor.co.uk> On 21/09/2011 16:13, Roumano wrote: > Hi, > > It can be usefull, feature already created on the bug tracker : > > http://redmine.yorba.org/issues/3316 : Suggestion: display a 'please > wait' type message if writing tags takes longer than three seconds. Thanks Roumano, that's exactly the sort of thing I was thinking of. Dougie From oliver at first.in-berlin.de Wed Sep 21 15:53:22 2011 From: oliver at first.in-berlin.de (oliver) Date: Wed, 21 Sep 2011 17:53:22 +0200 Subject: [Shotwell] Monitoring what shotwell is doing (AKA "has it crashed?" In-Reply-To: <1316618038.1531.0.camel@roumano> References: <4E79FD4C.1040801@highmoor.co.uk> <1316618038.1531.0.camel@roumano> Message-ID: <20110921155321.GB3644@siouxsie> Hello, On Wed, Sep 21, 2011 at 05:13:58PM +0200, Roumano wrote: > Hi, > > It can be usefull, feature already created on the bug tracker : > > http://redmine.yorba.org/issues/3316 : Suggestion: display a 'please > wait' type message if writing tags takes longer than three seconds. [...] Quoted from that link I found: "Currently, it?s possible to add an unlimited number of tags to an image; however, if too many tags are added at once, it can take Shotwell a significant amount of time to process and store them all." This looks like shotwell uses the wrong data structures for the tags... Ciao, Oliver From dougie at highmoor.co.uk Wed Sep 21 16:32:36 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 21 Sep 2011 17:32:36 +0100 Subject: [Shotwell] Monitoring what shotwell is doing (AKA "has it crashed?)" In-Reply-To: <20110921155321.GB3644@siouxsie> References: <4E79FD4C.1040801@highmoor.co.uk> <1316618038.1531.0.camel@roumano> <20110921155321.GB3644@siouxsie> Message-ID: <4E7A11A3.8050109@highmoor.co.uk> On 21/09/11 16:53, oliver wrote: > > [...] > > Quoted from that link I found: > > "Currently, it?s possible to add an unlimited number of tags to an > image; however, if too many tags are added at once, it can take Shotwell > a significant amount of time to process and store them all." > > This looks like shotwell uses the wrong data structures for the tags... > Perhaps it's exacerbated now that shotwell can handle tag hierarchies. So me dragging a tag bundle from one location to another probably results in a large number of tag reassignments. Ironically this is something that f-spot does pretty quickly. I think, from my experience watching the debug output, that it queues lots of things up, so it does them on-the-fly in the background while the user gets on with other stuff. Dougie From hanszorn at xs4all.nl Wed Sep 21 17:18:38 2011 From: hanszorn at xs4all.nl (Hans Zorn) Date: Wed, 21 Sep 2011 19:18:38 +0200 Subject: [Shotwell] =?utf-8?q?Monitoring_what_shotwell_is_doing_=28AKA_=22?= =?utf-8?q?has_it_crashed=3F=22?= In-Reply-To: <20110921155321.GB3644@siouxsie> References: <4E79FD4C.1040801@highmoor.co.uk> <1316618038.1531.0.camel@roumano> <20110921155321.GB3644@siouxsie> Message-ID: <2284ec30f3a6aa3b25272bea56aab115@xs4all.nl> On Wed, 21 Sep 2011 17:53:22 +0200, oliver wrote: > Hello, > > This looks like shotwell uses the wrong data structures for the > tags... That's exactly what I thought, while examining the data structure with a SQLite tool: the tags are stored in an utterly un-normalized way. And we all know that you will pay (with poor performance) for that... Hans Zorn > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From clinton at yorba.org Wed Sep 21 18:47:03 2011 From: clinton at yorba.org (Clinton Rogers) Date: Wed, 21 Sep 2011 11:47:03 -0700 Subject: [Shotwell] crash on f-spot import (0.11.2) In-Reply-To: <4E7993D4.3080904@highmoor.co.uk> References: <4E7993D4.3080904@highmoor.co.uk> Message-ID: Hi Dougie, On Wed, Sep 21, 2011 at 12:35 AM, Dougie Nisbet wrote: > I've just installed the newest shotwell and decided to start-over and get > it to import my f-spot database. Things looked ok during the 'Preparing' > stage, then when the import itself began shotwell crashed. This is what > appeared on the terminal: > > Error: Directory Canon: Next pointer is out of bounds; ignored. > XMP Toolkit error 203: Duplicate property or field node > Warning: Failed to decode XMP metadata. > XMP Toolkit error 203: Duplicate property or field node > Warning: Failed to decode XMP metadata. > XMP Toolkit error 203: Duplicate property or field node > Warning: Failed to decode XMP metadata. > Error: Directory Canon: Next pointer is out of bounds; ignored. > Error: Directory Canon: Next pointer is out of bounds; ignored. > Error: Directory Canon: Next pointer is out of bounds; ignored. > The above errors are most likely from either Exiv2 or libraw; both can complain when they find something in the metadata of an image that they think doesn't quite obey the EXIF or XMP specs. These are harmless, do not affect the pixel data in your images and ordinarily aren't cause for concern. > ** > ERROR:hashmap.c:2280:gee_hash_**map_node_iterator_next: assertion failed: > (self->_stamp == self->_map->priv->_stamp) > Aborted > This, on the other hand, _is_ cause for concern, and we'll begin looking into it on our side. In the meantime, could you try the following? - If you feel comfortable doing so, please send us a copy of your F-Spot database; this may help us reproduce the problem on our side. - As a work-around, can you try temporarily disabling library monitoring, try the F-Spot import again, and let us know if this causes it to behave correctly? Cheers, -c From xavierviader at gmail.com Wed Sep 21 22:18:58 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Thu, 22 Sep 2011 00:18:58 +0200 Subject: [Shotwell] edit JPG instead of RAW Message-ID: Hi, I've all RAW and JPEG files well paired but I'd like to have JPEG file like the main picture, is there any way to do this? For example, I have IMG_1111.JPG and IMG_111.CR2, if I tick in 'View' to see title I realise that in pair pictures i'm looking at CR2 instead of JPG. I'd like to see JPG as I want edit JPG not CR2...could it be possible to say to shotwell to hide CR2 and just show JPG? I hope I'd explained ok...maybe I'm misunderstanding something... thanks xavi From xavierviader at gmail.com Wed Sep 21 22:38:08 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Thu, 22 Sep 2011 00:38:08 +0200 Subject: [Shotwell] Red eyes zoom - suggestion Message-ID: Hi, for futur releases, could it be possible to have zoom while you are applying red eye correction? Now it's quite hard to do it if the red eye is little. thanks xavi From clinton at yorba.org Thu Sep 22 00:17:14 2011 From: clinton at yorba.org (Clinton Rogers) Date: Wed, 21 Sep 2011 17:17:14 -0700 Subject: [Shotwell] Red eyes zoom - suggestion In-Reply-To: References: Message-ID: Hi Xavi, On Wed, Sep 21, 2011 at 3:38 PM, Xavi Viader wrote: > Hi, > for futur releases, could it be possible to have zoom while you are > applying > red eye correction? > > Now it's quite hard to do it if the red eye is little. > As a matter of fact, we feel the same, and as such, there's a ticket to track this; please have a look at http://redmine.yorba.org/issues/3592. Cheers, -c From xavierviader at gmail.com Thu Sep 22 06:40:40 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Thu, 22 Sep 2011 08:40:40 +0200 Subject: [Shotwell] Red eyes zoom - suggestion In-Reply-To: References: Message-ID: Hi Clinton, thanks and sorry for the repeated suggesion. xavi 2011/9/22 Clinton Rogers > Hi Xavi, > > > On Wed, Sep 21, 2011 at 3:38 PM, Xavi Viader wrote: > >> Hi, >> for futur releases, could it be possible to have zoom while you are >> applying >> red eye correction? >> >> Now it's quite hard to do it if the red eye is little. >> > > As a matter of fact, we feel the same, and as such, there's a ticket to > track this; please have a look at http://redmine.yorba.org/issues/3592. > > Cheers, > -c > From xavierviader at gmail.com Thu Sep 22 08:37:12 2011 From: xavierviader at gmail.com (Xavi Viader) Date: Thu, 22 Sep 2011 10:37:12 +0200 Subject: [Shotwell] edit JPG instead of RAW (already tracked) Message-ID: Hi, I've just seen that my "problem" would be sorted out whith this track: "combine/separate RAW+JPEG photos" --> http://redmine.yorba.org/issues/4040 I hope you can implement all feature, including separte option. Sorry to ask something alreade ticketed... xavi 2011/9/22 Xavi Viader > Hi, > I've all RAW and JPEG files well paired but I'd like to have JPEG file like > the main picture, is there any way to do this? > > For example, I have IMG_1111.JPG and IMG_111.CR2, if I tick in 'View' to > see title I realise that in pair pictures i'm looking at CR2 instead of JPG. > > I'd like to see JPG as I want edit JPG not CR2...could it be possible to > say to shotwell to hide CR2 and just show JPG? > > I hope I'd explained ok...maybe I'm misunderstanding something... > > thanks > > xavi > From oliver at first.in-berlin.de Thu Sep 22 11:55:35 2011 From: oliver at first.in-berlin.de (oliver) Date: Thu, 22 Sep 2011 13:55:35 +0200 Subject: [Shotwell] Export menue optimization proposition ("Format") Message-ID: <20110922115535.GB4975@siouxsie> Hello, for the export menue I want to propose the following: Creating a new Item in that menu, with item title "Version of picture". The selectable issues would be "unchanged" and "current", which at the moment are selectable from the "Format" Item. Those items should be removed from Format, and Format only conntain file formats, not state of picture. As default value of Format it would be nice, if it would be the format, that the original file was (so jpeg, if it was jpeg for example, or BMP if it was a BMP-file, ...). Using two seperate Menue items for format and version of the picture, will make these issues independent, and the structure of the menues is "more logical". Ciao, Oliver From clinton at yorba.org Thu Sep 22 23:03:22 2011 From: clinton at yorba.org (Clinton Rogers) Date: Thu, 22 Sep 2011 16:03:22 -0700 Subject: [Shotwell] Red eyes zoom - suggestion In-Reply-To: References: Message-ID: Hi again, On Wed, Sep 21, 2011 at 11:40 PM, Xavi Viader wrote: > Hi Clinton, > thanks and sorry for the repeated suggesion. > Not to worry - hearing from multiple people asking for the same feature can highlight things that our users really want, and as such, helps us know what should be prioritized. Cheers, -c From adam at yorba.org Fri Sep 23 02:02:52 2011 From: adam at yorba.org (Adam Dingle) Date: Fri, 23 Sep 2011 06:02:52 +0400 Subject: [Shotwell] Cropping and Rejections In-Reply-To: <4E77760A.5080102@highmoor.co.uk> References: <4E77760A.5080102@highmoor.co.uk> Message-ID: <4E7BE8CC.5070706@yorba.org> On 09/19/2011 09:04 PM, Dougie Nisbet wrote: > Hi, > > a couple of quick questions. I've checked the bugs and FAQ so > apologies if already answered. > > Cropping: shotwell does the same as f-spot. i.e. It doesn't remember > the last setting for cropping constraint. I usually select 'original > photo', and have to keep selecting it as it's not remembered from > photo to photo. Would it be possible for shotwell to 'remember last > used setting'? Yes - were hoping to fix this for the next Shotwell release (0.12): http://redmine.yorba.org/issues/3566 > > Rejection Tag. Is there a shortcut key for tagging a photo as > rejected? (This isn't much of an issue as I simply want to mark photos > for later deletion, and I can do that using the star system. i.e. "1 > star" means "delete later". The shortcut key is "9". See http://yorba.org/shotwell/help/rating.html . > > Dougie > > PS: Perhaps off-topic, but one of the things I'm missing from f-spot > is the 'straighten' feature. It was very simply. I've tried using > straighten in the gimp and although it's possible it seems a bit > long-winded. I'm fairly sure it's not possible in gthumb. Is there > another editing tool I can use in the meantime (I could use f-spot > itself I suppose) to straighten images as I believe a straighten > facility is in the pipeline for shotwell sometime anyway. Yes - we've already started work on a straighten tool for Shotwell and are planning to complete it for 0.12: http://redmine.yorba.org/issues/61 It actually is possible to straighten images in gThumb starting with version 2.13.2 which appeared a few months ago: http://ftp.gnome.org/pub/GNOME/sources/gthumb/2.13/gthumb-2.13.2.news So you could use either gThumb or GIMP to accomplish this until Shotwell gets its own straighten tool. Cheers - adam From lutimdale at yahoo.com Fri Sep 23 15:06:38 2011 From: lutimdale at yahoo.com (Lu Timdale) Date: Fri, 23 Sep 2011 08:06:38 -0700 (PDT) Subject: [Shotwell] Red eyes zoom - suggestion In-Reply-To: References: Message-ID: <1316790398.84065.YahooMailNeo@web160808.mail.bf1.yahoo.com> While it's good to have zoom, red eyes a lot of the time are NOT round due to eylids.? So the tool as is is frustrating to use.? Also, it`s annoying and slow to have to select each eye separately. Currently, the red eye zoom expects to remove the red from the entire area that is denoted by the circle created with the tool. This is incorrect behaviour. The red eye tool should be smart enough to only apply the correction to the area within the denoted circle that is actually RED.? This is quite simple to do.? Simply make an irregular mask based on a red filter.? Once that is done, take the original image section corresponding to the new mask (a subset of the denoted circular section), and correct the redness.? This makes it quite a lot easier to fix all manner of irregular shapes.? It removes any red from a subsection of the image (leaving other valid red areas... jackets/scarves true).? You really only need to define a range of colour which is considered red to create the irregular mask. This also paves the way to selecting both eyes at the same time, or even using a square area... it will be irrelevant what the shape the user denotes since only the red areas within that shape will be modified.? All red-eye tools I have used before did this at least. In addition, this paves the way for enhancing this to autocorrect red-eye for the entire picture, with one click and not specifying an area at all... the picture is the area that the algorithm would be applied to.? Since this will possibly cause more collisions with other valid red ares, it would likely need to be enhanced.? You simply need to marry the above to eitherto a) face detection to make changes only to anything red on a face b) shape detection to make changes only to anything resembling a series of shapes (circular, oval, partially closed bottom, partially closed top, etc.) Magic. Just my 2 cents. ? Lu Timdale lutimdale at yahoo.com ________________________________ From: Clinton Rogers To: xavierviader at gmail.com Cc: shotwell at lists.yorba.org Sent: Thursday, September 22, 2011 7:03:22 PM Subject: Re: [Shotwell] Red eyes zoom - suggestion Hi again, On Wed, Sep 21, 2011 at 11:40 PM, Xavi Viader wrote: > Hi Clinton, > thanks and sorry for the repeated suggesion. > Not to worry - hearing from multiple people asking for the same feature can highlight things that our users really want, and as such, helps us know what should be prioritized. Cheers, -c _______________________________________________ Shotwell mailing list Shotwell at lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From eric at yorba.org Fri Sep 23 18:57:00 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 23 Sep 2011 11:57:00 -0700 Subject: [Shotwell] Red eyes zoom - suggestion In-Reply-To: <1316790398.84065.YahooMailNeo@web160808.mail.bf1.yahoo.com> References: <1316790398.84065.YahooMailNeo@web160808.mail.bf1.yahoo.com> Message-ID: On Fri, Sep 23, 2011 at 8:06 AM, Lu Timdale wrote: > While it's good to have zoom, red eyes a lot of the time are NOT round due > to eylids. So the tool as is is frustrating to use. Also, it`s annoying > and slow to have to select each eye separately. > > > Currently, the red eye zoom expects to remove the red from the entire area > that is denoted by the circle created with the tool. > > This is incorrect behaviour. > > The red eye tool should be smart enough to only apply the correction to the > area within the denoted circle that is actually RED. This is quite simple > to do. Simply make an irregular mask based on a red filter. Once that is > done, take the original image section corresponding to the new mask (a > subset of the denoted circular section), and correct the redness. This > makes it quite a lot easier to fix all manner of irregular shapes. It > removes any red from a subsection of the image (leaving other valid red > areas... jackets/scarves true). You really only need to define a range of > colour which is considered red to create the irregular mask. > > > This also paves the way to selecting both eyes at the same time, or even > using a square area... it will be irrelevant what the shape the user denotes > since only the red areas within that shape will be modified. All red-eye > tools I have used before did this at least. > > > In addition, this paves the way for enhancing this to autocorrect red-eye > for the entire picture, with one click and not specifying an area at all... > the picture is the area that the algorithm would be applied to. Since this > will possibly cause more collisions with other valid red ares, it would > likely need to be enhanced. You simply need to marry the above to eitherto > > a) face detection to make changes only to anything red on a face > b) shape detection to make changes only to anything resembling a series of > shapes (circular, oval, partially closed bottom, partially closed top, etc.) > Hi Lu, Yes, that would be a huge improvement. Apparently you've brought this issue up in the past since you're mentioned in the ticket: http://redmine.yorba.org/issues/2171 We also have this ticket: http://redmine.yorba.org/issues/549 By the way, we always accept patches for these kinds of things! - Eric From jim at yorba.org Fri Sep 23 19:02:28 2011 From: jim at yorba.org (Jim Nelson) Date: Fri, 23 Sep 2011 12:02:28 -0700 Subject: [Shotwell] =?iso-8859-1?q?question-=B4database_information?= In-Reply-To: References: Message-ID: If you search around the Shotwell mailing list archives (at http://lists.yorba.org/pipermail/shotwell/) you'll see other people who have attempted to do this. Shotwell doesn't have an official feature for copying or syncing libraries between computers. The image files are stored as an absolute path, so those paths must be replicated on your other machine. -- Jim On Mon, Sep 19, 2011 at 3:01 AM, Xavi Viader wrote: > Hi, > > I have a desktop computer where I use mainly shotwell but sometimes I work > (using a share) with my laptop using the same library placement (on the > network, of course). Is it possible to copy shotwell database to my laptop > to don't lose all information done in the main computer? Is shotwell > storing > information by image without path? > > thanks > > xavi > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Fri Sep 23 19:52:40 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Fri, 23 Sep 2011 20:52:40 +0100 Subject: [Shotwell] feature request Message-ID: <4E7CE388.3000200@highmoor.co.uk> I'm enjoying tidying up my tags (each to their own :-) ). It's quite satisfying making order out of chaos. The only frustration is when I need to 'reparent' a tag. My 'Acer' tag bundle seems to have found its way to the top level and it needs to be way-down there under Sapindaceae. At the moment I need to click and drag it all the way down on a slightly terrifying quest hoping that I don't drop it on the way as I overtake a few hundred other tags. Are there any plans to allow an 'edit tag' option where it would be possible to move a tag to a different place in the tag hierarchy? Thanks, Dougie PS: Although there are a few things I'm finding exasperating about shotwell, there is tons more that I'm finding very, very cool. From eric at yorba.org Fri Sep 23 21:17:16 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 23 Sep 2011 14:17:16 -0700 Subject: [Shotwell] feature request In-Reply-To: <4E7CE388.3000200@highmoor.co.uk> References: <4E7CE388.3000200@highmoor.co.uk> Message-ID: On Fri, Sep 23, 2011 at 12:52 PM, Dougie Nisbet wrote: > I'm enjoying tidying up my tags (each to their own :-) ). It's quite > satisfying making order out of chaos. The only frustration is when I need to > 'reparent' a tag. My 'Acer' tag bundle seems to have found its way to the > top level and it needs to be way-down there under Sapindaceae. At the moment > I need to click and drag it all the way down on a slightly terrifying quest > hoping that I don't drop it on the way as I overtake a few hundred other > tags. Are there any plans to allow an 'edit tag' option where it would be > possible to move a tag to a different place in the tag hierarchy? Hi Dougie, Yes, eventually we'll have the ability to edit the entire hierarchical tag path through the edit tags dialog. That should make lives easier for folks who have a lot of tags. We have a ticket on this here: http://redmine.yorba.org/issues/3911 - Eric From adam at yorba.org Fri Sep 23 23:28:15 2011 From: adam at yorba.org (Adam Dingle) Date: Sat, 24 Sep 2011 03:28:15 +0400 Subject: [Shotwell] feature request In-Reply-To: References: <4E7CE388.3000200@highmoor.co.uk> Message-ID: <4E7D160F.5060806@yorba.org> On 09/24/2011 01:17 AM, Eric Gregory wrote: > On Fri, Sep 23, 2011 at 12:52 PM, Dougie Nisbetwrote: > >> I'm enjoying tidying up my tags (each to their own :-) ). It's quite >> satisfying making order out of chaos. The only frustration is when I need to >> 'reparent' a tag. My 'Acer' tag bundle seems to have found its way to the >> top level and it needs to be way-down there under Sapindaceae. At the moment >> I need to click and drag it all the way down on a slightly terrifying quest >> hoping that I don't drop it on the way as I overtake a few hundred other >> tags. Are there any plans to allow an 'edit tag' option where it would be >> possible to move a tag to a different place in the tag hierarchy? > > Hi Dougie, > > Yes, eventually we'll have the ability to edit the entire hierarchical tag > path through the edit tags dialog. That should make lives easier for folks > who have a lot of tags. > > We have a ticket on this here: > http://redmine.yorba.org/issues/3911 Actually I don't see how the changes proposed in that ticket will help with this particular use case: the Edit Tags dialog affects only one photo, and this user wants to move a tag to a new position in the hierarchy. We'd like to make it possible to use the keyboard to move tags in the hierachy (http://redmine.yorba.org/issues/4048). Then you won't have to drag over a large number of tags: you'll be able to select one tag, choose Edit->Copy, then choose a new parent and choose Edit->Paste. adam From dougie at highmoor.co.uk Sat Sep 24 05:49:28 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sat, 24 Sep 2011 06:49:28 +0100 Subject: [Shotwell] feature request In-Reply-To: <4E7D160F.5060806@yorba.org> References: <4E7CE388.3000200@highmoor.co.uk> <4E7D160F.5060806@yorba.org> Message-ID: <4E7D6F68.8060908@highmoor.co.uk> On 24/09/11 00:28, Adam Dingle wrote: > > We'd like to make it possible to use the keyboard to move tags in the > hierachy (http://redmine.yorba.org/issues/4048). Then you won't have > to drag over a large number of tags: you'll be able to select one tag, > choose Edit->Copy, then choose a new parent and choose Edit->Paste. > spot on. Dougie From chrisgame at pobox.com Sat Sep 24 11:42:07 2011 From: chrisgame at pobox.com (Chris Game) Date: Sat, 24 Sep 2011 12:42:07 +0100 (BST) Subject: [Shotwell] Shotwell 0.11.2 Released! In-Reply-To: References: Message-ID: Kudos to the guy who provides updated builds on the OpenSUSE build service (build.opensuse.org), the latest 0.11.2 version was up within a couple of days! No hassle with vala and so on for the rest of us! From conrad.p.dean at gmail.com Sat Sep 24 14:31:40 2011 From: conrad.p.dean at gmail.com (Conrad Dean) Date: Sat, 24 Sep 2011 09:31:40 -0500 Subject: [Shotwell] Non-destructive editing In-Reply-To: <4E768D56.3060807@yorba.org> References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> <4E768D56.3060807@yorba.org> Message-ID: > > I'm not aware of any other GNOME application that persists the undo > hierarchy across sessions, so I don't think that Shotwell needs to either. > The undo mechanism is not intended to allow you to go back and revert > recent changes to individual photos; it simply allows you to, well, undo the > last step that you did globally (just like in other GNOME apps). We could > conceivably modify Shotwell someday to keep track of the order of changes > you've made to each photo and to revert recent changes. But if we do > implement that, the user interface will probably not be through Edit->Undo. > > I apologize if this is a little off topic... but Adobe Lightroom keeps a list of operations performed on a single photo. This lets you play around with your photos and get a particular "look" that you like, and then you can analyze how you got there. While it's neat to play around with the operations themselves, going back into the photo's history, modifying the operations, etc -- the real strength of this feature is you can save the operations as a single batch operation that can be applied to multiple photos in the future, which is useful if you have a large set of photos from a single shoot that all need the same exact color and exposure adjustments made at once. It's also a super intuitive interface for creating your own filters. Probably a superfluous feature, but it's one of those things that makes a user feel in control of their environment and has a huge 'wow-factor'. From andreas.wallberg at gmail.com Sun Sep 25 21:47:26 2011 From: andreas.wallberg at gmail.com (Andreas Wallberg) Date: Sun, 25 Sep 2011 23:47:26 +0200 Subject: [Shotwell] Feature request: arbitrary tag as badge Message-ID: Hi all! Let me start off by giving the all devs a big hug! I truly adore this program and use it to happily manage a collection of 30.000+ photos :-) I have a feature request (which may have been requested before, but, heck here it goes again if so): would it be possible to show a tag as a small badge somewhere on top of a picture using a previously determined icon for that particular tag, similar to the way stars are shown when pictures are rated. The list of keywords under a picture can oftentimes be too long to be shown in its entirety and some tags may be more important than others. This "necklace of badges" should preferably be possible to a toggle between show/hide states. There are many uses for this. I have a specific use case as an example for when this would be very helpful, namely to tag a picture as "Published", which would help me know which images I have selected for my own photo blog. Come to think of it, perhaps adding such a badge automatically when pictures are published through Shotwell itself, such as on facebook, would generally be helpful to many. In the case of facebook, a small blue facebook-icon would indicate that a picture had been sent to facebook. I had a look at the requests in the tracker but did not see something along these lines. Moreover, I would prefer some refining feedback on this idea before turning it into a "proper" feature request in the tracker. What is everyones thoughts on this one? Best regards, Andreas From adam at yorba.org Mon Sep 26 00:41:42 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 26 Sep 2011 04:41:42 +0400 Subject: [Shotwell] Feature request: arbitrary tag as badge In-Reply-To: References: Message-ID: <4E7FCA46.6030902@yorba.org> On 09/26/2011 01:47 AM, Andreas Wallberg wrote: > would it be possible to show a tag as > a small badge somewhere on top of a picture using a previously > determined icon for that particular tag, similar to the way stars are > shown when pictures are rated. The list of keywords under a picture > can oftentimes be too long to be shown in its entirety and some tags > may be more important than others. This "necklace of badges" should > preferably be possible to a toggle between show/hide states. > > There are many uses for this. I have a specific use case as an example > for when this would be very helpful, namely to tag a picture as > "Published", which would help me know which images I have selected for > my own photo blog. Come to think of it, perhaps adding such a badge > automatically when pictures are published through Shotwell itself, > such as on facebook, would generally be helpful to many. In the case > of facebook, a small blue facebook-icon would indicate that a picture > had been sent to facebook. Thanks for the suggestion, Andreas. Some other photo programs (e.g. F-Spot) have this feature. I think we may as well create a ticket for this now, so I made one: http://redmine.yorba.org/issues/4182 We can discuss this idea further on that ticket. Cheers - adam From monnier at iro.umontreal.ca Mon Sep 26 03:23:59 2011 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Sun, 25 Sep 2011 23:23:59 -0400 Subject: [Shotwell] Sharing a photo collection between machines Message-ID: Do people have experience sharing a photo collection between different machines? Of course, I could use a network file system, but I'd rather not since some of those machines may not always be connected to the Internet or to each other. Also, I'd like to be able to apply modifications from any machine, so I don't want to just declare one of the machines as the master and all others end up having only a read-only mirror. Maybe sharing via Git could be made to work? Other thoughts? Stefan From alex at ourwoods.org Mon Sep 26 03:26:57 2011 From: alex at ourwoods.org (Alex Janssen) Date: Sun, 25 Sep 2011 23:26:57 -0400 Subject: [Shotwell] EXIF data contained in JPEG image files Message-ID: <4E7FF101.9050109@ourwoods.org> It seems to me that preserving the camera data including the original exposure date would be important to most photographers. If Shotwell should do anything, it should preserve the original data and append that the photo was altered by itself, it should certainly not delete all of the pre-existing data and insert that the picture originated with itself. -- Ourwoods.org Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin (391) From insomniacpenguin at googlemail.com Mon Sep 26 06:03:42 2011 From: insomniacpenguin at googlemail.com (Andy Stevens) Date: Mon, 26 Sep 2011 07:03:42 +0100 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: <4E7FF101.9050109@ourwoods.org> References: <4E7FF101.9050109@ourwoods.org> Message-ID: Where are you seeing that? Imported pictures, modified,exported (resized or original?), published, ... Andy On 26 Sep 2011 04:27, "Alex Janssen" wrote: > It seems to me that preserving the camera data including the original > exposure date would be important to most photographers. If Shotwell > should do anything, it should preserve the original data and append that > the photo was altered by itself, it should certainly not delete all of > the pre-existing data and insert that the picture originated with itself. > > -- > Ourwoods.org > > Those who would give up essential liberty to purchase a little temporary > safety deserve neither liberty nor safety. - Benjamin Franklin (391) > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From dougie at highmoor.co.uk Mon Sep 26 06:45:15 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 07:45:15 +0100 Subject: [Shotwell] Feature request: arbitrary tag as badge In-Reply-To: References: Message-ID: <4E801F7B.4080506@highmoor.co.uk> On 25/09/2011 22:47, Andreas Wallberg wrote: > I have a feature request (which may have been requested before, but, > heck here it goes again if so): would it be possible to show a tag as > a small badge somewhere on top of a picture using a previously > determined icon for that particular tag, similar to the way stars are > shown when pictures are rated. The list of keywords under a picture > can oftentimes be too long to be shown in its entirety and some tags > may be more important than others. This "necklace of badges" should > preferably be possible to a toggle between show/hide states. Coming from f-spot I missed this too. In f-spot it's a simple toggle to display/edit or hide tags. However, I discovered that in shotwell if the space taken up by tags exceeds the screen real-estate you can get a full list by hovering the mouse-pointer over the tags. The same applies to the title. It's sufficient for me most of the time. Tag management is a bit cumbersome at times and can be long-winded but I assume that it will evolve over time. For example, I'd like to be able to: - select a group of images and right-click to get a list of tags that are common to these images, then be able to remove one. - with the tag list open in the left pane, slick on an image and enter a new tag, with the new tag being added to the tag cloud in the same place in the hierarchy that is open on the tag pane (rather than the top-level). Dougie From dougie at highmoor.co.uk Mon Sep 26 06:49:16 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 07:49:16 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: Message-ID: <4E80206C.5000305@highmoor.co.uk> On 26/09/2011 04:23, Stefan Monnier wrote: > Do people have experience sharing a photo collection between > different machines? The short answer, I believe, is that it is do-able but unsupported. If you look at the archive for this mailing list for this month you should find a few posts by Colin Law where he describes how he's being doing just that. I'm currently trying this out myself but in my case I'm just interested in having a 'read-only' version on my netbook. I use rsync on my images and ~/.shotwell directory although I'm having a couple of strange performance issues that I need to have a look at. Dougie From dougie at highmoor.co.uk Mon Sep 26 06:54:49 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 07:54:49 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: <4E80206C.5000305@highmoor.co.uk> References: <4E80206C.5000305@highmoor.co.uk> Message-ID: <4E8021B9.4060408@highmoor.co.uk> On 26/09/2011 07:49, Dougie Nisbet wrote: > > If you look at the archive for this mailing list for this month you > should find a few posts by Colin Law where he describes how he's being > doing just that. sorry, I've just checked back through the list and see that you commented in the thread I mention, so I assume you're already aware of using rsync. Don't know of any other ways of doing it. Dougie From clanlaw at googlemail.com Mon Sep 26 08:06:33 2011 From: clanlaw at googlemail.com (Colin Law) Date: Mon, 26 Sep 2011 09:06:33 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: <4E8021B9.4060408@highmoor.co.uk> References: <4E80206C.5000305@highmoor.co.uk> <4E8021B9.4060408@highmoor.co.uk> Message-ID: On 26 September 2011 07:54, Dougie Nisbet wrote: > On 26/09/2011 07:49, Dougie Nisbet wrote: >> >> If you look at the archive for this mailing list for this month you should >> find a few posts by Colin Law where he describes how he's being doing just >> that. > > sorry, I've just checked back through the list and see that you commented in > the thread I mention, so I assume you're already aware of using rsync. Don't > know of any other ways of doing it. @OP: You can use any method you like for synchronising the pictures and .shotwell folders. You could simply copy them (which could take a long time) or I think you could use something like Dropbox with symlinks to the folders. rsync is just a very efficient way of doing it. Note that I believe that syncing .shotwell will only work if you have the same directory structure (to the pictures folder) on both machines. You also need the same (or close) versions of shotwell on the two machines. Colin From dougie at highmoor.co.uk Mon Sep 26 09:54:06 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 10:54:06 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> <4E8021B9.4060408@highmoor.co.uk> Message-ID: <4E804BBE.2080009@highmoor.co.uk> On 26/09/2011 09:06, Colin Law wrote: > [ ... ] rsync is just a very efficient way of doing > it. Note that I believe that syncing .shotwell will only work if you > have the same directory structure (to the pictures folder) on both > machines. You also need the same (or close) versions of shotwell on > the two machines. There seems to be something else going on that I can't track down. I'm using the recipe: rsync -rav --stats --delete kitchen:/images/ /images rsync -rav --stats --delete kitchen:/home/dougie/.shotwell/ /home/dougie/.config/shotwell with the same distro (Linux Mint Debian) on both desktop and netbook and with shotwell compiled. What I find is that starting shotwell on the netbook initially looks ok, but shotwell hangs and sits hogging 100% CPU. I wondered if it was a caching thing but I've left it for about an hour and it's unresponsive. My guess is that shotwell has settings stored somewhere else that I need to manually tweak something on the netbook. For instance, on the desktop the log file shows the line: L 16985 2011-09-25 16:24:04 [DBG] LibraryWindow.vala:295: on_library_monitor_installed: /images but on the netbook it shows /Pictures in instead of /images. Settings were mentioned earlier this month by Eric Gregory (they're in GSettings from 0.11 onwards) but I can't figure out how to change them. I've tried an uninstall, reinstall on the netbook and deleted the .shotwell directory to give it a clean start, but shotwell hangs on startup and I can't access any of its menus. I'm guessing there's some other configuration settings somewhere. Dougie From clanlaw at googlemail.com Mon Sep 26 10:06:06 2011 From: clanlaw at googlemail.com (Colin Law) Date: Mon, 26 Sep 2011 11:06:06 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: <4E804BBE.2080009@highmoor.co.uk> References: <4E80206C.5000305@highmoor.co.uk> <4E8021B9.4060408@highmoor.co.uk> <4E804BBE.2080009@highmoor.co.uk> Message-ID: On 26 September 2011 10:54, Dougie Nisbet wrote: > On 26/09/2011 09:06, Colin Law wrote: >> >> ?[ ... ] rsync is just a very efficient way of doing >> it. ?Note that I believe that syncing .shotwell will only work if you >> have the same directory structure (to the pictures folder) on both >> machines. ?You also need the same (or close) versions of shotwell on >> the two machines. > > There seems to be something else going on that I can't track down. I'm using > the recipe: > ? ?rsync -rav --stats --delete kitchen:/images/ /images > ? ?rsync -rav --stats --delete kitchen:/home/dougie/.shotwell/ > /home/dougie/.config/shotwell How is it that you have ~/.config on one and ~/.config/shotwell on the other? Colin > > with the same distro (Linux Mint Debian) on both desktop and netbook and > with shotwell compiled. > > What I find is that starting shotwell on the netbook initially looks ok, but > shotwell hangs and sits hogging 100% CPU. I wondered if it was a caching > thing but I've left it for about an hour and it's unresponsive. > > My guess is that shotwell has settings stored somewhere else that I need to > manually tweak something on the ?netbook. For instance, on the desktop the > log file shows the line: > > ? ?L 16985 2011-09-25 16:24:04 [DBG] LibraryWindow.vala:295: > on_library_monitor_installed: /images > > but on the netbook it shows /Pictures in instead of /images. > > Settings were mentioned earlier this month by Eric Gregory (they're in > GSettings from 0.11 onwards) but I can't figure out how to change them. > > I've tried an uninstall, reinstall on the netbook and deleted the .shotwell > directory to give it a clean start, but shotwell hangs on startup and I > can't access any of its menus. I'm guessing there's some other configuration > settings somewhere. > > Dougie > > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- gplus.to/clanlaw From dougie at highmoor.co.uk Mon Sep 26 11:15:48 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 12:15:48 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> <4E8021B9.4060408@highmoor.co.uk> <4E804BBE.2080009@highmoor.co.uk> Message-ID: <4E805EE4.3070605@highmoor.co.uk> On 26/09/2011 11:06, Colin Law wrote: > How is it that you have ~/.config on one and ~/.config/shotwell on the other? > er, yes, (cough) ahem (blush), that *is* odd isn't it. How come I didn't spot that :( Thanks for debugging my script for me :) Fixing it now, and trying again. Although I'm not sure it would explain shotwell hanging on startup with a clean .shotwell directory. Trying again now. Dougie From monnier at iro.umontreal.ca Mon Sep 26 14:14:49 2011 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 26 Sep 2011 10:14:49 -0400 Subject: [Shotwell] Sharing a photo collection between machines References: <4E80206C.5000305@highmoor.co.uk> Message-ID: >> Do people have experience sharing a photo collection between >> different machines? > The short answer, I believe, is that it is do-able but unsupported. > If you look at the archive for this mailing list for this month you should > find a few posts by Colin Law where he describes how he's being doing > just that. But that doesn't really account for allowing modifications on any machine. It would work OK for mirroring, but if you start making modifications via different machines it quickly becomes hellish to manage with rsync. > I'm currently trying this out myself but in my case I'm just interested in > having a 'read-only' version on my netbook. I use rsync on my images and > ~/.shotwell directory although I'm having a couple of strange performance > issues that I need to have a look at. Mirrors is what I use now. I want better. I even want to be able to make changes concurrently on different machines. Git or Bazaar sound like obvious candidates but the .git repository ends up just as large as the photo collection itself, and doubling the disk space used is not my idea of a good solution (and then we have the problem of the metadata database, of course). Stefan From alex at ourwoods.org Mon Sep 26 15:48:28 2011 From: alex at ourwoods.org (Alex) Date: Mon, 26 Sep 2011 11:48:28 -0400 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: References: <4E7FF101.9050109@ourwoods.org> Message-ID: <4E809ECC.6030506@ourwoods.org> Andy Stevens said the following on 09/26/2011 02:03 AM: > > Where are you seeing that? Imported pictures, modified,exported > (resized or original?), published, ... > > Andy > Now, I feel that I've got egg on my face. I jumped to some conclusions. It only deletes all of the camera data; make, model, ISO, Aperture value, exposure time, exposure program, exposure bias, exposure mode, meter mode, light source, white balance, focal length, contrast, flash, ... It does preserve the original creation date and time, though. I guess, seeing as the pic has been altered and is no longer as the camera created it, Shotwell may be doing the right thing. Although, I'm used to GIMP preserving all of the camera information but the software and date entries. I'd rather Shotwell not delete all the original camera information. Alex -- Alex P Janssen Jr alex at ourwoods.org From joseph.bylund at gmail.com Mon Sep 26 15:57:26 2011 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Mon, 26 Sep 2011 11:57:26 -0400 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: <4E809ECC.6030506@ourwoods.org> References: <4E7FF101.9050109@ourwoods.org> <4E809ECC.6030506@ourwoods.org> Message-ID: <4E80A0E6.2060507@gmail.com> I'm also a little confused on this. I haven't noticed this behavior on import at least. I find a program named exiftool is very useful for looking at what's in there. -Joe On 09/26/2011 11:48 AM, Alex wrote: > Andy Stevens said the following on 09/26/2011 02:03 AM: >> >> Where are you seeing that? Imported pictures, modified,exported >> (resized or original?), published, ... >> >> Andy >> > > Now, I feel that I've got egg on my face. I jumped to some > conclusions. It only deletes all of the camera data; make, model, > ISO, Aperture value, exposure time, exposure program, exposure bias, > exposure mode, meter mode, light source, white balance, focal length, > contrast, flash, ... > It does preserve the original creation date and time, though. > I guess, seeing as the pic has been altered and is no longer as the > camera created it, Shotwell may be doing the right thing. Although, > I'm used to GIMP preserving all of the camera information but the > software and date entries. I'd rather Shotwell not delete all the > original camera information. > > Alex > From dougie at highmoor.co.uk Mon Sep 26 16:15:21 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 17:15:21 +0100 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE Message-ID: <4E80A519.7090701@highmoor.co.uk> I wonder if anyone can help me with this. I'm trying to get shotwell 0.11.2 to run on my netbook. I had it working but then I started experimenting with syncing my desktop shotwell database to the netbook, and things have come a little undone. So in an attempt to get back to a clean base I've uninstalled and deleted anything shotwell'ish from the netbook and tried to compare installed packages on the desktop and the netbook. I'm now in the situation where I've recompiled 0.11.2 from the source tarball on what I believe to be a clean system. However, when I run shotwell, it presents the main screen but then hangs consuming 100% CPU. Here's the output from the shotwell.log L 2484 2011-09-26 17:05:26 [MSG] main.vala:416: Shotwell Photo Manager 0.11.2 L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:313: Searching /home/dougie/.gnome2/shotwell/plugins for plugins ... L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:135: Unable to search directory /home/dougie/.gnome2/shotwell/plugins for plugins: No such file or directory L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:313: Searching /usr/local/lib/shotwell/plugins for plugins ... L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:313: Searching /usr/local/lib/shotwell/plugins/builtin for plugins ... L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:421: Loaded SPIT module "Core Slideshow Transitions 0.11.2" (org.yorba.shotwell.transitions) [/usr/local/lib/shotwell/plugins/builtin/shotwell-transitions.so] L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:421: Loaded SPIT module "Core Publishing Services 0.11.2" (org.yorba.shotwell.publishing.core_services) [/usr/local/lib/shotwell/plugins/builtin/shotwell-publishing.so] L 2484 2011-09-26 17:05:27 [DBG] shotwell-publishing-extras.vala:69: bound shotwell-extras language support directory '/usr/local/share/locale'. L 2484 2011-09-26 17:05:27 [DBG] Plugins.vala:421: Loaded SPIT module "Shotwell Extra Publishing Services 0.11.2" (org.yorba.shotwell.publishing.extras) [/usr/local/lib/shotwell/plugins/builtin/shotwell-publishing-extras.so] L 2484 2011-09-26 17:05:27 [MSG] main.vala:73: Verifying database ... L 2484 2011-09-26 17:05:27 [DBG] Db.vala:40: Database schema version 14 created by app version 0.11.2 L 2484 2011-09-26 17:05:27 [MSG] VideoSupport.vala:329: interpreter state cookie not found; assuming all video thumbnails are out of date L 2484 2011-09-26 17:05:27 [DBG] Upgrades.vala:82: Could not delete mimics: /home/dougie/.shotwell/mimics is not a directory L 2484 2011-09-26 17:05:28 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'DISPLAY_BASIC_PROPERTIES' changed. L 2484 2011-09-26 17:05:28 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'EVENTS_SORT_ASCENDING' changed. L 2484 2011-09-26 17:05:28 [DBG] LibraryWindow.vala:295: on_library_monitor_installed: /home/dougie/Pictures L 2484 2011-09-26 17:05:28 [DBG] ConfigurationInterfaces.vala:283: ConfigurationFacade: engine reports property 'SHOW_WELCOME_DIALOG' changed. L 2484 2011-09-26 17:05:28 [DBG] main.vala:224: 1.260489 seconds to Gtk.main() From alex at ourwoods.org Mon Sep 26 16:44:13 2011 From: alex at ourwoods.org (Alex) Date: Mon, 26 Sep 2011 12:44:13 -0400 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: <4E80A0E6.2060507@gmail.com> References: <4E7FF101.9050109@ourwoods.org> <4E809ECC.6030506@ourwoods.org> <4E80A0E6.2060507@gmail.com> Message-ID: <4E80ABDD.7090905@ourwoods.org> Joseph Bylund said the following on 09/26/2011 11:57 AM: > I'm also a little confused on this. I haven't noticed this behavior > on import at least. I find a program named exiftool is very useful > for looking at what's in there. > > -Joe The only time I've noticed it was in saving after making initial crop and color adjustments. Alex -- alex at ourwoods.org From dougie at highmoor.co.uk Mon Sep 26 17:45:02 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 18:45:02 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) Message-ID: <4E80BA1E.90202@highmoor.co.uk> ouch. Just noticed this was happening. observation 1; create a tag, e.g. 'testtag1'. Do not assign it to any photographs. Exit and restart shotwell. The tag has disappeared. observation 2; create two tags, the 2nd tag being the same as the first one, but with information in brackets. e.g. testtag1 testtag1 (test string1) assign photos to both tags. It doesn't matter if they are the same photos. delete testtag1 testtag1 (test string1) is also deleted. Dougie From jim at yorba.org Mon Sep 26 18:27:16 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 26 Sep 2011 11:27:16 -0700 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: <4E80ABDD.7090905@ourwoods.org> References: <4E7FF101.9050109@ourwoods.org> <4E809ECC.6030506@ourwoods.org> <4E80A0E6.2060507@gmail.com> <4E80ABDD.7090905@ourwoods.org> Message-ID: Are you using Shotwell in direct-edit mode (that is, you right-clicked on a photo file and chose "Open with Shotwell")? -- Jim On Mon, Sep 26, 2011 at 9:44 AM, Alex wrote: > Joseph Bylund said the following on 09/26/2011 11:57 AM: > > I'm also a little confused on this. I haven't noticed this behavior on >> import at least. I find a program named exiftool is very useful for looking >> at what's in there. >> >> -Joe >> > The only time I've noticed it was in saving after making initial crop and > color adjustments. > > Alex > > -- > alex at ourwoods.org > > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From eric at yorba.org Mon Sep 26 18:40:10 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 11:40:10 -0700 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: <4E80BA1E.90202@highmoor.co.uk> References: <4E80BA1E.90202@highmoor.co.uk> Message-ID: On Mon, Sep 26, 2011 at 10:45 AM, Dougie Nisbet wrote: > ouch. Just noticed this was happening. > > observation 1; create a tag, e.g. 'testtag1'. Do not assign it to any > photographs. Exit and restart shotwell. The tag has disappeared. > While users may not expect this behavior, it's what we decided on at some point. Shotwell considers tags to be associated with photos, no the other way around -- for this reason it didn't make sense to use to let empty tags persist across Shotwell sessions. > observation 2; create two tags, the 2nd tag being the same as the first > one, but with information in brackets. e.g. > > testtag1 > testtag1 (test string1) > > assign photos to both tags. It doesn't matter if they are the same photos. > > delete testtag1 > > testtag1 (test string1) is also deleted. > I can't replicate this bug. Is there something more that needs to be done to re-create this? Also, which version of Shotwell are you using? - Eric From eric at yorba.org Mon Sep 26 18:49:12 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 11:49:12 -0700 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: <4E80A519.7090701@highmoor.co.uk> References: <4E80A519.7090701@highmoor.co.uk> Message-ID: On Mon, Sep 26, 2011 at 9:15 AM, Dougie Nisbet wrote: > I wonder if anyone can help me with this. I'm trying to get shotwell 0.11.2 > to run on my netbook. I had it working but then I started experimenting with > syncing my desktop shotwell database to the netbook, and things have come a > little undone. > > So in an attempt to get back to a clean base I've uninstalled and deleted > anything shotwell'ish from the netbook and tried to compare installed > packages on the desktop and the netbook. > > I'm now in the situation where I've recompiled 0.11.2 from the source > tarball on what I believe to be a clean system. However, when I run > shotwell, it presents the main screen but then hangs consuming 100% CPU. > > Here's the output from the shotwell.log > Doesn't seem there's anything unusual in that log. But be aware that this line: L 2484 2011-09-26 17:05:27 [MSG] VideoSupport.vala:329: interpreter state > cookie not found; assuming all video thumbnails are out of date > which means that Shotwell is going to fire off a process to re-thumbnail your videos. If you have a lot of videos, this may take a while -- particularly if the disk or CPU is slow on your system. Anyway, not sure how much we can help with syncing database/photos over a network, since that's not something any of us here have any experience with. Maybe someone else on the mailing list has some ideas...? - Eric From alex at ourwoods.org Mon Sep 26 18:53:19 2011 From: alex at ourwoods.org (Alex) Date: Mon, 26 Sep 2011 14:53:19 -0400 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: References: <4E7FF101.9050109@ourwoods.org> <4E809ECC.6030506@ourwoods.org> <4E80A0E6.2060507@gmail.com> <4E80ABDD.7090905@ourwoods.org> Message-ID: <4E80CA1F.4070109@ourwoods.org> Jim Nelson said the following on 09/26/2011 02:27 PM: > Are you using Shotwell in direct-edit mode (that is, you right-clicked > on a photo file and chose "Open with Shotwell")? > > -- Jim I'm usually previewing images with Eye Of Gnome on Ubuntu and click the Edit button. I don't think that should make any difference as Shotwell opens the file from the disk. Eog does not pass anything to Shotwell but a file name. What results do you see? Alex Shotwell 0.9.3 on Ubuntu 11.04 -- alex at ourwoods.org From dougie at highmoor.co.uk Mon Sep 26 18:53:08 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 19:53:08 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: References: <4E80BA1E.90202@highmoor.co.uk> Message-ID: <4E80CA14.7020006@highmoor.co.uk> On 26/09/2011 19:40, Eric Gregory wrote: > > [ ... ] Shotwell considers tags to be associated with photos, no the > other way around -- for this reason it didn't make sense to use to let > empty tags persist across Shotwell sessions. I can see the logic but if you consider the situation where someone has a clear idea on how they want to organise their tags anticipating allocating them to batches of photos it does make sense. For example, I may select 10 photos and wish to allocate a tag to them. But the tag does not exist. To create the tag, in the place in the hierarchy that I want it, I have to navigate to the appropriate place in the tag structure and create the New tag, which will automatically unselect the photos I wish to tag. I must then go back and reselect the photos I wish to tag. A real life example might be where I take photos in several new locations and wish to create location tags under a particular county. So I create all the tags at once. As the tags do not persist across sessions this means I need to do all my tagging in the current session. > observation 2; create two tags, the 2nd tag being the same as the > first one, but with information in brackets. e.g. > > testtag1 > testtag1 (test string1) > > assign photos to both tags. It doesn't matter if they are the same > photos. > > delete testtag1 > > testtag1 (test string1) is also deleted. > > > I can't replicate this bug. Is there something more that needs to be > done to re-create this? Also, which version of Shotwell are you using? > I am seeing some rather alarming behavour with tagging at the moment and I'm not sure why. Or whether shotwell has always being doing it and I've only just noticed. I'm beginning to wonder if there's something odd that I've unwittingly introduced into my configuration. I shall do a couple more tests, and also see if it persists across reboots, and see if I can get more concrete examples. This is shotwell 0.11.2. Dougie From jim at yorba.org Mon Sep 26 18:53:36 2011 From: jim at yorba.org (Jim Nelson) Date: Mon, 26 Sep 2011 11:53:36 -0700 Subject: [Shotwell] Non-destructive editing In-Reply-To: References: <20110916132721.GA5686@siouxsie> <20110917123712.GG1714@siouxsie> <4E768D56.3060807@yorba.org> Message-ID: There are two separate features being discussed here: the Undo/Redo stack and a journaling non-destructive photo editor. I'm unaware of any application that maintains its Undo/Redo stack between sessions. Also, apps (including Shotwell) have a finite limit to the undo stack's size (in Shotwell, it's 20 operations). Once that limit is reached, old operations are dropped to make way for the new ones. What you're referring to is a journaling non-destructive editor, where each operation on a photo is stored as a list and applied against the original in turn. We've discussed this feature in the past. I definitely see its value, but it's not a simple feature and has many ramifications throughout the app, especially since its real value is in the other features you've mentioned: scripting, rewinding, filtering, and so forth. I could've sworn we had a ticket for this somewhere, but I can't find it. I've ticketed it here: http://redmine.yorba.org/issues/4184 I don't think this is something we're going to get to in the near future, but it's worth consideration going forward. -- Jim On Sat, Sep 24, 2011 at 7:31 AM, Conrad Dean wrote: > > > > I'm not aware of any other GNOME application that persists the undo > > hierarchy across sessions, so I don't think that Shotwell needs to > either. > > The undo mechanism is not intended to allow you to go back and revert > > recent changes to individual photos; it simply allows you to, well, undo > the > > last step that you did globally (just like in other GNOME apps). We > could > > conceivably modify Shotwell someday to keep track of the order of changes > > you've made to each photo and to revert recent changes. But if we do > > implement that, the user interface will probably not be through > Edit->Undo. > > > > > I apologize if this is a little off topic... but Adobe Lightroom keeps a > list of operations performed on a single photo. This lets you play around > with your photos and get a particular "look" that you like, and then you > can > analyze how you got there. > > While it's neat to play around with the operations themselves, going back > into the photo's history, modifying the operations, etc -- the real > strength > of this feature is you can save the operations as a single batch operation > that can be applied to multiple photos in the future, which is useful if > you > have a large set of photos from a single shoot that all need the same exact > color and exposure adjustments made at once. > > It's also a super intuitive interface for creating your own filters. > > Probably a superfluous feature, but it's one of those things that makes a > user feel in control of their environment and has a huge 'wow-factor'. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From eric at yorba.org Mon Sep 26 18:53:39 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 11:53:39 -0700 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> Message-ID: I know this doesn't help anyone here in the immediate term, but we've had a ticket open on finding a way to share between machines for some time: http://redmine.yorba.org/issues/1292 Personally I'd *love* for this feature to be in Shotwell today, but we just haven't had the time to implement it. One thought we had a while back was to use LDAP for sharing. That way there's no configuration required, you just launch two Shotwell instances on the same network and they can (optionally) share certain photos with one another. Patches are always gladly accepted; though to warn anyone thinking of trying to implement this in advance, networking sharing is likely to be a significant undertaking. - Eric From dougie at highmoor.co.uk Mon Sep 26 18:59:34 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 19:59:34 +0100 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: References: <4E80A519.7090701@highmoor.co.uk> Message-ID: <4E80CB96.1070505@highmoor.co.uk> On 26/09/2011 19:49, Eric Gregory wrote: > Doesn't seem there's anything unusual in that log. But be aware that > this line: > > L 2484 2011-09-26 17:05:27 [MSG] VideoSupport.vala:329: > interpreter state cookie not found; assuming all video thumbnails > are out of date > > > which means that Shotwell is going to fire off a process to > re-thumbnail your videos. If you have a lot of videos, this may take > a while -- particularly if the disk or CPU is slow on your system. > It's an empty installation. No photos. No videos. Nothing. Clean install. ~/Pictures is empty. > Anyway, not sure how much we can help with syncing database/photos > over a network, since that's not something any of us here have any > experience with. > I'm not worried about syncing over network; i.e. I'm not expecting it to be a problem. At the moment I'm struggling just trying to revert to a clean install of 0.11.2. I suspect there's some legacy configuration from a previous install that I've not been able to purge and I don't know where it is or how to purge it. Dougie From eric at yorba.org Mon Sep 26 19:07:13 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 12:07:13 -0700 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> Message-ID: On Mon, Sep 26, 2011 at 11:53 AM, Eric Gregory wrote: > > One thought we had a while back was to use LDAP for sharing. > Correction: I meant DPAP, not LDAP. More about DPAP here: http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol - Eric From eric at yorba.org Mon Sep 26 19:08:46 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 12:08:46 -0700 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: <4E80CB96.1070505@highmoor.co.uk> References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> Message-ID: On Mon, Sep 26, 2011 at 11:59 AM, Dougie Nisbet wrote: > I'm not worried about syncing over network; i.e. I'm not expecting it to be > a problem. At the moment I'm struggling just trying to revert to a clean > install of 0.11.2. I suspect there's some legacy configuration from a > previous install that I've not been able to purge and I don't know where it > is or how to purge it. > Shotwell configuration is stored in a few places. If you remove ~/.shotwell that should take care of everything important; you might also use dconf editor to remove (or reset) the /apps/shotwell prefs. - Eric From clanlaw at googlemail.com Mon Sep 26 19:10:57 2011 From: clanlaw at googlemail.com (Colin Law) Date: Mon, 26 Sep 2011 20:10:57 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> Message-ID: On 26 September 2011 20:07, Eric Gregory wrote: > On Mon, Sep 26, 2011 at 11:53 AM, Eric Gregory wrote: >> >> One thought we had a while back was to use LDAP for sharing. >> > > Correction: I meant DPAP, not LDAP. > > More about DPAP here: > http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol Or even DAAP :) Colin From dougie at highmoor.co.uk Mon Sep 26 20:29:07 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 21:29:07 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: <4E80CA14.7020006@highmoor.co.uk> References: <4E80BA1E.90202@highmoor.co.uk> <4E80CA14.7020006@highmoor.co.uk> Message-ID: <4E80E093.5010306@highmoor.co.uk> On 26/09/2011 19:53, Dougie Nisbet wrote: > On 26/09/2011 19:40, Eric Gregory wrote: >> >> I can't replicate this bug. >> > actually, neither can I. Interesting. I *think* it's something to do with the tag hierarchy. I can reproduce it with existing tags created during import from an f-spot db, but not with 'test' tags that I've created to try and reproduce it. Strange. The tags that can show the problem were introduced during import and have appeared in two places: top-level and in a lower-level, the 'correct' location. I took a desktop recording of the session that sadly neither flickr or picasa have managed to interpret (even though they uploaded without any problems). The file is only 4MB so I could email it if you wish. (produced using 'recordmysession' to an 'ogv' file). From dougie at highmoor.co.uk Mon Sep 26 20:32:36 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 21:32:36 +0100 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> Message-ID: <4E80E164.6070506@highmoor.co.uk> On 26/09/2011 20:08, Eric Gregory wrote: > > Shotwell configuration is stored in a few places. If you remove > ~/.shotwell that should take care of everything important; you might > also use dconf editor to remove (or reset) the /apps/shotwell prefs. I've installed the package dconf-tools which gives me donf-editor, and I can see a couple of shotwell settings, even after uninstalling and deleting. But they look quite innocuous and although I can see an option to 'reset to defaults' I can't see an option to delete them. Since I used to be able to run shotwell on my netbook and now I can't, it's clearly something I've introduced or changed. Perhaps there's some subtle dependency I've missed or removed. It's frustrating though. It would be great to be able to totally purge shotwell and start again. Dougie From dougie at highmoor.co.uk Mon Sep 26 20:55:10 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 21:55:10 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: <4E80E093.5010306@highmoor.co.uk> References: <4E80BA1E.90202@highmoor.co.uk> <4E80CA14.7020006@highmoor.co.uk> <4E80E093.5010306@highmoor.co.uk> Message-ID: <4E80E6AE.2010900@highmoor.co.uk> On 26/09/2011 21:29, Dougie Nisbet wrote: > On 26/09/2011 19:53, Dougie Nisbet wrote: >> On 26/09/2011 19:40, Eric Gregory wrote: >>> >>> I can't replicate this bug. >>> >> > > actually, neither can I. Interesting. > I suspect this is some weirdness particular to my database inherited from the f-spot import. I can test it by renaming a tag, and seeing another tag renamed accordingly. e.g. tag1 tag1 (text in brackets) if I rename 'tag1' to 'tag1_rn' I immediately see a corresponding change in 'tag1 (text in brackets)' which becomes 'tag1_rn (text in brackets)'. Hopefully as I gradually tidy up my tags these anomalies will vanish. Dougie From dougie at highmoor.co.uk Mon Sep 26 21:19:31 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 26 Sep 2011 22:19:31 +0100 Subject: [Shotwell] publishing to flickr - spaces in filename translated to %20 Message-ID: <4E80EC63.7050603@highmoor.co.uk> I've just tried the publish to flickr option. Spaces in filenames are converted to %20 (e.g. http://www.flickr.com/photos/djnisbet/6186794432/in/photostream/), whereas if I export from shotwell, then upload from the command line using flickr_upload, the spaces are ok (e.g. http://www.flickr.com/photos/djnisbet/6186298363/in/photostream/). (A similar thing happens with f-spot if photos are exported - spaces are translated to %20). This is just an observation as I've never really seen much advantage to exporting/publishing from within the photo application itself. It just ties up shotwell/f-spot/whatever, when it's easier to just export the photos to a directory and upload them using some other mechanism. Dougie From eric at yorba.org Mon Sep 26 21:26:19 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 14:26:19 -0700 Subject: [Shotwell] publishing to flickr - spaces in filename translated to %20 In-Reply-To: <4E80EC63.7050603@highmoor.co.uk> References: <4E80EC63.7050603@highmoor.co.uk> Message-ID: On Mon, Sep 26, 2011 at 2:19 PM, Dougie Nisbet wrote: > I've just tried the publish to flickr option. Spaces in filenames are > converted to %20 (e.g. http://www.flickr.com/photos/** > djnisbet/6186794432/in/**photostream/), > whereas if I export from shotwell, then upload from the command line using > flickr_upload, the spaces are ok (e.g. http://www.flickr.com/photos/** > djnisbet/6186298363/in/**photostream/ > ). > > (A similar thing happens with f-spot if photos are exported - spaces are > translated to %20). > > This is just an observation as I've never really seen much advantage to > exporting/publishing from within the photo application itself. It just ties > up shotwell/f-spot/whatever, when it's easier to just export the photos to a > directory and upload them using some other mechanism. > Yup, I can confirm this. Thanks for the bug report! I filed a ticket here: http://redmine.yorba.org/issues/4187 - Eric From gary at boltav.me.uk Mon Sep 26 22:13:58 2011 From: gary at boltav.me.uk (Gary) Date: Mon, 26 Sep 2011 23:13:58 +0100 Subject: [Shotwell] Full bleed print on 100x150mm Message-ID: <4E80F926.8070001@boltav.me.uk> Hi Using Shotwell 0.9.3 on Ubuntu 11.04 If I set the page size to full bleed 4x6in and then use the slightly smaller 100x150mm (which retailers call 4x6), as long as I set the resolution correctly for the actual size and print using autosize, I get a full bleed print although it is much more cropped than I would have liked or expected. Using the correct paper size (100x150) on my custom ppd file which used to work fine with F-Spot the print preview is good but the printer says 'paper mismatch'. I conclude that somehow my settings are being mangled. I have tried all kinds of combinations of paper and image size to get round this but at the moment it seems like I can only get a partly satisfactory result using deliberately wrong settings. Ideally, I should be able to set, say, image size 10.37x15.38 cm with paper size 100x150mm and resolution 390ppi for an image 2304x1536 to get the correct full bleed result. Do the later versions of Shotwell have more in the way of print options? Can anyone suggest what I might try to get full bleed on 100x150mm? From adam at yorba.org Tue Sep 27 00:41:31 2011 From: adam at yorba.org (Adam Dingle) Date: Tue, 27 Sep 2011 04:41:31 +0400 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: <4E80E164.6070506@highmoor.co.uk> References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> <4E80E164.6070506@highmoor.co.uk> Message-ID: <4E811BBB.8030106@yorba.org> On 09/27/2011 12:32 AM, Dougie Nisbet wrote: > On 26/09/2011 20:08, Eric Gregory wrote: >> >> Shotwell configuration is stored in a few places. If you remove >> ~/.shotwell that should take care of everything important; you might >> also use dconf editor to remove (or reset) the /apps/shotwell prefs. > > I've installed the package dconf-tools which gives me donf-editor, and > I can see a couple of shotwell settings, even after uninstalling and > deleting. But they look quite innocuous and although I can see an > option to 'reset to defaults' I can't see an option to delete them. > > Since I used to be able to run shotwell on my netbook and now I can't, > it's clearly something I've introduced or changed. Perhaps there's > some subtle dependency I've missed or removed. It's frustrating > though. It would be great to be able to totally purge shotwell and > start again. I think the best way to debug this is to figure out what Shotwell is doing while consuming 100% CPU. In other words, we need a stack trace. There are two ways you could get this. You could run Shotwell under gdb, then press Ctrl+C during the 100% CPU loop and use the 'where' command to see where it was interrupted. Or you could install the Sysprof profiler and gather profiling data as Shotwell runs; this should also reveal the stack trace. In either case you'll want to have debug symbols installed for important system libraries (GTK, GLib). If you do this and report the trace to us, it may give insight into what's going on. Otherwise, as Eric said, we really don't have much to go on here. adam From monnier at iro.umontreal.ca Tue Sep 27 00:47:44 2011 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 26 Sep 2011 20:47:44 -0400 Subject: [Shotwell] Sharing a photo collection between machines References: <4E80206C.5000305@highmoor.co.uk> Message-ID: > I know this doesn't help anyone here in the immediate term, but we've had a > ticket open on finding a way to share between machines for some time: > http://redmine.yorba.org/issues/1292 But this seems to be about having concurrent access to some particular set of photos. While I do care about this as well, the problem I'm after in this thread is the case where the photo database is replicated rather than shared. This is because I have several machines (desktop at home, desktop in the office, my laptop, my wife's laptop, my netbook, you name it...) and I want to be able to access my photos from any one of those machines, even when they're not connected. I do have the disk space needed to keep a separate copy on each machine (tho I guess a subsequent request would be about having only some part of the photo database replicated). Currently, I do that by rsync, but it means that the mirrors can only be read-only, whereas I want to be able to make changes from any one of the mirrors and have it reflected later on on the other machines. Stefan From eric at yorba.org Tue Sep 27 01:18:00 2011 From: eric at yorba.org (Eric Gregory) Date: Mon, 26 Sep 2011 18:18:00 -0700 Subject: [Shotwell] Full bleed print on 100x150mm In-Reply-To: <4E80F926.8070001@boltav.me.uk> References: <4E80F926.8070001@boltav.me.uk> Message-ID: On Mon, Sep 26, 2011 at 3:13 PM, Gary wrote: > Using Shotwell 0.9.3 on Ubuntu 11.04 > > If I set the page size to full bleed 4x6in and then use the slightly > smaller 100x150mm (which retailers call 4x6), as long as I set the > resolution correctly for the actual size and print using autosize, I get a > full bleed print although it is much more cropped than I would have liked or > expected. > > Using the correct paper size (100x150) on my custom ppd file which used to > work fine with F-Spot the print preview is good but the printer says 'paper > mismatch'. I conclude that somehow my settings are being mangled. I have > tried all kinds of combinations of paper and image size to get round this > but at the moment it seems like I can only get a partly satisfactory result > using deliberately wrong settings. Ideally, I should be able to set, say, > image size 10.37x15.38 cm with paper size 100x150mm and resolution 390ppi > for an image 2304x1536 to get the correct full bleed result. > Sorry to hear about the problem. Printing issues are fairly difficult for us to diagnose, since printers are all a little different and we only have one in the office. We haven't tested with 4x6 images in some time. Are you able to replicate this issue with a print-to-pdf driver by any chance? Also, what printer and printer driver are you using? Do the later versions of Shotwell have more in the way of print options? > Can anyone suggest what I might try to get full bleed on 100x150mm? > Nothing has been done with printing since 0.9, unfortunately! - Eric From apeitheo at gmail.com Tue Sep 27 01:26:23 2011 From: apeitheo at gmail.com (Brad Hermanson) Date: Mon, 26 Sep 2011 21:26:23 -0400 Subject: [Shotwell] Does not register camera on Slackware: Kodak EasyShare CX7430 Message-ID: <4E81263F.2080106@gmail.com> I just recently tried the camera with 0.11.2 and it still doesn't work. Attached are the files you've requested. > Hi Brad, > > It looks to me that there's something going wrong in the code in Shotwell > that matches up the camera's address on the USB bus with the gphoto2 address > (which is what we need to use to communicate with gphoto2, which talks to > the camera). > > There's a few things we need you to do to diagnose this problem. First, > from the console, run Shotwell like this: > > $ SHOTWELL_LOG=1 shotwell > > With Shotwell running, plug in the camera, wait for a ten seconds > (presumably Shotwell won't show it), and then unplug the camera. Exit > Shotwell. > > Then find this file: ~/.cache/shotwell/shotwell.log We need this log file. > > Second, run this command with the camera plugged in: > > $ sudo lsusb -v> lsusb.txt > > Third, run this command with the camera plugged in: > > $ udevadm info --export-db> udev.txt > > Finally, run this command with the camera plugged in: > > $ gphoto2 --list-ports> gphoto2.txt > > (You might need to install the gphoto2 package in order for this last one to > work.) > > Then send us all these files: shotwell.log, lsusb.txt, udev.txt, gphoto2.txt > > Thanks, > > -- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: shotwell.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lsusb.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: udev.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gphoto2.txt URL: From dougie at highmoor.co.uk Tue Sep 27 08:02:06 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 09:02:06 +0100 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: <4E811BBB.8030106@yorba.org> References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> <4E80E164.6070506@highmoor.co.uk> <4E811BBB.8030106@yorba.org> Message-ID: <4E8182FE.3020207@highmoor.co.uk> On 27/09/2011 01:41, Adam Dingle wrote: > > I think the best way to debug this is to figure out what Shotwell is > doing while consuming 100% CPU. In other words, we need a stack > trace. There are two ways you could get this. You could run Shotwell > under gdb, then press Ctrl+C during the 100% CPU loop and use the > 'where' command to see where it was interrupted. Or you could install > the Sysprof profiler and gather profiling data as Shotwell runs; this > should also reveal the stack trace. In either case you'll want to > have debug symbols installed for important system libraries (GTK, > GLib). If you do this and report the trace to us, it may give insight > into what's going on. Otherwise, as Eric said, we really don't have > much to go on here. > I'm happy to give this a try but I might need some pointers. Here's what I've tried with gdb. I installed it and ran it against shotwell. I typed 'start' and 'continue', hitting Ctrl-C when it hung around 100%CPU. I also gave sysprof a try but didn't know what to do with the output. It created a 700K file when I saved it. Here's the session from gdb: Script started on Tue 27 Sep 2011 08:46:30 BST dougie at barra ~ $ d dougie at barra ~ $ gdb shotwell GNU gdb (GDB) 7.2-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/local/bin/shotwell...done. (gdb) start Temporary breakpoint 1 at 0x4862f0: file src/main.c, line 1658. Starting program: /usr/local/bin/shotwell [Thread debugging using libthread_db enabled] Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe8e8) at src/main.c:1658 1658 int main (int argc, char ** argv) { (gdb) (gdb) continue Continuing. [New Thread 0x7fffddd18700 (LWP 2488)] [New Thread 0x7fffdd517700 (LWP 2489)] [New Thread 0x7fffdcd16700 (LWP 2490)] [New Thread 0x7fffd7fff700 (LWP 2491)] ^C Program received signal SIGINT, Interrupt. 0x00007ffff2dae298 in ?? () from /usr/lib/libcairo.so.2 (gdb) where #0 0x00007ffff2dae298 in ?? () from /usr/lib/libcairo.so.2 #1 0x00007ffff2d9336f in cairo_line_to () from /usr/lib/libcairo.so.2 #2 0x00007fffe7f64edc in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libaurora.so #3 0x00007fffe7f59a32 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libaurora.so #4 0x00007ffff41d0bde in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #5 0x00007ffff4312b78 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x00007ffff20eee7e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #7 0x00007ffff210009c in ?? () from /usr/lib/libgobject-2.0.so.0 #8 0x00007ffff2109d05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #9 0x00007ffff2109ed3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #10 0x00007ffff42b8b9e in gtk_widget_realize () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x00007ffff42b92d8 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x00007ffff4156c5a in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x00007ffff4116f1f in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x00007ffff20eee7e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0x00007ffff210009c in ?? () from /usr/lib/libgobject-2.0.so.0 #16 0x00007ffff2109d05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x00007ffff2109ed3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 ---Type to continue, or q to quit--- #18 0x00007ffff42b92ae in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x00007ffff20eee7e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #20 0x00007ffff210009c in ?? () from /usr/lib/libgobject-2.0.so.0 #21 0x00007ffff2109d05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #22 0x00007ffff2109ed3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #23 0x00007ffff42b9ba6 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0 #24 0x00000000004eef76 in library_window_show_background_progress_bar ( self=0xe06100) at src/library/LibraryWindow.c:4896 #25 library_window_show_background_progress_bar (self=0xe06100) at src/library/LibraryWindow.c:4892 #26 0x00000000004ef30b in library_window_start_pulse_background_progress_bar ( self=0xe06100, label=0x7fffde3d54de "Updating library...", priority=35) at src/library/LibraryWindow.c:4810 #27 0x00007ffff20eee7e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #28 0x00007ffff21008d7 in ?? () from /usr/lib/libgobject-2.0.so.0 #29 0x00007ffff2109d05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #30 0x00007ffff210a092 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #31 0x000000000067fb11 in directory_monitor_start_discovery (self=0xdf4050) at src/DirectoryMonitor.c:1692 #32 0x0000000000681393 in library_monitor_pool_on_start_monitor ( ---Type to continue, or q to quit--- self=) at src/LibraryMonitor.c:1217 #33 _library_monitor_pool_on_start_monitor_gsource_func ( self=) at src/LibraryMonitor.c:1164 #34 0x00007ffff15e6ddb in ?? () from /lib/libglib-2.0.so.0 #35 0x00007ffff15e54a3 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #36 0x00007ffff15e5c80 in ?? () from /lib/libglib-2.0.so.0 #37 0x00007ffff15e62f2 in g_main_loop_run () from /lib/libglib-2.0.so.0 #38 0x00007ffff41932b7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x0000000000697d8c in application_start (self=0xaee860) at src/Application.c:141 #40 0x0000000000583de4 in library_exec (mounts=, mounts_length1=) at src/main.c:1124 #41 0x00000000005850bf in _vala_main (args=0x7fffffffe8e8, args_length1=1) at src/main.c:1596 #42 0x0000000000486311 in main (argc=1, argv=0x7fffffffe8e8) at src/main.c:1661 (gdb) quit A debugging session is active. Inferior 1 [process 2485] will be killed. Quit anyway? (y or n) y dougie at barra ~ $ exit Script done on Tue 27 Sep 2011 08:47:36 BST From clanlaw at googlemail.com Tue Sep 27 08:51:01 2011 From: clanlaw at googlemail.com (Colin Law) Date: Tue, 27 Sep 2011 09:51:01 +0100 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: <4E80206C.5000305@highmoor.co.uk> Message-ID: On 27 September 2011 01:47, Stefan Monnier wrote: >> I know this doesn't help anyone here in the immediate term, but we've had a >> ticket open on finding a way to share between machines for some time: >> http://redmine.yorba.org/issues/1292 > > But this seems to be about having concurrent access to some particular > set of photos. ?While I do care about this as well, the problem I'm > after in this thread is the case where the photo database is replicated > rather than shared. > > This is because I have several machines (desktop at home, desktop in > the office, my laptop, my wife's laptop, my netbook, you name it...) and > I want to be able to access my photos from any one of those machines, > even when they're not connected. ?I do have the disk space needed to > keep a separate copy on each machine (tho I guess a subsequent request > would be about having only some part of the photo database replicated). > > Currently, I do that by rsync, but it means that the mirrors can only be > read-only, whereas I want to be able to make changes from any one of the > mirrors and have it reflected later on on the other machines. You could possibly use Dropbox with symlinks to sync across the machines, alternatively there are a number of bi-directional sync apps though I have not tried them. You will have to make sure that you do not make changes on two machines at the same time (or between syncs) otherwise you will get in a mess, so good backup strategy would be necessary. It sounds a bit dangerous though unless you are confident you can enforce the 'only edit on one machine between syncs' rule. Colin From dougie at highmoor.co.uk Tue Sep 27 09:21:32 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 10:21:32 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: <4E80E093.5010306@highmoor.co.uk> References: <4E80BA1E.90202@highmoor.co.uk> <4E80CA14.7020006@highmoor.co.uk> <4E80E093.5010306@highmoor.co.uk> Message-ID: <4E81959C.6020103@highmoor.co.uk> On 26/09/2011 21:29, Dougie Nisbet wrote: > > The tags that can show the problem were introduced during import and > have appeared in two places: top-level and in a lower-level, the > 'correct' location. I took a desktop recording of the session that > sadly neither flickr or picasa have managed to interpret (even though > they uploaded without any problems). The file is only 4MB so I could > email it if you wish. (produced using 'recordmysession' to an 'ogv' > file). > Although both picasa and flickr didn't like the movie file it seems to work fine from my own webspace here: http://www.katsura.myzen.co.uk/shotwell_delete.ogv This shows me deleting the tag 'Acer capillepes', and when I do so, the adjacent tag 'Acer capillepes (Sapindaceae)' is also being deleted. Remaming the first tag also causes a corresponding rename in the second tag. Dougie From chrisgame at pobox.com Tue Sep 27 10:04:18 2011 From: chrisgame at pobox.com (Chris Game) Date: Tue, 27 Sep 2011 11:04:18 +0100 (BST) Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: Message-ID: > Date: Mon, 26 Sep 2011 20:47:44 -0400 > From: Stefan Monnier > To: shotwell at lists.yorba.org > Subject: Re: [Shotwell] Sharing a photo collection between machines > .... > > Currently, I do that by rsync, but it means that the mirrors can only be > read-only, whereas I want to be able to make changes from any one of the > mirrors and have it reflected later on on the other machines. > Try using Dropbox to do the synching, with links from your config files to ones in the Dropbox folder to maintain consistent views of Shotwell across the machines. Should even work with other OSs! From dougie at highmoor.co.uk Tue Sep 27 10:15:59 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 11:15:59 +0100 Subject: [Shotwell] shotwell knows best Message-ID: <4E81A25F.5060303@highmoor.co.uk> I'm getting caught out again by shotwell thinking it knows best. I rename image files based on their tags as I find it very useful in terms of portability and it is often useful in finding images very quickly (using 'locate') without the need to fire up a photo package. ( http://www.bluecedar.org.uk/?p=143 ). f-spot allows a 'real' delete (shift-delete) whereas in Shotwell I think it's a two-way process. Move to Wastebasket - then move to desktop wastbasket. So to rename images that I have tagged in shotwell (or f-spot), I would export the files to a directory, then delete (move to wastebasket) the files in shotwell. After renaming them outside shotwell, I then re-import them, selecting 'Copy' rather than 'import in place'. But I've only just discovered that shotwell hasn't been doing what I expected. In fact, I'm not clear exactly what it has been doing. It obviously knows I'm up to something as the log file shows it recognises the import as a duplicate, with messages such as: L 11880 2011-09-27 11:02:24 [DBG] BatchImport.vala:848: duplicate photo detected, not importing /images/2011/09/24/24-September-2011 - Durham Parkrun - Durham Parkrun - run7 - Parkrun -- (United Kingdom - England - Elvet ED - Shincliffe) -- Sat 24 Sep 2011 09-04-12 BST.jpg or sometimes more alarmingly as: L 11880 2011-09-27 11:04:22 [DBG] BatchImport.vala:809: duplicate linked photo found in trash, untrashing and removing transforms for /home/dougie/renamejpegsout/24-September-2011 - Durham Parkrun - run7 -- (United Kingdom - England - Elvet ED - Durham) -- Sat 24 Sep 2011 09-18-05 BST.jpg when the import is complete, and I use 'show in file manager' to look at the imported files, I can see that it has not been copied to the /images directory, but is still in place in /home/dougie/renamejpegsout. As I delete this directory once I've imported the images this is a bit dangerous for me. I presume I can get around this by physically deleting the images from shotwell before re-importing, but I do feel a bit uneasy as I've come unstuck a few times now (e.g. no empty tags, quietly writing metadata to image files even though write unchecked) where shotwell makes assumptions about what to do without letting me know, unless I keep an eagle eye on the log file. I've checked the bugs and think this might be related to http://redmine.yorba.org/issues/3687 ? Although in my case I haven't noticed any performance issues. Dougie From dougie at highmoor.co.uk Tue Sep 27 10:25:07 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 11:25:07 +0100 Subject: [Shotwell] shotwell knows best In-Reply-To: <4E81A25F.5060303@highmoor.co.uk> References: <4E81A25F.5060303@highmoor.co.uk> Message-ID: <4E81A483.1020805@highmoor.co.uk> On 27/09/2011 11:15, Dougie Nisbet wrote: > > when the import is complete, and I use 'show in file manager' to look > at the imported files, I can see that it has not been copied to the > /images directory, but is still in place in > /home/dougie/renamejpegsout. As I delete this directory once I've > imported the images this is a bit dangerous for me. > I've just confirmed that shotwell thinks the 'imported' files are indeed in their original locations, and not in /images, and the import hasn't respected the 'copy' option. So if I delete from shotwell they are deleted from their imported source location, rather than destination where I'd assumed they'd been copied to. So I think what's happening in summary is: If import / copy is selected on a directory, and the files already exist in the shotwell wastebasket, shotwell appears to import the files in place, rather than copy them. Dougie From dougie at highmoor.co.uk Tue Sep 27 10:44:23 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 11:44:23 +0100 Subject: [Shotwell] quick and dirty 'real' delete Message-ID: <4E81A907.3010207@highmoor.co.uk> At the moment I think it takes 3 steps to physically delete images (move to wastebasket, move to desktop wastebasket, delete from desktop wastebasket). Am I correct in thinking that if I simply physically delete files at the command line shotwell will automatically detect that the images have disappeared and update its database appropriately? Thanks, Dougie From oliver at first.in-berlin.de Tue Sep 27 11:54:30 2011 From: oliver at first.in-berlin.de (oliver) Date: Tue, 27 Sep 2011 13:54:30 +0200 Subject: [Shotwell] quick and dirty 'real' delete In-Reply-To: <4E81A907.3010207@highmoor.co.uk> References: <4E81A907.3010207@highmoor.co.uk> Message-ID: <20110927115430.GB1657@siouxsie> On Tue, Sep 27, 2011 at 11:44:23AM +0100, Dougie Nisbet wrote: > At the moment I think it takes 3 steps to physically delete images > (move to wastebasket, move to desktop wastebasket, delete from > desktop wastebasket). > > Am I correct in thinking that if I simply physically delete files at > the command line shotwell will automatically detect that the images > have disappeared and update its database appropriately? [...] I doubt that would make sense. If files disappear, it shows that something is wrong. And some users asked for a feature that allows to detect temporarily missing files. So... when the database would just automatically update itself on missing files, it would make no sense here; and it would not be much more than the filesystem plus some metadata. A missing file should rather be a starting point for an investigation. I also see no reason why this wastebasket-issue is so bad. If you don't real-delete file by file, this is making sense. First kick out all files, and before you decide really to delete them physically, one step in between is to do. But then you can delete all files at once. Hence it is not a really big problem, that the files will be deleted physically only by that one step more. You maybe have selected some hundred files for deleting, and then it's 1/100 of a command per file. This is not so much additional overhead, but gives one step more of save behaviour. I doubt it would make sense to change that. Ciao, Oliver From dougie at highmoor.co.uk Tue Sep 27 13:13:06 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 14:13:06 +0100 Subject: [Shotwell] shotwell knows best In-Reply-To: <4E81A25F.5060303@highmoor.co.uk> References: <4E81A25F.5060303@highmoor.co.uk> Message-ID: <4E81CBE2.4080409@highmoor.co.uk> On 27/09/2011 11:15, Dougie Nisbet wrote: > > So to rename images that I have tagged in shotwell (or f-spot), I > would export the files to a directory, then delete (move to > wastebasket) the files in shotwell. After renaming them outside > shotwell, I then re-import them, selecting 'Copy' rather than 'import > in place'. I've just thought of a snag of doing this with shotwell. The tag hierarchy in f-spot was always 'remembered' on re-import, and I've always assumed this is because f-spot does not allow the same tag to be used in more than once place. So on import, the tags can only be in one place in the hierarchy. This is not the case with shotwell. An interesting puzzle. Perhaps I need to stop concentrating on content-rich filenames. Dougie From monnier at iro.umontreal.ca Tue Sep 27 13:30:46 2011 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Tue, 27 Sep 2011 09:30:46 -0400 Subject: [Shotwell] Sharing a photo collection between machines References: Message-ID: > Try using Dropbox to do the synching, with links from your config > files to ones in the Dropbox folder to maintain consistent views of > Shotwell across the machines. Should even work with other OSs! I'd rather not have to pay 10-20$ per month for the privilege of depending on some company I don't know. And AFAIK the Dropbox driver is not Free Software (tho they don't say it out loud: they just don't say much about it, whereas they clearly say that the nautilus plugin is open source), so it's not an option for me. This said, you got me thinking, and maybe I could use a lightweight Bazaar checkout, so the (large) repository doesn't have to be copied onto each and every machine. > It sounds a bit dangerous though unless you are confident you can > enforce the 'only edit on one machine between syncs' rule. Yes, in this respect, the support for replicating the database poses similar issues to the support for sharing the database. BTW, this also brings us back to some ealier point in another thread: if the metadata DB only stores redundant info and can be reconstructed from the photo files, then the concurrent modification is only really problematic when it is a modification to the same photo. Stefan From clanlaw at googlemail.com Tue Sep 27 14:34:01 2011 From: clanlaw at googlemail.com (Colin Law) Date: Tue, 27 Sep 2011 15:34:01 +0100 Subject: [Shotwell] shotwell knows best In-Reply-To: <4E81A25F.5060303@highmoor.co.uk> References: <4E81A25F.5060303@highmoor.co.uk> Message-ID: On 27 September 2011 11:15, Dougie Nisbet wrote: > I'm getting caught out again by shotwell thinking ?it knows best. > > I rename image files based on their tags as I find it very useful in terms > of portability and it is often useful in finding images very quickly (using > 'locate') without the need to fire up a photo package. ( > http://www.bluecedar.org.uk/?p=143 ). f-spot allows a 'real' delete > (shift-delete) whereas in Shotwell I think it's a two-way process. Move to > Wastebasket - then move to desktop wastbasket. > > So to rename images that I have tagged in shotwell (or f-spot), I would > export the files to a directory, then delete (move to wastebasket) the files > in shotwell. After renaming them outside shotwell, I then re-import them, I would find it useful to be able to rename files inside Shotwell. Is there a technical reason why that would be difficult to implement. That would make this sort of exercise much easier. I expect there is a ticket for this already. Colin From jim at yorba.org Tue Sep 27 17:20:25 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 27 Sep 2011 10:20:25 -0700 Subject: [Shotwell] quick and dirty 'real' delete In-Reply-To: <4E81A907.3010207@highmoor.co.uk> References: <4E81A907.3010207@highmoor.co.uk> Message-ID: You can skip steps by using Edit -> Remove From Library (Shift+Delete). This will give you the option of moving the backing file to the desktop trash can, skipping Shotwell's. Shotwell has no provision for deleting the file out-right. Shotwell doesn't automatically remove deleted images from its database. This was a design choice made under careful consideration. One common complaint we've had is from people who have their photos on external storage that's either disconnected, turned off, or other not mounted properly. If Shotwell detected these images as gone and wiped them from its database, a lot of information could be lost. This is why Shotwell marks these files as offline. If it finds them again, then they come back online. Otherwise, the user needs to remove them manually from the database. -- Jim On Tue, Sep 27, 2011 at 3:44 AM, Dougie Nisbet wrote: > At the moment I think it takes 3 steps to physically delete images (move to > wastebasket, move to desktop wastebasket, delete from desktop wastebasket). > > Am I correct in thinking that if I simply physically delete files at the > command line shotwell will automatically detect that the images have > disappeared and update its database appropriately? > > Thanks, > > Dougie > > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Tue Sep 27 17:33:19 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 18:33:19 +0100 Subject: [Shotwell] quick and dirty 'real' delete In-Reply-To: References: <4E81A907.3010207@highmoor.co.uk> Message-ID: <4E8208DF.4060602@highmoor.co.uk> On 27/09/2011 18:20, Jim Nelson wrote: > You can skip steps by using Edit -> Remove From Library > (Shift+Delete). This will give you the option of moving the backing > file to the desktop trash can, skipping Shotwell's. Shotwell has no > provision for deleting the file out-right. > I see what you mean. That's not what I was expecting. I'd never tried that option as I hadn't expected to be offered more choices after pressing Shift-Delete. Thanks, Dougie From eric at yorba.org Tue Sep 27 18:41:56 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 27 Sep 2011 11:41:56 -0700 Subject: [Shotwell] shotwell knows best In-Reply-To: References: <4E81A25F.5060303@highmoor.co.uk> Message-ID: There is in fact a ticket for renaming from within Shotwell: http://redmine.yorba.org/issues/1562 On Tue, Sep 27, 2011 at 3:25 AM, Dougie Nisbet wrote: I've just confirmed that shotwell thinks the 'imported' files are indeed in > their original locations, and not in /images, and the import hasn't > respected the 'copy' option. So if I delete from shotwell they are deleted > from their imported source location, rather than destination where I'd > assumed they'd been copied to. > > So I think what's happening in summary is: If import / copy is selected > on a directory, and the files already exist in the shotwell wastebasket, > shotwell appears to import the files in place, rather than copy them. > I believe this is only the expected behavior if you did an import in place for that photo the first time you imported it. Is that what you did, or are you seeing different behavior? - Eric From eric at yorba.org Tue Sep 27 19:01:44 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 27 Sep 2011 12:01:44 -0700 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: <4E81959C.6020103@highmoor.co.uk> References: <4E80BA1E.90202@highmoor.co.uk> <4E80CA14.7020006@highmoor.co.uk> <4E80E093.5010306@highmoor.co.uk> <4E81959C.6020103@highmoor.co.uk> Message-ID: On Tue, Sep 27, 2011 at 2:21 AM, Dougie Nisbet wrote: > > Although both picasa and flickr didn't like the movie file it seems to work > fine from my own webspace here: > > http://www.katsura.myzen.co.**uk/shotwell_delete.ogv > > This shows me deleting the tag 'Acer capillepes', and when I do so, the > adjacent tag 'Acer capillepes (Sapindaceae)' is also being deleted. Remaming > the first tag also causes a corresponding rename in the second tag. > Yep, that's how I tested it. Strange that it worked one way for you and another for me -- these are some of the toughest bugs to solve. I filed a ticket on this here: http://redmine.yorba.org/issues/4190 Hopefully we'll be able to investigate this further for 0.12. Thanks for the video! - Eric From dougie at highmoor.co.uk Tue Sep 27 19:22:00 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 20:22:00 +0100 Subject: [Shotwell] possible tagging bugs (0.11.2) In-Reply-To: References: <4E80BA1E.90202@highmoor.co.uk> <4E80CA14.7020006@highmoor.co.uk> <4E80E093.5010306@highmoor.co.uk> <4E81959C.6020103@highmoor.co.uk> Message-ID: <4E822258.4040902@highmoor.co.uk> On 27/09/2011 20:01, Eric Gregory wrote: > On Tue, Sep 27, 2011 at 2:21 AM, Dougie Nisbet > wrote: > > > Although both picasa and flickr didn't like the movie file it > seems to work fine from my own webspace here: > > http://www.katsura.myzen.co.uk/shotwell_delete.ogv > > This shows me deleting the tag 'Acer capillepes', and when I do > so, the adjacent tag 'Acer capillepes (Sapindaceae)' is also being > deleted. Remaming the first tag also causes a corresponding rename > in the second tag. > > > Yep, that's how I tested it. Strange that it worked one way for you > and another for me -- these are some of the toughest bugs to solve. > > I filed a ticket on this here: > http://redmine.yorba.org/issues/4190 > > Hopefully we'll be able to investigate this further for 0.12. > > Thanks for the video! > > - Eric You're very welcome, but please don't sweat it on my behalf! I'm seeing all sorts of weirdness at the moment on my imported tags and I'm quite philosophical about it. It largely seems to be top-level tags that are duplicated in other places in the tag hierarchy that are showing bizarre behaviour and I'm simply deleting them as the photos they are associated with seem to be 'double-tagged' with the same tag. As my database gradually gets tidier I'll get a better idea of where the real problems, if any, are. Dougie From dougie at highmoor.co.uk Tue Sep 27 19:24:03 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 20:24:03 +0100 Subject: [Shotwell] shotwell knows best In-Reply-To: References: <4E81A25F.5060303@highmoor.co.uk> Message-ID: <4E8222D3.10204@highmoor.co.uk> On 27/09/2011 19:41, Eric Gregory wrote: > > I believe this is only the expected behavior if you did an import in > place for that photo the first time you imported it. Is that what you > did, or are you seeing different behavior? > I never import 'in place'; I always do 'copy'. But it's always possible that I've been mistaken. Now that I have a better idea of what I'm looking for I shall take more notice the next time I do an import/tag/export/rename cycle. Dougie From lucas at yorba.org Tue Sep 27 19:25:50 2011 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 27 Sep 2011 12:25:50 -0700 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: <4E8182FE.3020207@highmoor.co.uk> References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> <4E80E164.6070506@highmoor.co.uk> <4E811BBB.8030106@yorba.org> <4E8182FE.3020207@highmoor.co.uk> Message-ID: I think I know your problem. Here's the telling line: > from /usr/lib/gtk-2.0/2.10.0/engines/libaurora.so Shotwell (and several other applications) have issues working with the Aurora theme engine. If you set your theme engine to Clearlooks and then launch Shotwell, does that solve the problem? Cheers, Lucas From dougie at highmoor.co.uk Tue Sep 27 19:37:20 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Tue, 27 Sep 2011 20:37:20 +0100 Subject: [Shotwell] shotwell (0.11.2) hanging with 100% CPU LXDE In-Reply-To: References: <4E80A519.7090701@highmoor.co.uk> <4E80CB96.1070505@highmoor.co.uk> <4E80E164.6070506@highmoor.co.uk> <4E811BBB.8030106@yorba.org> <4E8182FE.3020207@highmoor.co.uk> Message-ID: <4E8225F0.4050600@highmoor.co.uk> On 27/09/2011 20:25, Lucas Beeler wrote: > I think I know your problem. Here's the telling line: > >> from /usr/lib/gtk-2.0/2.10.0/engines/libaurora.so > Shotwell (and several other applications) have issues working with the > Aurora theme engine. If you set your theme engine to Clearlooks and > then launch Shotwell, does that solve the problem? Oh deep joy! Thank you, Lucas! Sorted! The chances of me ever stumbling on that one by myself are about**http://tinyurl.com/6ym99h ! I'm really pleased to have solved that one as I'm off on holiday next week (and so will give the list some respite from my nitpicking) and fancied playing around with shotwell and my photos while away. Great stuff indeed. Dead chuffed! Cheers! Dougie From jim at yorba.org Tue Sep 27 20:49:10 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 27 Sep 2011 13:49:10 -0700 Subject: [Shotwell] EXIF data contained in JPEG image files In-Reply-To: <4E80CA1F.4070109@ourwoods.org> References: <4E7FF101.9050109@ourwoods.org> <4E809ECC.6030506@ourwoods.org> <4E80A0E6.2060507@gmail.com> <4E80ABDD.7090905@ourwoods.org> <4E80CA1F.4070109@ourwoods.org> Message-ID: The reason I asked is because Shotwell has two modes: library mode and direct-edit mode. In library mode, Shotwell doesn't touch the master file on disk unless the user explicitly says it's okay, such as writing metadata In direct-edit mode, when you make edits to a file and choose File -> Save, it will overwrite the file. This is the mode you're in when you run Shotwell from EoG. I was just making sure this is what's going on. I took a photo, modified it in direct-edit mode, and saved it. I then ran this command for each: $ exiv2 -pa IMG_0001.JPG > orig.txt $ exiv2 -pa IMG_0002_saved.JPG > saved.txt Then I did a diff (using meld) of the files. I see no changes other than a couple expected modifications. What do you see when you do this experiment? -- Jim On Mon, Sep 26, 2011 at 11:53 AM, Alex wrote: > Jim Nelson said the following on 09/26/2011 02:27 PM: > > Are you using Shotwell in direct-edit mode (that is, you right-clicked on >> a photo file and chose "Open with Shotwell")? >> >> -- Jim >> > > I'm usually previewing images with Eye Of Gnome on Ubuntu and click the > Edit button. I don't think that should make any difference as Shotwell > opens the file from the disk. Eog does not pass anything to Shotwell but a > file name. > > What results do you see? > > Alex > > Shotwell 0.9.3 on Ubuntu 11.04 > > -- > alex at ourwoods.org > > From jim at yorba.org Tue Sep 27 21:01:33 2011 From: jim at yorba.org (Jim Nelson) Date: Tue, 27 Sep 2011 14:01:33 -0700 Subject: [Shotwell] Pictures as symbolic links In-Reply-To: References: <20110901100500.GA1867@siouxsie> Message-ID: Sorry for the late reply, been busy as anything lately and am catching up on old email. To be honest, the more I understand what you're trying to do the more it sounds like a highly particular use-case and not something that would be used by our more general audience of users. Today I'm more inclined to support symlinked directories than files because of the headaches symlink files lead to, such as broken links, or multiple links to the same file (which, ideally, Shotwell would recognize as the same file, and not merely duplicates). Plus, the scope of the problem Shotwell is addressing -- managing thousands, even tens of thousands of photo files -- is not something I imagine file links being appropriate for most users. As far as your test, I don't know if GLib will ever stop creating FileMonitor objects (by throwing an exception). It may be that you were able to create all those but many of them were broken, that is, not actually monitoring anything. Incidentally, I believe we do monitor symlinked directories, so that won't be necessary. -- Jim On Wed, Sep 7, 2011 at 4:04 PM, Ethan wrote: > On Tue, Sep 6, 2011 at 7:30 PM, Jim Nelson wrote: > >> What I should've asked before was, why can't you simply create a symlink >> from your Pictures directory to the git annex directory? That would solve >> this problem right away, I think. Library monitoring should work as well. >> > > That's a good idea but the filenames would be long and ugly instead of the > symlink filenames :) > Also I'm thinking in terms of XMP sidecars. I'd want the sidecars next to > the symlinks to be used, and don't want sidecars next to the symlink targets > to be used. But I'll accept that this might be idiosyncratic to my use > case. > > I see two or three decisions to be made in regards to symlinked-file > support: > > - Should a broken symlink count as missing files? I propose that whatever > you do for symlinked directories, symlinked files should behave the same > way. (The patch I sent you will mark broken symlinks as missing but only on > startup.) > > - Should monitors be installed on symlink targets? I think it would be > best if we could but you mentioned a system limit on the number of > monitors. I did a test on my system (Ubuntu natty+oneiric, Linux kernel > 3.0.0.9) and wrote a program that opens monitors on every directory in a > directory tree. I ran it on my home directory and it stopped at 31728 -- > this is also the number of directories found by find -type "d". How do you > feel about a patch to unconditionally install monitors on symlinked files' > directories? If that turns out to cause problems, we can keep those > monitors separate and monitor them only as resources allow. > > These are the only perils and pitfalls I can think of. Do you see any I > missed? I think with these changes (and I'll hack them up if you like), > symlinks can be as robust as they can be. > > Ethan > > From mauricio.tellez at gmail.com Wed Sep 28 00:44:17 2011 From: mauricio.tellez at gmail.com (Mauricio Tellez) Date: Tue, 27 Sep 2011 19:44:17 -0500 Subject: [Shotwell] Not importing to my library folder Message-ID: Hi, I'm running ubuntu 11.04 and I have 2 shotwell libraries, so I run shotwell like this (from the command line): 1. shotwell 2. shotwell -d ~/.shotwell_t When I run shotwell witouth -d flag, at the preferences dialog the path to my library is /home/mtellez/multimedia/Photos, and when running with -d .shotwell_t the path is /home/mtellez/.pics So far so good, but yesterday, I notice that all my pics imported from past month to today, are stored in /home/mtellez/.pics no matter wich path is selected at the preferences dialog. When I run shotwell with -d it show me the photos I expect, the only problem is that the last one are at /home/mtellez/.pics instead of /home/mtellez/multimedia/Photos. I try reimporting the pics (and of course double check the path at preferences), moving the files to another folder so they are mark as missing and then drag to shotwell again, but It never get stored at /home/mtellez/multimedia/Photos. Whats wrong? Thnaks in advance! -- Mauricio Tellez From eric at yorba.org Wed Sep 28 00:51:48 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 27 Sep 2011 17:51:48 -0700 Subject: [Shotwell] Not importing to my library folder In-Reply-To: References: Message-ID: On Tue, Sep 27, 2011 at 5:44 PM, Mauricio Tellez wrote: > Hi, I'm running ubuntu 11.04 and I have 2 shotwell libraries, so I run > shotwell like this (from the command line): > > 1. shotwell > 2. shotwell -d ~/.shotwell_t > > When I run shotwell witouth -d flag, at the preferences dialog the path to > my library is /home/mtellez/multimedia/Photos, and when running with -d > .shotwell_t the path is /home/mtellez/.pics > Hi Mauricio, The -d option doesn't change the location of your library folder in the Shotwell preferences. That pref is stored in GConf or GSettings (depending on your Shotwell version) rather than in the Shotwell database. If you want to have separate Shotwell library folders, the easiest way to do this is with multiple user accounts. The hard way would be to write a script that changes the folder in GConf/GSettings -- something that's doable but not supported by us. - Eric From mauricio.tellez at gmail.com Wed Sep 28 00:54:44 2011 From: mauricio.tellez at gmail.com (Mauricio Tellez) Date: Tue, 27 Sep 2011 19:54:44 -0500 Subject: [Shotwell] Not importing to my library folder In-Reply-To: References: Message-ID: Thanks for the reply Eric, so what does the library path at the preferences window? I think that change that before import the imported pics are store at that path. 2011/9/27 Eric Gregory > On Tue, Sep 27, 2011 at 5:44 PM, Mauricio Tellez < > mauricio.tellez at gmail.com> wrote: > >> Hi, I'm running ubuntu 11.04 and I have 2 shotwell libraries, so I run >> shotwell like this (from the command line): >> >> 1. shotwell >> 2. shotwell -d ~/.shotwell_t >> >> When I run shotwell witouth -d flag, at the preferences dialog the path to >> my library is /home/mtellez/multimedia/Photos, and when running with -d >> .shotwell_t the path is /home/mtellez/.pics >> > > Hi Mauricio, > > The -d option doesn't change the location of your library folder in the > Shotwell preferences. That pref is stored in GConf or GSettings (depending > on your Shotwell version) rather than in the Shotwell database. > > If you want to have separate Shotwell library folders, the easiest way to > do this is with multiple user accounts. The hard way would be to write a > script that changes the folder in GConf/GSettings -- something that's doable > but not supported by us. > > - Eric > -- Mauricio Tellez From eric at yorba.org Wed Sep 28 01:02:36 2011 From: eric at yorba.org (Eric Gregory) Date: Tue, 27 Sep 2011 18:02:36 -0700 Subject: [Shotwell] Not importing to my library folder In-Reply-To: References: Message-ID: On Tue, Sep 27, 2011 at 5:54 PM, Mauricio Tellez wrote: > Thanks for the reply Eric, so what does the library path at the preferences > window? I think that change that before import the imported pics are store > at that path. > I'm afraid I don't understand the question... From adam at yorba.org Wed Sep 28 01:48:22 2011 From: adam at yorba.org (Adam Dingle) Date: Wed, 28 Sep 2011 05:48:22 +0400 Subject: [Shotwell] Not importing to my library folder In-Reply-To: References: Message-ID: <4E827CE6.3030607@yorba.org> On 09/28/2011 04:51 AM, Eric Gregory wrote: > On Tue, Sep 27, 2011 at 5:44 PM, Mauricio Tellez > wrote: > >> Hi, I'm running ubuntu 11.04 and I have 2 shotwell libraries, so I run >> shotwell like this (from the command line): >> >> 1. shotwell >> 2. shotwell -d ~/.shotwell_t >> >> When I run shotwell witouth -d flag, at the preferences dialog the path to >> my library is /home/mtellez/multimedia/Photos, and when running with -d >> .shotwell_t the path is /home/mtellez/.pics >> > Hi Mauricio, > > The -d option doesn't change the location of your library folder in the > Shotwell preferences. That pref is stored in GConf or GSettings (depending > on your Shotwell version) rather than in the Shotwell database. Right. Note that we consider this a bug and are hoping to fix it for 0.12: http://redmine.yorba.org/issues/2146 adam From progman32 at gmail.com Wed Sep 28 19:43:21 2011 From: progman32 at gmail.com (Giacomo Ferrari) Date: Wed, 28 Sep 2011 12:43:21 -0700 Subject: [Shotwell] Sharing a photo collection between machines In-Reply-To: References: Message-ID: On Tue, Sep 27, 2011 at 6:30 AM, Stefan Monnier wrote: > > Try using Dropbox to do the synching, with links from your config > > files to ones in the Dropbox folder to maintain consistent views of > > Shotwell across the machines. Should even work with other OSs! > > I'd rather not have to pay 10-20$ per month for the privilege of > depending on some company I don't know. And AFAIK the Dropbox driver is > not Free Software (tho they don't say it out loud: they just don't say > much about it, whereas they clearly say that the nautilus plugin is open > source), so it's not an option for me. > > This said, you got me thinking, and maybe I could use a lightweight > Bazaar checkout, so the (large) repository doesn't have to be copied > onto each and every machine. > > > It sounds a bit dangerous though unless you are confident you can > > enforce the 'only edit on one machine between syncs' rule. > > Yes, in this respect, the support for replicating the database poses > similar issues to the support for sharing the database. > > BTW, this also brings us back to some ealier point in another thread: > if the metadata DB only stores redundant info and can be reconstructed > from the photo files, then the concurrent modification is only really > problematic when it is a modification to the same photo. > > > Stefan > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > You could try using Unison , it handles bidirectional sync well. I've been using it for a few years. Unfortunately, that still leaves the database issues unsolved. Giacomo From dougie at highmoor.co.uk Wed Sep 28 19:47:47 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 28 Sep 2011 20:47:47 +0100 Subject: [Shotwell] shotwell knows best In-Reply-To: <4E8222D3.10204@highmoor.co.uk> References: <4E81A25F.5060303@highmoor.co.uk> <4E8222D3.10204@highmoor.co.uk> Message-ID: <4E8379E3.9090104@highmoor.co.uk> On 27/09/2011 20:24, Dougie Nisbet wrote: > On 27/09/2011 19:41, Eric Gregory wrote: >> >> I believe this is only the expected behavior if you did an import in >> place for that photo the first time you imported it. Is that what >> you did, or are you seeing different behavior? >> > > I never import 'in place'; I always do 'copy'. But it's always > possible that I've been mistaken. Now that I have a better idea of > what I'm looking for I shall take more notice the next time I do an > import/tag/export/rename cycle. > Never say never ... I'm unable to reproduce this so must assume that I'd inadvertently selected 'in place' instead of 'copy'. Dougie From dougie at highmoor.co.uk Wed Sep 28 19:50:12 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Wed, 28 Sep 2011 20:50:12 +0100 Subject: [Shotwell] Two features I'm really missing .... Message-ID: <4E837A74.10301@highmoor.co.uk> 1. Selectively removing tags from one or more images. It would be great to select a group of images, then right-click, remove tags, and have a pop-up list of tags common to the selected images. Removing a particular tag from photos seems quite convoluted. 2. Rapidly locate a particular tag in the hierarchy. For example, for renaming a tag I need to remember 'where I left it', which, at the moment, could be anywhere! Dougie From eric at yorba.org Wed Sep 28 19:50:57 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 28 Sep 2011 12:50:57 -0700 Subject: [Shotwell] shotwell knows best In-Reply-To: <4E8379E3.9090104@highmoor.co.uk> References: <4E81A25F.5060303@highmoor.co.uk> <4E8222D3.10204@highmoor.co.uk> <4E8379E3.9090104@highmoor.co.uk> Message-ID: On Wed, Sep 28, 2011 at 12:47 PM, Dougie Nisbet wrote: > Never say never ... > > I'm unable to reproduce this so must assume that I'd inadvertently selected > 'in place' instead of 'copy'. > Good to know. Thanks for looking into this! - Eric From paulo at matos-sorge.com Wed Sep 28 21:39:36 2011 From: paulo at matos-sorge.com (Paulo J. Matos) Date: Wed, 28 Sep 2011 22:39:36 +0100 Subject: [Shotwell] Halting during import References: <4E5E0A87.4020402@yorba.org> Message-ID: <844nzw9wiv.fsf@matos-sorge.com> Eric Gregory writes: > On Thu, Sep 1, 2011 at 7:21 AM, Paulo J. Matos wrote: > >> I attach the logs however here are some interesting things: >> >> [shotwell.log]: >> L 4850 2011-09-01 11:16:20 [WRN] ImportPage.vala:1392: Unable to fetch >> metadata for /DCIM/100D5000/DSC_0001.NEF: [-1] Error retrieving file object >> for /DCIM/100D5000/DSC_0001.NEF: Unspecified error >> >> >> This is strange. What kind of path is that. The actual path should be >> /media/4FC5-8E2D/DCIM/... >> > > This error comes from GPhoto. The path is the path to your camera or memory > card. Do you get the "unspecified error" every time? > Looks like it. However, I cannot see anything specifically wrong on the interface. How can I try to reproduce this using gphoto alone? > > It sounds like you killed Shotwell during the import, so it didn't create a > thumbnail for the image. Is that the case? If so the best thing to do is > probably to remove those photos from Shotwell and re-import them. > Might be. Is there a way to regenerate thumbnails from within shotwell? Cheers, -- PMatos From vinod at kurup.com Wed Sep 28 21:40:01 2011 From: vinod at kurup.com (Vinod Kurup) Date: Wed, 28 Sep 2011 17:40:01 -0400 Subject: [Shotwell] Segfault importing multiple pictures Message-ID: OS: Ubuntu 10.10 Shotwell version: Shotwell 0.10.1 I have almost 30,000 images in my ~/Pictures folder. When I try to import them, some progress is made and then it segfaults. This is the end of the trace that I see: ... Warning: Directory Image2, entry 0xda55 has unknown Exif (TIFF) type 35147; setting type size 1. Error: Directory Image2, entry 0xda55 has invalid size 713878840*1; skipping entry. Segmentation fault I tried initially with Shotwell 0.7 and then installed 0.10.1 from the PPA. Any other info that would help track this down? Thanks, Vinod -- Vinod Kurup, MD vinod at kurup.com http://kurup.org From eric at yorba.org Wed Sep 28 21:42:40 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 28 Sep 2011 14:42:40 -0700 Subject: [Shotwell] Segfault importing multiple pictures In-Reply-To: References: Message-ID: On Wed, Sep 28, 2011 at 2:40 PM, Vinod Kurup wrote: > OS: Ubuntu 10.10 > Shotwell version: Shotwell 0.10.1 > > I have almost 30,000 images in my ~/Pictures folder. When I try to import > them, some progress is made and then it segfaults. This is the end of the > trace that I see: > > ... > Warning: Directory Image2, entry 0xda55 has unknown Exif (TIFF) type 35147; > setting type size 1. > Error: Directory Image2, entry 0xda55 has invalid size 713878840*1; > skipping > entry. > Segmentation fault > > I tried initially with Shotwell 0.7 and then installed 0.10.1 from the PPA. > Any other info that would help track this down? > Your best bet is to follow the steps outlined here for reporting a but in Shotwell: http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ#I-found-a-bug-in-Shotwell-How-can-I-report-it However, I'd recommend updating to the latest version of Shotwell, 0.11.2, before reporting a bug. It's possible this was fixed already. - Eric From paulo at matos-sorge.com Wed Sep 28 21:41:41 2011 From: paulo at matos-sorge.com (Paulo J. Matos) Date: Wed, 28 Sep 2011 22:41:41 +0100 Subject: [Shotwell] Shotwell 0.11.2 crashes Message-ID: <84zkho8huy.fsf@matos-sorge.com> Hi, I have no idea of what's happening but during import shotwell simply closes (crashes) without any notice whatsoever. The log is attached. Were this a C program I would know how to debug it using gdb -------------- next part -------------- but in Vala I have no idea. Any tips? Cheers, -- PMatos From eric at yorba.org Wed Sep 28 21:52:08 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 28 Sep 2011 14:52:08 -0700 Subject: [Shotwell] Halting during import In-Reply-To: <844nzw9wiv.fsf@matos-sorge.com> References: <4E5E0A87.4020402@yorba.org> <844nzw9wiv.fsf@matos-sorge.com> Message-ID: On Wed, Sep 28, 2011 at 2:39 PM, Paulo J. Matos wrote: > > This error comes from GPhoto. The path is the path to your camera or > memory > > card. Do you get the "unspecified error" every time? > > > > Looks like it. However, I cannot see anything specifically wrong on the > interface. How can I try to reproduce this using gphoto alone? > There's a gphoto command line tool you can install to query the camera and download photos. This too *might* give you some more detailed information, but more likely it will fail the same way Shotwell did. This would help confirm that it's indeed a GPhoto bug, however. > > > > It sounds like you killed Shotwell during the import, so it didn't create > a > > thumbnail for the image. Is that the case? If so the best thing to do > is > > probably to remove those photos from Shotwell and re-import them. > > > > Might be. Is there a way to regenerate thumbnails from within shotwell? > Not directly. For photos, you can "trick" Shotwell into generating new images by selecting photos, hitting the Rotate button, then undoing the rotate. - Eric From eric at yorba.org Wed Sep 28 21:54:09 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 28 Sep 2011 14:54:09 -0700 Subject: [Shotwell] Shotwell 0.11.2 crashes In-Reply-To: <84zkho8huy.fsf@matos-sorge.com> References: <84zkho8huy.fsf@matos-sorge.com> Message-ID: On Wed, Sep 28, 2011 at 2:41 PM, Paulo J. Matos wrote: > I have no idea of what's happening but during import shotwell simply > closes (crashes) without any notice whatsoever. > > The log is attached. Were this a C program I would know how to debug it > using gdb > but in Vala I have no idea. Any tips? > Hi Paulo, A Vala program *is* a C program -- Vala is a source compiler which compiles to C. Unfortunately our mailing list doesn't accept patches. You could either file a new ticket on this, or just e-mail me the log. Please see our bug reporting section in the FAQ for info on creating helpful logs and stack traces for us: http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ#I-found-a-bug-in-Shotwell-How-can-I-report-it - Eric From eric at yorba.org Thu Sep 29 01:43:38 2011 From: eric at yorba.org (Eric Gregory) Date: Wed, 28 Sep 2011 18:43:38 -0700 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: <4E837A74.10301@highmoor.co.uk> References: <4E837A74.10301@highmoor.co.uk> Message-ID: On Wed, Sep 28, 2011 at 12:50 PM, Dougie Nisbet wrote: > 1. Selectively removing tags from one or more images. It would be great to > select a group of images, then right-click, remove tags, and have a pop-up > list of tags common to the selected images. Removing a particular tag from > photos seems quite convoluted. > The "modify tags" dialog works similar to what you've described. Is that not what you're looking for? We also had this feature suggestion: http://redmine.yorba.org/issues/3415 2. Rapidly locate a particular tag in the hierarchy. For example, for > renaming a tag I need to remember 'where I left it', which, at the moment, > could be anywhere! > I know there's been some discussion of keyboard navigation lately for the sidebar. Is that what you have in mind, or something else? - Eric From duyhoustontx at yahoo.com Thu Sep 29 02:58:10 2011 From: duyhoustontx at yahoo.com (Duy Le) Date: Wed, 28 Sep 2011 19:58:10 -0700 (PDT) Subject: [Shotwell] auto Exposure feature Message-ID: <1317265090.27395.YahooMailClassic@web65715.mail.ac4.yahoo.com> Hi, It would be nice to have an auto Exposure feature that is similar to auto Enhance for multiples photos in the library.? This is a huge advantage in saving time and energy since I do not have to auto Enhance each photo individually for a large collection of photos.? For the auto Enhance, I can just select multiples photos and then hit Ctrl+E.? What do you think about the auto Exposure feature?? I can just set a default value on the exposure slider that is to be applied to all the photos and then let Shotwell takes care the rest.? For now, I have to adjust the exposure for each photo, and it takes a long time to go through each one of them individually in a large photo collection. Regards, Duy From dougie at highmoor.co.uk Thu Sep 29 07:43:20 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 29 Sep 2011 08:43:20 +0100 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: References: <4E837A74.10301@highmoor.co.uk> Message-ID: <4E842198.5070506@highmoor.co.uk> On 29/09/2011 02:43, Eric Gregory wrote: > On Wed, Sep 28, 2011 at 12:50 PM, Dougie Nisbet > wrote: > > 1. Selectively removing tags from one or more images. It would be > great to select a group of images, then right-click, remove tags, > and have a pop-up list of tags common to the selected images. > Removing a particular tag from photos seems quite convoluted. > > > The "modify tags" dialog works similar to what you've described. Is > that not what you're looking for? Not really. The 'modify tag' option is fine for single images with just a few tags, but it is greyed-out for multiple selections. And the pop-up window size for the 'modify tags' option is so small that it soon becomes cumbersome for images with lots of tags, where presumable the way to remove the unwanted tag is to manually delete it from the text string. > > We also had this feature suggestion: > http://redmine.yorba.org/issues/3415 > Yes, I shall just need to get used to different ways of working. A typical situation might be where I want to tidy up the tags for a particular event. If I'm working on a batch of photos (import roll, event, or search pattern) I may identify a few photos and manually select them using Ctrl-Click, but if I then locate the tag in the hierarchy and select it, my multi-clicked selection has been unselected. It's the jumping back and forward between views (time/tag) that I find disconcerting. > 2. Rapidly locate a particular tag in the hierarchy. For example, > for renaming a tag I need to remember 'where I left it', which, at > the moment, could be anywhere! > > > I know there's been some discussion of keyboard navigation lately for > the sidebar. Is that what you have in mind, or something else? > I'm thinking along the lines of a Find that works for tags. I think at the moment if I want to rename a tag, the only way is to manually locate it in the hierarchy using the mouse. My main tag bundle is 7 levels deep and it can take me a while to track down the one I want. Dougie From dougie at highmoor.co.uk Thu Sep 29 08:03:16 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 29 Sep 2011 09:03:16 +0100 Subject: [Shotwell] Renaming Events Message-ID: <4E842644.8090506@highmoor.co.uk> On flickr there a tag format convention for a group that I upload photos. The date is formatted in a common way and anyone who copies photos to the group uses the same format, making it easy for visitors to see the event by particular day. In f-spot I used an Events tag with the dates inside; e.g. 24-September-2011. In shotwell there is the automatic event generation which is pretty nifty, and allows renaming. So I can rename Sat, 24 Sep, 2011 -> 24-September-2011. Unfortunately, unless I'm mistaken, this data must be held in the database, and not written as a tag to the file itself. So when it's uploaded to flickr the event does not appear automatically as a tag. I'm assuming this is the same whether photos are 'published' or exported and manually uploaded. Would it be feasible to allow the Event name to be written as part of the exif data? Dougie From oliver at first.in-berlin.de Thu Sep 29 08:34:25 2011 From: oliver at first.in-berlin.de (oliver) Date: Thu, 29 Sep 2011 10:34:25 +0200 Subject: [Shotwell] auto Exposure feature In-Reply-To: <1317265090.27395.YahooMailClassic@web65715.mail.ac4.yahoo.com> References: <1317265090.27395.YahooMailClassic@web65715.mail.ac4.yahoo.com> Message-ID: <20110929083425.GA1659@siouxsie> Instead of aut-foo and auto-bar features AFAIK it would make meore sense to general make tools available to a collection of files. Like Ocaml's List.iter for example. (Or using a fold for also applying statistics maybe?). But in generaol I would not apply automatic tools without looking at the result afterwards. Each picture is individual and some "enhancements" might not look like enhancements. So I would rather not use such features without checking the results. And that again needs exploring individually... Maybe image magick and it's batch processing features are rather what you are looking for? Ciao, OLIVER From paulo at matos-sorge.com Thu Sep 29 10:49:28 2011 From: paulo at matos-sorge.com (Paulo J. Matos) Date: Thu, 29 Sep 2011 11:49:28 +0100 Subject: [Shotwell] Halting during import References: <4E5E0A87.4020402@yorba.org> <844nzw9wiv.fsf@matos-sorge.com> Message-ID: <84y5x7y66f.fsf@matos-sorge.com> Eric Gregory writes: > > Not directly. For photos, you can "trick" Shotwell into generating new > images by selecting photos, hitting the Rotate button, then undoing the > rotate. > OK, I will give that a try. Is there a reason why shotwell doesn't try to regenerate thumbnails when they are missing? -- PMatos From adam at yorba.org Thu Sep 29 11:20:29 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 29 Sep 2011 15:20:29 +0400 Subject: [Shotwell] Halting during import In-Reply-To: <84y5x7y66f.fsf@matos-sorge.com> References: <4E5E0A87.4020402@yorba.org> <844nzw9wiv.fsf@matos-sorge.com> <84y5x7y66f.fsf@matos-sorge.com> Message-ID: <4E84547D.8050003@yorba.org> On 09/29/2011 02:49 PM, Paulo J. Matos wrote: > Eric Gregory writes: >> Not directly. For photos, you can "trick" Shotwell into generating new >> images by selecting photos, hitting the Rotate button, then undoing the >> rotate. >> > OK, I will give that a try. Is there a reason why shotwell doesn't try > to regenerate thumbnails when they are missing? We simply haven't implemented that yet: http://redmine.yorba.org/issues/2889 Maybe for 0.12. adam From adam at yorba.org Thu Sep 29 12:07:02 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 29 Sep 2011 16:07:02 +0400 Subject: [Shotwell] Renaming Events In-Reply-To: <4E842644.8090506@highmoor.co.uk> References: <4E842644.8090506@highmoor.co.uk> Message-ID: <4E845F66.2070401@yorba.org> On 09/29/2011 12:03 PM, Dougie Nisbet wrote: > On flickr there a tag format convention for a group that I upload > photos. The date is formatted in a common way and anyone who copies > photos to the group uses the same format, making it easy for visitors > to see the event by particular day. > > In f-spot I used an Events tag with the dates inside; e.g. > 24-September-2011. In shotwell there is the automatic event generation > which is pretty nifty, and allows renaming. So I can rename Sat, 24 > Sep, 2011 -> 24-September-2011. Unfortunately, unless I'm mistaken, > this data must be held in the database, and not written as a tag to > the file itself. That's correct. > So when it's uploaded to flickr the event does not appear > automatically as a tag. I'm assuming this is the same whether photos > are 'published' or exported and manually uploaded. > > Would it be feasible to allow the Event name to be written as part of > the exif data? Yes, this is under consideration: http://redmine.yorba.org/issues/3567 adam From eric at yorba.org Thu Sep 29 18:52:37 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 29 Sep 2011 11:52:37 -0700 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: <4E842198.5070506@highmoor.co.uk> References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> Message-ID: On Thu, Sep 29, 2011 at 12:43 AM, Dougie Nisbet wrote: > > Not really. The 'modify tag' option is fine for single images with just a > few tags, but it is greyed-out for multiple selections. And the pop-up > window size for the 'modify tags' option is so small that it soon becomes > cumbersome for images with lots of tags, where presumable the way to remove > the unwanted tag is to manually delete it from the text string. > Seems like there's two issues here: 1. The modify tags dialog only works for one image at a time. I filed a ticket to change this: http://redmine.yorba.org/issues/4206 2. Not enough space in the dialog box. It's a re-sizable window, but that's not really the best solution. We've talked about various possible changes to this dialog in the past, maybe it's something we need to think about again soon. I'm thinking along the lines of a Find that works for tags. I think at the > moment if I want to rename a tag, the only way is to manually locate it in > the hierarchy using the mouse. My main tag bundle is 7 levels deep and it > can take me a while to track down the one I want. > The Find toolbar works for tags; just hit F8 and you can search through your current view for a given tag. Or you could set up a saved search for more complex tag searches. - Eric From jim at yorba.org Thu Sep 29 19:15:23 2011 From: jim at yorba.org (Jim Nelson) Date: Thu, 29 Sep 2011 12:15:23 -0700 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> Message-ID: > 2. Not enough space in the dialog box. It's a re-sizable window, but that's > not really the best solution. We've talked about various possible changes > to > this dialog in the past, maybe it's something we need to think about again > soon. > Incidentally, we have a ticket for that as well: http://redmine.yorba.org/issues/3510* * -- Jim* * From dougie at highmoor.co.uk Thu Sep 29 19:20:24 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 29 Sep 2011 20:20:24 +0100 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> Message-ID: <4E84C4F8.80507@highmoor.co.uk> On 29/09/2011 19:52, Eric Gregory wrote: > It's a re-sizable window, So it is. I hadn't spotted that before. That helps quite a bit. > > The Find toolbar works for tags; just hit F8 and you can search > through your current view for a given tag. I'm not sure it does, or I understand. Certainly, it can find text strings that are a substring of a tag, but if doesn't offer autocompletion of tags, or zoom into the tag in the tag pane. > Or you could set up a saved search for more complex tag searches. > I noticed (for the first time) that the search bar offers a clickable choice or photos, video, or raw. I miss the auto-completion ability to search on an individual tag, or combination of tags using boolean logic. Perhaps this could be an option in the customized searches. Dougie From dougie at highmoor.co.uk Thu Sep 29 19:31:52 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Thu, 29 Sep 2011 20:31:52 +0100 Subject: [Shotwell] Two features I'm really missing .... In-Reply-To: References: <4E837A74.10301@highmoor.co.uk> <4E842198.5070506@highmoor.co.uk> Message-ID: <4E84C7A8.7060502@highmoor.co.uk> On 29/09/2011 20:15, Jim Nelson wrote: > > Incidentally, we have a ticket for that as well: > http://redmine.yorba.org/issues/3510* > * I'm all for innovation and progress and don't want to fall into the 'but software x does it this way' trap, but, er, this is something that f-spot does this really well. Single keypress, (t) for tags, then auto-completion on tab-press, or cycling through valid tags (just like bash shell). It also allows editing (like 'Modify Tag') in the same way as shotwell, by simply deleting a tag from the photo. Elegant and intuitive. Dougie From adalbert.prokop at gmx.de Thu Sep 29 20:21:55 2011 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Thu, 29 Sep 2011 22:21:55 +0200 Subject: [Shotwell] Deleted files reappear after restart / default developer is not used Message-ID: <4E84D363.3060707@gmx.de> Hello! First: Thanks for the nice peace of software! :) In the process of getting familiar with Shotwell, I've noticed two possible bugs. Version 0.11.1 I've selected "Camera" as the default raw developer. I'm importing picture from my camera (is the type important?), but they appear as pinkish or reddish images, as they would if I used "Shotwell" as the developer. If I select those images and change the developer to "Shotwell" and then to "Camera" again, they will be displayed correctly. Version 0.11.2 I've imported some pictures from my camera (RAW+JPG). If I delete some of them, the will be moved to Shotwell's trash bin - that's fine. Now I select "Empty trash". On some occasion a message appears telling me that the file cannot be moved to desktop trash and asking, if I want to remove it permanently. Regardless of which answer I choose ("Keep" or "Delete"), the behavior seems to be the same: The picture is remove from Shotwell's trash and the JPEG file is deleted, but the raw file remains. On next start, the automatic import is triggered the raw files will be re-imported and sorted into a new event. -- best wishes Adalbert Teutonic: Not enough gin. From eric at yorba.org Thu Sep 29 22:24:35 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 29 Sep 2011 15:24:35 -0700 Subject: [Shotwell] auto Exposure feature In-Reply-To: <1317265090.27395.YahooMailClassic@web65715.mail.ac4.yahoo.com> References: <1317265090.27395.YahooMailClassic@web65715.mail.ac4.yahoo.com> Message-ID: On Wed, Sep 28, 2011 at 7:58 PM, Duy Le wrote: > Hi, > It would be nice to have an auto Exposure feature that is similar to auto > Enhance for multiples photos in the library. This is a huge advantage in > saving time and energy since I do not have to auto Enhance each photo > individually for a large collection of photos. For the auto Enhance, I can > just select multiples photos and then hit Ctrl+E. > > What do you think about the auto Exposure feature? I can just set a > default value on the exposure slider that is to be applied to all the photos > and then let Shotwell takes care the rest. For now, I have to adjust the > exposure for each photo, and it takes a long time to go through each one of > them individually in a large photo collection. > I'm not sure we'd want to do an auto-exposure feature; but the idea of applying one set of color adjustments to multiple photos is ticketed here: http://redmine.yorba.org/issues/2517 I know that's not *quite* what you'd asked for, but that's the direction we're learning on this. Would that work for you? - Eric From eric at yorba.org Thu Sep 29 22:40:03 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 29 Sep 2011 15:40:03 -0700 Subject: [Shotwell] Deleted files reappear after restart / default developer is not used In-Reply-To: <4E84D363.3060707@gmx.de> References: <4E84D363.3060707@gmx.de> Message-ID: On Thu, Sep 29, 2011 at 1:21 PM, Adalbert Prokop wrote: > Version 0.11.1 > > I've selected "Camera" as the default raw developer. I'm importing > picture from my camera (is the type important?), but they appear as > pinkish or reddish images, as they would if I used "Shotwell" as the > developer. If I select those images and change the developer to > "Shotwell" and then to "Camera" again, they will be displayed correctly. > This is a known issue and is slated to be fixed in Shotwell 0.12. http://redmine.yorba.org/issues/4139 > Version 0.11.2 > > I've imported some pictures from my camera (RAW+JPG). If I delete some > of them, the will be moved to Shotwell's trash bin - that's fine. Now I > select "Empty trash". On some occasion a message appears telling me that > the file cannot be moved to desktop trash and asking, if I want to > remove it permanently. > > Regardless of which answer I choose ("Keep" or "Delete"), the behavior > seems to be the same: > > The picture is remove from Shotwell's trash and the JPEG file is > deleted, but the raw file remains. On next start, the automatic import > is triggered the raw files will be re-imported and sorted into a new event. > Interesting. I filed a new ticket on this one: http://redmine.yorba.org/issues/4207 If we can reproduce this one in-house, we'll take a look at it for 0.12. Thanks! - Eric From mauricio.tellez at gmail.com Fri Sep 30 01:19:56 2011 From: mauricio.tellez at gmail.com (Mauricio Tellez) Date: Thu, 29 Sep 2011 20:19:56 -0500 Subject: [Shotwell] Exporting entire library Message-ID: Hi, I have two libraries, at diferent folders each, but I'm no sure how, one library split between both folders. I'm trying to unify one library so all the pics from that library are at the same folder, the problem is that I don't know which pics are in the right folder (I know there is a "show in filemanager" but with 10,000+ pics this is not an option). So, I tried to export my entire library so I can delete all my pics and then reimported all my pics, hoping all get imported together. But when I try to import, I get a lot of "duplicate filename window" because all files are exporte in one directory. How can import mimic the library's folder hierachy? Thanks in advance. -- Mauricio Tellez From eric at yorba.org Fri Sep 30 01:51:20 2011 From: eric at yorba.org (Eric Gregory) Date: Thu, 29 Sep 2011 18:51:20 -0700 Subject: [Shotwell] Exporting entire library In-Reply-To: References: Message-ID: On Thu, Sep 29, 2011 at 6:19 PM, Mauricio Tellez wrote: > Hi, I have two libraries, at diferent folders each, but I'm no sure how, > one > library split between both folders. I'm trying to unify one library so all > the pics from that library are at the same folder, the problem is that I > don't know which pics are in the right folder (I know there is a "show in > filemanager" but with 10,000+ pics this is not an option). So, I tried to > export my entire library so I can delete all my pics and then reimported > all > my pics, hoping all get imported together. But when I try to import, I get > a > lot of "duplicate filename window" because all files are exporte in one > directory. How can import mimic the library's folder hierachy? Thanks in > advance. > Merging libraries is not an easy task; it's especially difficult if you don't have the photos for each library in a distinct folder (i.e. Pictures.) That said, I'm a bit confused as to what exactly you're trying to do. Exporting the photos is only necessary if you want to preserve edits made within Shotwell (red eye, enhance, etc.). Tags and titles can be preserved if you enable metadata writing in Shotwell -- these are written into the photo files themselves (for JPEGs, not RAW or video) which are then read back when you import the file. There is no way currently to export to multiple directories. - Eric From mauricio.tellez at gmail.com Fri Sep 30 02:23:08 2011 From: mauricio.tellez at gmail.com (Mauricio Tellez) Date: Thu, 29 Sep 2011 21:23:08 -0500 Subject: [Shotwell] Exporting entire library In-Reply-To: References: Message-ID: Hi Eric, Supose I have 2 set of photos: Set A: 1.jpg, 2.jpg 3.jpg, 4.jpg and 5.jpg Set B: a1.jpg, 2.jpg, b1.jpg, 4.jpg and cvb.jpg As you can see 2.jpg and 4.jpg has the same name but are diferent pics. My original idea was create 2 libraries, one for set A, one for set B, like this: /path/library1 ->2011 ------>01 ------------>05 1.jpg ------------>08 2.jpg ------->03 ------------->01 3.jpg ------->07 ------------->02 4.jpg, 5.jpg /path/library2 ->2011 ------->02 -------------->01 a1.jpg ------->03 -------------->05 2.jpg b1.jpg -------------->08 4.jpg cvb.jpg It work fine for a time, but suddenly some photos of library1 was at the path of library2, like this: /path/library2 ->2011 ------>01 ------------>08 2.jpg <--- This belongs to library 1 ------->02 -------------->01 a1.jpg ------->03 -------------->05 2.jpg b1.jpg -------------->08 4.jpg cvb.jpg so I want to move it to the path of library one. In my example because of the little amount of pics I can search through the folders, and reimport them, but In my real library there is a huge amount of folders and subfolders. That's why I tried to export the entire library to a folder so I can reimport all again hoping to import in the same path library. But because there is photos with same name, I can't do that. I hope I was a little clear now (my english isn't very good), and you can help me. Thanks. 2011/9/29 Eric Gregory > On Thu, Sep 29, 2011 at 6:19 PM, Mauricio Tellez < > mauricio.tellez at gmail.com> wrote: > >> Hi, I have two libraries, at diferent folders each, but I'm no sure how, >> one >> library split between both folders. I'm trying to unify one library so all >> the pics from that library are at the same folder, the problem is that I >> don't know which pics are in the right folder (I know there is a "show in >> filemanager" but with 10,000+ pics this is not an option). So, I tried to >> export my entire library so I can delete all my pics and then reimported >> all >> my pics, hoping all get imported together. But when I try to import, I get >> a >> lot of "duplicate filename window" because all files are exporte in one >> directory. How can import mimic the library's folder hierachy? Thanks in >> advance. >> > > Merging libraries is not an easy task; it's especially difficult if you > don't have the photos for each library in a distinct folder (i.e. Pictures.) > > That said, I'm a bit confused as to what exactly you're trying to do. > Exporting the photos is only necessary if you want to preserve edits made > within Shotwell (red eye, enhance, etc.). Tags and titles can be preserved > if you enable metadata writing in Shotwell -- these are written into the > photo files themselves (for JPEGs, not RAW or video) which are then read > back when you import the file. > > There is no way currently to export to multiple directories. > > - Eric > -- Mauricio Tellez From photon3000 at hotmail.com Fri Sep 30 13:29:12 2011 From: photon3000 at hotmail.com (Dirk Nelson) Date: Fri, 30 Sep 2011 08:29:12 -0500 Subject: [Shotwell] auto Exposure feature In-Reply-To: <1317388329.84176.YahooMailClassic@web65706.mail.ac4.yahoo.com> References: <1317388329.84176.YahooMailClassic@web65706.mail.ac4.yahoo.com> Message-ID: I really like the idea of applying a set of color adjustments to multiple photos. I like to take pictures in aquarium and museum, and the ambient light condition is kind of dark. Having this feature would be helpful to adjust the colors on a set of photos. - Dirk --- On Thu, 9/29/11, Eric Gregory wrote: From: Eric Gregory Subject: Re: [Shotwell] auto Exposure feature To: "Duy Le" Cc: shotwell at lists.yorba.org Date: Thursday, September 29, 2011, 5:24 PM On Wed, Sep 28, 2011 at 7:58 PM, Duy Le wrote: Hi, It would be nice to have an auto Exposure feature that is similar to auto Enhance for multiples photos in the library. This is a huge advantage in saving time and energy since I do not have to auto Enhance each photo individually for a large collection of photos. For the auto Enhance, I can just select multiples photos and then hit Ctrl+E. What do you think about the auto Exposure feature? I can just set a default value on the exposure slider that is to be applied to all the photos and then let Shotwell takes care the rest. For now, I have to adjust the exposure for each photo, and it takes a long time to go through each one of them individually in a large photo collection. I'm not sure we'd want to do an auto-exposure feature; but the idea of applying one set of color adjustments to multiple photos is ticketed here: http://redmine.yorba.org/issues/2517 I know that's not *quite* what you'd asked for, but that's the direction we're learning on this. Would that work for you? - Eric From eric at yorba.org Fri Sep 30 18:44:26 2011 From: eric at yorba.org (Eric Gregory) Date: Fri, 30 Sep 2011 11:44:26 -0700 Subject: [Shotwell] Exporting entire library In-Reply-To: References: Message-ID: Couldn't you just start Shotwell with library 1, then import all the photos in library 2? Shotwell won't overwrite photos of the same name on import. The duplicate detection is based on a file hash, not on the file name. - Eric