From adam at yorba.org Mon Apr 5 14:44:02 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 05 Apr 2010 07:44:02 -0700 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <4BB0FE5A.6050602@techfak.uni-bielefeld.de> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <4BA67ACC.4040300@techfak.uni-bielefeld.de> <4BA6C359.8080408@yorba.org> <4BB0FE5A.6050602@techfak.uni-bielefeld.de> Message-ID: <4BB9F732.8040702@yorba.org> An HTML attachment was scrubbed... URL: From adam at yorba.org Mon Apr 5 15:03:00 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 05 Apr 2010 08:03:00 -0700 Subject: [Shotwell] Wishlist: Database updates, lighttable, easier deletion, aspect ratio In-Reply-To: <1264531358.2294.25.camel@mk64> References: <1264531358.2294.25.camel@mk64> Message-ID: <4BB9FBA4.5050102@yorba.org> Mark, here's a quick response to some ideas you sent to the Shotwell mailing list some time ago. > * When I delete an image in the filemanager or the terminal, it is still > existing in shotwells database. Add a single-button refresh database > function to get rid of these phantoms. > We could do that, but I think we'd rather make Shotwell smart enough to notice when images have been deleted and react automatically - this is http://trac.yorba.org/ticket/374 , more or less. > * Add some kind of lighttable-area (maybe in the left panel?), to which > images may easily be drag-and-dropped. A lighttabe could open like an > event and could be used for ordering prints for example. Maybe it could > make sense to save a collection in the database for later use? > Tags (new in Shotwell 0.5) are sort of like this: once you've created a tag, you can drag as many images onto it as you like, and you can open a tag just like an event. > * deleting images is not simple in shotwell, because shotwell asks how > to handle imagefiles every time. eog for example gives an option to keep > the way it deletes for the session. Browsing and deleting images using > the keyboard is not easy fun because ALT-L is way more complicated than > single button removal. > Right. We're considering implementing a trash can in Shotwell; once we have this, you'll be able to delete images simply by pressing Delete, which will move them to the trash without confirmation. This is http://trac.yorba.org/ticket/594 . > * add a single way to change the aspect ration - many digital cameras > take pictures in a ratio 4/3 instead of traditional 3/2. An automatic > funktion to switch the ratio whith the possibility to adjust the image > would be great! (something like a frame of the full width of an photo > that could be moved to the top or the bottom) > Shotwell's crop tool allows you to choose an aspect ration for cropping. It sounds like you'd like to be able to crop a set of photos to a given aspect ratio in one batch operation. That's a reasonable idea; feel free to create a ticket for this in our bug database at trac.yorba.org . Thanks for the suggestions! adam From iluetkeb at techfak.uni-bielefeld.de Mon Apr 5 18:57:41 2010 From: iluetkeb at techfak.uni-bielefeld.de (=?ISO-8859-1?Q?Ingo_L=FCtkebohle?=) Date: Mon, 05 Apr 2010 20:57:41 +0200 Subject: [Shotwell] Features for Shotwell 0.6 In-Reply-To: <4BB9F732.8040702@yorba.org> References: <7c6db8601003140930o3c2c19ahd97d91790f69982a@mail.gmail.com> <4BA67ACC.4040300@techfak.uni-bielefeld.de> <4BA6C359.8080408@yorba.org> <4BB0FE5A.6050602@techfak.uni-bielefeld.de> <4BB9F732.8040702@yorba.org> Message-ID: <4BBA32A5.1040704@techfak.uni-bielefeld.de> Hi Adam, Am 05.04.2010 16:44, schrieb Adam Dingle: > - a plugin-based API where Shotwell dynamically loads plugins at startup (like > gedit or GIMP). > > - a shared libary (libshotwell) which any application can use to interact with > the photo database. > > - a D-BUS or REST-based API which allows external programs to interact with the > running Shotwell instance. I would also add that, irrespective of the means of communication, there are two different extension choices: * A "plug-in" system suggests that Shotwell is enhanced, i.e. through new menu items or dialogs. It is not important for that whether the plug-ins run in process or not. * In contrast, a "service" model looks basically at "other programs accessing the same database in a coherent manner". Historically, your first option has mostly been used to achieve choice 1 and this is likely the easiest way, due to the ease of adding API for providing a GUI within another program. > It's true that a disadvantage of plugins is that menus can become cluttered if > the user loads lots of plugins. Of the other approaches, I see some advantages > of a shared library over D-BUS/REST as a means of providing database access. In > particular, with a shared libary, external programs can interact with the > database even if Shotwell isn't running. That is true, but could also be achieved through a daemon model. > With a shared library, we also wouldn't > need to concern ourselves with serialization via D-BUS or REST: external > programs could interact with the database using the same calls which Shotwell > itself for database access. Also true. Hpwever, at least with REST, if you're clever, you can minimize that quite a bit. Think of HTTP's four basic operations (GET, POST, PUT, DELETE) and one or two content types (images/metadata). After that, adding URIs for different functions is much less work. > I think it's safe to say that none of the above will happen for Shotwell 0.6 > (tentatively planned for June) but we can consider all of the above for future > releases. great to know, thanks :-) cheers, Ingo From adam at yorba.org Tue Apr 6 14:41:12 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 06 Apr 2010 07:41:12 -0700 Subject: [Shotwell] Alternative mailinglist archive for better readability In-Reply-To: References: Message-ID: <4BBB4808.4050805@yorba.org> Jarno, > First of all, I would like to thank all of you for making Shotwell an > interesting alternative for f-spot and other photo management > applications in linux desktop. You're welcome! :) > While browsing through Shotwell's > mailing list archive, I was again reminded how stiff the basic mailing > list archive system feels. Banshee-project[1] has been using nabble[2] > as their alternative mailing list interface[3] and I think it's quite > great improvement to the regular interface. Do you think you could > make Shotwell's mailing list available in nabble? > > [1] http://banshee-project.org/ > [2] http://www.nabble.com/ > [3] http://banshee-project.org/support/forum/ Sure - I've now set this up. You can find the Nabble archive at http://www.nabble.com/Shotwell-f3510.html Note that old messages are not present in the Nabble archive, but all new messages sent from this point onward will show up in the archive. I hope this will be useful for you. cheers adam From tommy.he at linux.com Wed Apr 7 22:30:45 2010 From: tommy.he at linux.com (Tommy He) Date: Wed, 7 Apr 2010 23:30:45 +0100 Subject: [Shotwell] MicroBlog for shotwell users Message-ID: Hello, Curiously, do we have a shotwell group on popular microblog services ? e.g. identi.ca. With the acceptance of shotwell as the default photo manager for the coming distro after Easter (Ubuntu 10.04, Fedora 13), the user base of shotwell will see a huge increase. It would be great if we end users could have a place on microblog to discuss our favourite photo manager. Just a suggestion. :-) Kind regards, Tommy He -- Take a Deep Breath out of Windows From matthias.clasen at gmail.com Wed Apr 7 22:58:15 2010 From: matthias.clasen at gmail.com (Matthias Clasen) Date: Wed, 7 Apr 2010 18:58:15 -0400 Subject: [Shotwell] MicroBlog for shotwell users In-Reply-To: References: Message-ID: On Wed, Apr 7, 2010 at 6:30 PM, Tommy He wrote: > Hello, > > Curiously, do we have a shotwell group on popular microblog services ? e.g. > identi.ca. > > With the acceptance of shotwell as the default photo manager for the coming > distro after Easter (Ubuntu 10.04, Fedora 13), the user base of shotwell > will see a huge increase. I was under the impression Ubuntu would default to f-spot with some homegrown editing mode additions ? If you want shotwell as the default photo manager, Fedora is the distro of choice :) From adam at yorba.org Tue Apr 13 16:58:02 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 13 Apr 2010 09:58:02 -0700 Subject: [Shotwell] RAW support in Shotwell Message-ID: <4BC4A29A.2070904@yorba.org> Shotwell friends and fans, as some of you know, we've been working on adding limited RAW support to Shotwell. Shotwell 0.6 (which we're tentatively planning to release in June) will allow you to import RAW photos from a camera, to view them, and to open them in an external RAW editor. I should point out, though, that in Shotwell 0.6 when you view a RAW photo you will actually be viewing a JPEG image generated from the RAW image. You will be able to use Shotwell's editing tools to adjust RAW photos but, again, you will actually be adjusting the JPEG image generated from the RAW image. In the future we hope to give Shotwell a new 16-bit color image pipeline (probably using the GEGL library used by GIMP) and at that point Shotwell will be able to display true RAW data that has never been transformed to a JPEG, but that is probably a few releases away. So, then, how should Shotwell 0.6 construct a JPEG to be used for displaying each RAW photo? There are a few possible mechanisms: 1. Shotwell can use libraw (http://www.libraw.org), which is derived from dcraw (http://www.cybercom.net/~dcoffin/dcraw/), to process the RAW image and generate pixel data for a JPEG. This is implemented in the Shotwell trunk today. One problem is that libraw may not be able to generate a reasonable image for RAW photos from all cameras. For example my Canon PowerShot S90 generates images with significant barrel distortion that needs to be corrected in software, but libraw cannot do that. 2. If the user puts the camera in RAW+JPEG mode so it generates both a RAW and a JPEG image for each shot, then Shotwell could import the RAW and JPEG images together and display them as a single photo in the library. Shotwell could use the camera-generated JPEG for display purposes, but the underlying RAW image would still be available to open in an external editor. 3. Many cameras embed JPEG previews in RAW images themselves. For example, my S90 stores a 1600x1200 JPEG inside each RAW file. Shotwell could optionally use the embedded JPEG for displaying RAW photos. Of course, the embedded JPEGs will probably be smaller than the RAW photos, but a size such as 1600x1200 is still plenty big enough to work with on most monitors. A question for you, Shotwell users: which of the above mechanisms do you think you would want to use if available? adam From adam at yorba.org Tue Apr 13 17:20:34 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 13 Apr 2010 10:20:34 -0700 Subject: [Shotwell] storing original and modified photos Message-ID: <4BC4A7E2.1080106@yorba.org> Shotwell friends/fans, as you all know, Shotwell is a non-destructive photo editor. If you edit a photo, then today Shotwell writes out a full-resolution JPEG including your changes only when you export. We're considering enhancing Shotwell so that it generates a new full-resolution JPEG immediately after you make any edit (this would probably happen in the background, so the user interface wouldn't slow down due to this change). This change would have several benefits. Since full-resolution modified copies would always be available, we'd easily be able to drag/drop to applications other than Nautilus (http://trac.yorba.org/ticket/1563). Also, browsing through modified photos would be faster than it is today because we wouldn't need to apply your edits on the fly each time you move to a new photo. Of course, Shotwell would still keep the original photos and remember all edits you've made, just like today. If Shotwell does store modified copies of each photo, though, where should it keep them? There are a few possibilities: 1. The original library directory (e.g. ~/Pictures) is unmodified. Shotwell keeps each modified photo in its own directory, e.g. ~/.shotwell/modified_photos. 2. Whenever any photo has been modified, Shotwell moves the original photo to its own directory (e.g. ~/.shotwell/original_photos) and writes modified photos into the library directory (e.g. ~/Pictures) directly. When you revert to original, Shotwell moves the original photo back into the library directory. 3. Shotwell keeps original and modified photos side by side in the library directory. We could either (a) keep the original photo DSC_001.JPG untouched, and create a new file DSC_001_MOD.JPG, or (b) rename the original photo to DSC_001_ORIG.JPG, and write the modifications into the original file DSC_001.JPG. Note that Shotwell would also likely store tag and title data in IPTC or XMP tags in each modified photo file. A potential advantage of (1) is that the original library is unmodified. A potential advantage of (2) is that it might be easier to share the photo library with other photo applications: for example, photo edits made in Shotwell would show up in those applications immediately if they are also viewing the ~/Pictures library. So, Shotwell users: which of the above approaches would you prefer for Shotwell to take? adam From sat at elsaturnino.com Tue Apr 13 18:31:53 2010 From: sat at elsaturnino.com (Saturnino Garcia) Date: Tue, 13 Apr 2010 11:31:53 -0700 Subject: [Shotwell] storing original and modified photos In-Reply-To: <4BC4A7E2.1080106@yorba.org> References: <4BC4A7E2.1080106@yorba.org> Message-ID: Of the three options, I personally like option #3 the best but would consider option #1 acceptable also. I would hate to see you do option #2 because it is counterintuitive. If I import photos somewhere, I expect to be able to go there to find them again. If I wanted to import the originals into another program then I would have to specify a shotwell specific directory; this might lead to all sorts of confusion down the road. Also, is the plan to have a new version of the file saved for every edit you make? Or maybe there will be a single edited version that gets updated with every edit? - Sat On Tue, Apr 13, 2010 at 10:20 AM, Adam Dingle wrote: > Shotwell friends/fans, > > as you all know, Shotwell is a non-destructive photo editor. If you > edit a photo, then today Shotwell writes out a full-resolution JPEG > including your changes only when you export. > > We're considering enhancing Shotwell so that it generates a new > full-resolution JPEG immediately after you make any edit (this would > probably happen in the background, so the user interface wouldn't slow > down due to this change). This change would have several benefits. > Since full-resolution modified copies would always be available, we'd > easily be able to drag/drop to applications other than Nautilus > (http://trac.yorba.org/ticket/1563). Also, browsing through modified > photos would be faster than it is today because we wouldn't need to > apply your edits on the fly each time you move to a new photo. Of > course, Shotwell would still keep the original photos and remember all > edits you've made, just like today. > > If Shotwell does store modified copies of each photo, though, where > should it keep them? There are a few possibilities: > > 1. The original library directory (e.g. ~/Pictures) is unmodified. > Shotwell keeps each modified photo in its own directory, e.g. > ~/.shotwell/modified_photos. > > 2. Whenever any photo has been modified, Shotwell moves the original > photo to its own directory (e.g. ~/.shotwell/original_photos) and writes > modified photos into the library directory (e.g. ~/Pictures) directly. > When you revert to original, Shotwell moves the original photo back into > the library directory. > > 3. Shotwell keeps original and modified photos side by side in the > library directory. We could either (a) keep the original photo > DSC_001.JPG untouched, and create a new file DSC_001_MOD.JPG, or (b) > rename the original photo to DSC_001_ORIG.JPG, and write the > modifications into the original file DSC_001.JPG. > > Note that Shotwell would also likely store tag and title data in IPTC or > XMP tags in each modified photo file. > > A potential advantage of (1) is that the original library is > unmodified. A potential advantage of (2) is that it might be easier to > share the photo library with other photo applications: for example, > photo edits made in Shotwell would show up in those applications > immediately if they are also viewing the ~/Pictures library. > > So, Shotwell users: which of the above approaches would you prefer for > Shotwell to take? > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From aquarichy at gmail.com Tue Apr 13 18:47:45 2010 From: aquarichy at gmail.com (Richard Schwarting) Date: Tue, 13 Apr 2010 14:47:45 -0400 Subject: [Shotwell] PicasaWeb support Message-ID: Hello. Last year, Philip Withnall asked about PicasaWeb support with consideration for libgdata's PicasaWeb support.[1] Since then, it appears Shotwell as acquired its own PicasaWeb upload support.[2][3] Also since then, libgdata is now in use by Eye of GNOME Plugin's new plugin Postasa (like their Postr plugin for Flickr) to upload photos to PicasaWeb. I was wondering whether Yorba and the Shotwell community would prefer maintaining their own support, or whether they'd be open to having said support replaced with something smaller that relies on libgdata and its Vala bindings. As the author of Postasa and most of the PicasaWeb support in libgdata, I'd be volunteering for this. In particular, if there are any features absent from Shotwell's PicasaWeb support that are desired, I'd be happy to add them to libgdata. I understand, however, if the current Shotwell PicasaWeb support is adequate and you'd prefer to keep it around. I do have experience with Vala as I do half of my private coding in it now. Sorry that I didn't volunteer earlier. I actually wasn't aware of Shotwell's existence until the Fedora 13 Beta release notice that was sent out today.[4] Cheers, Richard Schwarting 1. http://lists.yorba.org/pipermail/shotwell/2009-August/000012.html 2. http://trac.yorba.org/ticket/667 3. http://trac.yorba.org/browser/shotwell/trunk/src/PicasaConnector.vala 4. http://fedoraproject.org/wiki/F13_Beta_announcement From adam at yorba.org Tue Apr 13 22:12:12 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 13 Apr 2010 15:12:12 -0700 Subject: [Shotwell] storing original and modified photos In-Reply-To: References: <4BC4A7E2.1080106@yorba.org> Message-ID: <4BC4EC3C.4090309@yorba.org> > Also, is the plan to have a new version of the file saved for every edit you > make? Or maybe there will be a single edited version that gets updated with > every edit? There will be a single edited version that gets updated with every edit. adam From pnovak at alumni.caltech.edu Thu Apr 15 04:13:03 2010 From: pnovak at alumni.caltech.edu (Paul Novak) Date: Wed, 14 Apr 2010 21:13:03 -0700 Subject: [Shotwell] crop_tool_window layout changes when selecting "Custom" cropping Message-ID: <4BC6924F.6030605@alumni.caltech.edu> Hello, I have built shotwell from SVN on Fedora 12. When I use the crop tool, and select the "Custom" crop constraint, the layout of the crop tool window changes so the "Cancel" and "OK" buttons are on the left. This layout persists when I change to any other crop constraint. I think this happens because the tool window layout is initialized by (from EditingTools.vala) Gtk.HBox response_layout = new Gtk.HBox(true, CONTROL_SPACING); response_layout.add(cancel_button); response_layout.add(ok_button); layout = new Gtk.HBox(false, CONTROL_SPACING); layout.add(constraint_combo); layout.add(pivot_reticle_button); layout.add(response_layout); but when the constraint type changes, response_layout is not removed, just its children, cancel_button and the ok_button. I'm not sure how to fix it, because I don't know how to access response_layout to remove its children first (cancel_button and ok_button), and then remove response_layout. I'd be glad to create the patch if someone pointed me in the right direction. Thanks, Paul From kaj-ivar at vanderwijst.com Thu Apr 15 14:41:41 2010 From: kaj-ivar at vanderwijst.com (Kaj-Ivar van der Wijst) Date: Thu, 15 Apr 2010 16:41:41 +0200 Subject: [Shotwell] Fwd: shotwell flickr group Message-ID: <4BC725A5.3000301@vanderwijst.com> Hi Shotwell users, I just recieved this email about the creation of a Shotwell Flickr Group. What do you think, should we add / feature it on the website? Have a nice day everyone, Kaj-Ivar -------- Originele bericht -------- Onderwerp: shotwell flickr group Datum: Thu, 15 Apr 2010 10:05:55 -0400 Van: Anderson Silva Aan: kaj-ivar at vanderwijst.com I just created one for the app: http://www.flickr.com/groups/shotwell Thought you guys may want to use it as a marketing tool for the project or what not. AS -- http://www.the-silvas.com From jim at yorba.org Thu Apr 15 18:00:06 2010 From: jim at yorba.org (Jim Nelson) Date: Thu, 15 Apr 2010 11:00:06 -0700 Subject: [Shotwell] crop_tool_window layout changes when selecting "Custom" cropping In-Reply-To: <4BC6924F.6030605@alumni.caltech.edu> References: <4BC6924F.6030605@alumni.caltech.edu> Message-ID: Hi Paul, Yes, that's certainly not behavior by design. I've created a ticket for this: http://trac.yorba.org/ticket/1795 We'd love it if you patched this. The code you mentioned is exactly where you want to start: in EditingTools.vala, the CropToolWindow class. That class is internal to CropTool, which does a lot of the work to rearrange the controls when the custom constraint is selected. I suspect most (if not all) of the patch would be in these two classes. -- Jim On Wed, Apr 14, 2010 at 9:13 PM, Paul Novak wrote: > Hello, > > I have built shotwell from SVN on Fedora 12. When I use the crop tool, > and select the "Custom" crop constraint, the layout of the crop tool > window changes so the "Cancel" and "OK" buttons are on the left. This > layout persists when I change to any other crop constraint. I think this > happens because the tool window layout is initialized by (from > EditingTools.vala) > > Gtk.HBox response_layout = new Gtk.HBox(true, CONTROL_SPACING); > response_layout.add(cancel_button); > response_layout.add(ok_button); > > layout = new Gtk.HBox(false, CONTROL_SPACING); > layout.add(constraint_combo); > layout.add(pivot_reticle_button); > layout.add(response_layout); > > but when the constraint type changes, response_layout is not removed, > just its children, cancel_button and the ok_button. I'm not sure how to > fix it, because I don't know how to access response_layout to remove its > children first (cancel_button and ok_button), and then remove > response_layout. > > I'd be glad to create the patch if someone pointed me in the right > direction. > > Thanks, > Paul > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From pnovak at alumni.caltech.edu Fri Apr 16 02:41:31 2010 From: pnovak at alumni.caltech.edu (Paul Novak) Date: Thu, 15 Apr 2010 19:41:31 -0700 Subject: [Shotwell] crop_tool_window layout changes when selecting "Custom" cropping In-Reply-To: References: <4BC6924F.6030605@alumni.caltech.edu> Message-ID: <4BC7CE5B.7040609@alumni.caltech.edu> On 04/15/2010 11:00 AM, Jim Nelson wrote: > Hi Paul, > > Yes, that's certainly not behavior by design. I've created a ticket for > this: http://trac.yorba.org/ticket/1795 > > We'd love it if you patched this. The code you mentioned is exactly where > you want to start: in EditingTools.vala, the CropToolWindow class. That > class is internal to CropTool, which does a lot of the work to rearrange the > controls when the custom constraint is selected. I suspect most (if not > all) of the patch would be in these two classes. > > -- Jim > > On Wed, Apr 14, 2010 at 9:13 PM, Paul Novak wrote: > >> Hello, >> >> I have built shotwell from SVN on Fedora 12. When I use the crop tool, >> and select the "Custom" crop constraint, the layout of the crop tool >> window changes so the "Cancel" and "OK" buttons are on the left. This >> layout persists when I change to any other crop constraint. I think this >> happens because the tool window layout is initialized by (from >> EditingTools.vala) >> >> Gtk.HBox response_layout = new Gtk.HBox(true, CONTROL_SPACING); >> response_layout.add(cancel_button); >> response_layout.add(ok_button); >> >> layout = new Gtk.HBox(false, CONTROL_SPACING); >> layout.add(constraint_combo); >> layout.add(pivot_reticle_button); >> layout.add(response_layout); >> >> but when the constraint type changes, response_layout is not removed, >> just its children, cancel_button and the ok_button. I'm not sure how to >> fix it, because I don't know how to access response_layout to remove its >> children first (cancel_button and ok_button), and then remove >> response_layout. >> >> I'd be glad to create the patch if someone pointed me in the right >> direction. >> >> Thanks, >> Paul >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > This patch makes response_layout public, then removing and adding it (and its children widgets) places it in in the appropriate location. It works, but I'm not sure if it is the best solution. Paul Index: src/EditingTools.vala =================================================================== --- src/EditingTools.vala (revision 1496) +++ src/EditingTools.vala (working copy) @@ -477,6 +477,7 @@ public Gtk.Entry custom_height_entry = new Gtk.Entry(); public Gtk.Label custom_mulsign_label = new Gtk.Label.with_mnemonic("x"); public Gtk.Entry most_recently_edited = null; + public Gtk.HBox response_layout = null; public Gtk.HBox layout = null; public int normal_width = -1; public int normal_height = -1; @@ -506,7 +507,7 @@ custom_height_entry.set_width_chars(4); custom_height_entry.editable = true; - Gtk.HBox response_layout = new Gtk.HBox(true, CONTROL_SPACING); + response_layout = new Gtk.HBox(true, CONTROL_SPACING); response_layout.add(cancel_button); response_layout.add(ok_button); @@ -778,16 +779,14 @@ crop_tool_window.layout.remove(crop_tool_window.constraint_combo); crop_tool_window.layout.remove(crop_tool_window.pivot_reticle_button); - crop_tool_window.layout.remove(crop_tool_window.cancel_button); - crop_tool_window.layout.remove(crop_tool_window.ok_button); + crop_tool_window.layout.remove(crop_tool_window.response_layout); crop_tool_window.layout.add(crop_tool_window.constraint_combo); crop_tool_window.layout.add(crop_tool_window.custom_height_entry); crop_tool_window.layout.add(crop_tool_window.custom_mulsign_label); crop_tool_window.layout.add(crop_tool_window.custom_width_entry); crop_tool_window.layout.add(crop_tool_window.pivot_reticle_button); - crop_tool_window.layout.add(crop_tool_window.cancel_button); - crop_tool_window.layout.add(crop_tool_window.ok_button); + crop_tool_window.layout.add(crop_tool_window.response_layout); if (reticle_orientation == ReticleOrientation.LANDSCAPE) { crop_tool_window.custom_width_entry.set_text("%d".printf(custom_init_width)); @@ -819,13 +818,11 @@ crop_tool_window.layout.remove(crop_tool_window.custom_mulsign_label); crop_tool_window.layout.remove(crop_tool_window.custom_height_entry); crop_tool_window.layout.remove(crop_tool_window.pivot_reticle_button); - crop_tool_window.layout.remove(crop_tool_window.cancel_button); - crop_tool_window.layout.remove(crop_tool_window.ok_button); + crop_tool_window.layout.remove(crop_tool_window.response_layout); crop_tool_window.layout.add(crop_tool_window.constraint_combo); crop_tool_window.layout.add(crop_tool_window.pivot_reticle_button); - crop_tool_window.layout.add(crop_tool_window.cancel_button); - crop_tool_window.layout.add(crop_tool_window.ok_button); + crop_tool_window.layout.add(crop_tool_window.response_layout); crop_tool_window.resize(crop_tool_window.normal_width, crop_tool_window.normal_height); From lucas at yorba.org Fri Apr 16 07:51:55 2010 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 16 Apr 2010 00:51:55 -0700 Subject: [Shotwell] PicasaWeb support In-Reply-To: References: Message-ID: Hi Richard, Your question of whether Yorba and the Shotwell community would prefer maintaining our own PicasaWeb support instead of having it replaced with a libgdata-based implementation has two answers: one for the near term, and the other for the long term. I'll first speak to the near term. In the short run, we have no intention of modifying the Shotwell PicasaWeb publishing subsystem for the simple reason that it works and is stable. What's more, the set of transactions that we perform on the PicasaWeb REST endpoint isn't terribly complex. Heck, we really only perform 4 operations: we query album names, we query user information, we create new albums, and we upload binary objects. With such simple needs, it was just as easy to code the communications layer of the PicasaWeb subsystem ourselves as it was to write a wrapper layer around an outside library. Writing the communications layer ourselves also allowed us to implement it in such a way that it could be used directly by the higher-level classes that coordinate the behavior of the entire publishing system (Interactor and BatchUploader), without having to use clumsy wrappers and adapters. All of that said, over the longer term, we definitely do intend to migrate to libgdata and similar client libraries for the other services that we support (Flickr, Facebook). The reason for this is that we intend to evolve simple batch publishing of photos into a complete, bi-directional, "always on," synchronized link between Shotwell and the cloud. So, the moment you edit a photo in Shotwell (say, by adjusting its saturation), the change will be reflected automatically in any web service to which the photo has been linked and vice-versa. Of course, implementing bi-directional synchronization will dramatically increase the complexity of our communications with the various web services. And, once we've reached this level of complexity, it makes sense for Yorba to stop developing its own client communications code and to start offloading that responsibility to mature outside libraries like libgdata. So if you're interested in Shotwell and you know libgdata inside and out, we would love to have your help on the PicasaWeb subsystem once we decide to make the move to bi-directional sync'ing. We're just not ready yet. Once again, all of us at Yorba thank you for your interest in Shotwell and your offer of a substantive contribution. Regards, Lucas From adam at yorba.org Fri Apr 16 23:19:39 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 16 Apr 2010 16:19:39 -0700 Subject: [Shotwell] Fwd: shotwell flickr group In-Reply-To: <4BC725A5.3000301@vanderwijst.com> References: <4BC725A5.3000301@vanderwijst.com> Message-ID: <4BC8F08B.6000201@yorba.org> Kaj-Ivar van der Wijst wrote: > I just recieved this email about the creation of a Shotwell Flickr > Group. What do you think, should we add / feature it on the website? > Thanks - I just added a link to the Flickr group on the Shotwell wiki page: http://trac.yorba.org/wiki/Shotwell adam From bengt at thuree.com Sun Apr 18 03:09:06 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sun, 18 Apr 2010 13:09:06 +1000 (EST) Subject: [Shotwell] unit testing Message-ID: <55458.59.154.63.92.1271560146.squirrel@denton.thuree.com> Hi Just wondering if you are using a test driven design approach when you are designing Shotwell? Like unit testing. /Bengt -- Bengt Thuree bengt at thuree.com From tommy.he at linux.com Tue Apr 20 09:49:40 2010 From: tommy.he at linux.com (Tommy He) Date: Tue, 20 Apr 2010 10:49:40 +0100 Subject: [Shotwell] Fwd: shotwell flickr group In-Reply-To: <4BC8F08B.6000201@yorba.org> References: <4BC725A5.3000301@vanderwijst.com> <4BC8F08B.6000201@yorba.org> Message-ID: Joined. It would be great if we have a twitter or facebook page. Pure for marketing and fans. ;-) On 17 April 2010 00:19, Adam Dingle wrote: > Kaj-Ivar van der Wijst wrote: > > I just recieved this email about the creation of a Shotwell Flickr > > Group. What do you think, should we add / feature it on the website? > > > > Thanks - I just added a link to the Flickr group on the Shotwell wiki page: > > http://trac.yorba.org/wiki/Shotwell > > adam > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- Take a Deep Breath out of Windows From fsat at proton-sss.ru Tue Apr 20 15:27:26 2010 From: fsat at proton-sss.ru (Ruslan A. Bondar) Date: Tue, 20 Apr 2010 19:27:26 +0400 Subject: [Shotwell] Enhansment to shotwell Message-ID: <20100420192726.24bb0560@proton-sss.ru> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all. I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, but I'll tell in more details. It would be great to allow organizing tags into graph. So one tag may have multiple parent and multiple children tags. And each of them may be assigned to the photo. It will be more flexible to organize your photos. As an owner of large, enough, photo album (~100 GB of photos) I can say - This feature is VERY useful. Also I'd like to participate in coding of this feature. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q =4KsN -----END PGP SIGNATURE----- From kaj-ivar at vanderwijst.com Tue Apr 20 16:36:17 2010 From: kaj-ivar at vanderwijst.com (Kaj-Ivar van der Wijst) Date: Tue, 20 Apr 2010 18:36:17 +0200 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <20100420192726.24bb0560@proton-sss.ru> References: <20100420192726.24bb0560@proton-sss.ru> Message-ID: <4BCDD801.3040901@vanderwijst.com> +1, good idea, I'd love this feature :) Op 20-04-10 17:27, Ruslan A. Bondar schreef: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello all. > > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, but I'll tell in more details. > > It would be great to allow organizing tags into graph. > So one tag may have multiple parent and multiple children tags. And each of them may be assigned to the photo. > It will be more flexible to organize your photos. > As an owner of large, enough, photo album (~100 GB of photos) I can say - This feature is VERY useful. > > Also I'd like to participate in coding of this feature. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q > =4KsN > -----END PGP SIGNATURE----- > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From palango at gmx.de Tue Apr 20 18:04:27 2010 From: palango at gmx.de (Paul Lange) Date: Tue, 20 Apr 2010 20:04:27 +0200 Subject: [Shotwell] Fedora Summer Coding Project Message-ID: <1271786667.7549.0.camel@localhost.localdomain> Hey, my name is Paul and I'm studying Mechanical and Process Engineering in Darmstadt, Germany. I'm interested in participating in Fedora Summer Coding [1] this summer, therefore I'm currently searching for a project. As one of my hobbies is photography I'm really interested in photo management/editing software. Because of this I think improving Shotwell would be a great project. I have two ideas for which I would like to hear what you think about: 1) Improve the display of photos. Add zooming and add display modes like "pass in" or "fill". Furthermore things like a "Compare photos" view would be nice. Parts of this could be done using Clutter to create a visually pleasing interface. 2) Create a GEGL-based processing system. I really like the idea behind GEGL and think it would be great to integrate it into Shotwell. It's kind of slow at the moment but there's ongoing work to improve that. This could also include porting the current stuff over to GEGL. I would really appreciate any kind of feedback! with kind regards, Paul [1] http://fedoraproject.org/wiki/Summer_Coding_2010 From fsat at proton-sss.ru Tue Apr 20 18:30:06 2010 From: fsat at proton-sss.ru (Ruslan A. Bondar) Date: Tue, 20 Apr 2010 22:30:06 +0400 Subject: [Shotwell] Fedora Summer Coding Project In-Reply-To: <1271786667.7549.0.camel@localhost.localdomain> References: <1271786667.7549.0.camel@localhost.localdomain> Message-ID: <20100420223006.305e5954@proton-sss.ru> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Paul. Can you describe in a bit more details.. What is a "Compare photos"? Is it something like "Find duplicates" (fdupes) Also which functions do you want to implement using GEGL? On Tue, 20 Apr 2010 20:04:27 +0200 Paul Lange wrote: > Hey, > > my name is Paul and I'm studying Mechanical and Process Engineering in > Darmstadt, Germany. > I'm interested in participating in Fedora Summer Coding [1] this > summer, therefore I'm currently searching for a project. As one of my > hobbies is photography I'm really interested in photo > management/editing software. Because of this I think improving > Shotwell would be a great project. > > I have two ideas for which I would like to hear what you think about: > > 1) > Improve the display of photos. Add zooming and add display modes like > "pass in" or "fill". Furthermore things like a "Compare photos" view > would be nice. Parts of this could be done using Clutter to create a > visually pleasing interface. > > 2) > Create a GEGL-based processing system. I really like the idea behind > GEGL and think it would be great to integrate it into Shotwell. It's > kind of slow at the moment but there's ongoing work to improve that. > This could also include porting the current stuff over to GEGL. > > > I would really appreciate any kind of feedback! > > with kind regards, > Paul > > > [1] http://fedoraproject.org/wiki/Summer_Coding_2010 > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkvN8rQACgkQRadsTlsSykORUgCffIZfqii40Y6RJ1HFpjlarv33 QLMAniqdaBNkg16MB7fybwX+HWCkL1bH =tk5d -----END PGP SIGNATURE----- From jim at yorba.org Tue Apr 20 18:32:01 2010 From: jim at yorba.org (Jim Nelson) Date: Tue, 20 Apr 2010 11:32:01 -0700 Subject: [Shotwell] unit testing In-Reply-To: <55458.59.154.63.92.1271560146.squirrel@denton.thuree.com> References: <55458.59.154.63.92.1271560146.squirrel@denton.thuree.com> Message-ID: Hi Bengt, We are not using a test-driven design for Shotwell, nor do we have unit tests prepared. Rather, we're using an iterative approach of feature additions and bug fixes. We do have a ticket for an automated test suite ( http://trac.yorba.org/ticket/1068), but its intent is to find ways to exercise Shotwell's capabilities and look for bugs, crashers, and unexpected behavior (i.e. system testing, not unit testing). I could see starting a suite of unit tests that begins small and works outward and upward. If you're interested, one good place to start would be the Shotwell architecture pages on our wiki ( http://trac.yorba.org/wiki/ShotwellArchitectureOverview). Shotwell has smallish hard-working classes that could use validation (i.e. SortedList or Command/CommandManager). Unit tests could then work up to the central data structures, DataObject and DataCollection, and beyond. Unit testing would need to be in Vala; there's some support for GTest already: http://www.valadoc.org/glib-2.0/GLib.Test.html http://live.gnome.org/Vala/TestSample -- Jim On Sat, Apr 17, 2010 at 8:09 PM, Bengt Thuree wrote: > Hi > > Just wondering if you are using a test driven design approach when you are > designing Shotwell? Like unit testing. > > /Bengt > > > -- > Bengt Thuree bengt at thuree.com > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From rob at yorba.org Tue Apr 20 20:22:08 2010 From: rob at yorba.org (Robert Powell) Date: Tue, 20 Apr 2010 13:22:08 -0700 Subject: [Shotwell] unit testing In-Reply-To: References: <55458.59.154.63.92.1271560146.squirrel@denton.thuree.com> Message-ID: Hi Bengt, We are not using a test-driven design for Shotwell, nor do we have unit > tests prepared. Rather, we're using an iterative approach of feature > additions and bug fixes. > > At Yorba, we do have a few unit tests in the Fillmore/Lombard/Marina projects if you are looking to see one approach with Vala. I'm not thrilled with our usage of that test framework, so I'd love to hear of other approaches. The main problem is setting up the fixtures for the test cases. There will certainly be more as time allows, and I do use test-driven development when the task is appropriate. Hope that helps, Rob From adam at yorba.org Tue Apr 20 21:30:28 2010 From: adam at yorba.org (Adam Dingle) Date: Tue, 20 Apr 2010 14:30:28 -0700 Subject: [Shotwell] Fedora Summer Coding Project In-Reply-To: <1271786667.7549.0.camel@localhost.localdomain> References: <1271786667.7549.0.camel@localhost.localdomain> Message-ID: <4BCE1CF4.6060705@yorba.org> Paul, it's great to hear you're interested in working on Shotwell this summer. We'd certainly be happy to have your help. I can comment on a couple of your proposed ideas. First, zooming has recently been implemented in the trunk (try it!) We're also interested in replacing Shotwell's photo transformation pipeline with GEGL (that's http://trac.yorba.org/ticket/1624) but that will be a major project with lots of architectural consequences for Shotwell as a whole, so I think that is probably a project for the core team. I'm not sure what you mean by "pass in" or "fill" modes - can you explain? Also, how would the "compare photos" view work? Shotwell already lets you compare the unedited and edited versions of any photo, by the way - just press the Shift key. I'd suggest that you look at our existing Wiki page listing summer coding ideas: http://trac.yorba.org/wiki/SummerCodeIdeas You can also look through our ticket database (http://trac.yorba.org/report/16) for ideas. You might want to take on some smaller tickets at first to help you get to know the code. Let us know what you think you might want to work on first and we'll be happy to provide some ideas and feedback. Thanks! adam Paul Lange wrote: > Hey, > > my name is Paul and I'm studying Mechanical and Process Engineering in > Darmstadt, Germany. > I'm interested in participating in Fedora Summer Coding [1] this summer, > therefore I'm currently searching for a project. As one of my hobbies is > photography I'm really interested in photo management/editing software. > Because of this I think improving Shotwell would be a great project. > > I have two ideas for which I would like to hear what you think about: > > 1) > Improve the display of photos. Add zooming and add display modes like > "pass in" or "fill". Furthermore things like a "Compare photos" view > would be nice. Parts of this could be done using Clutter to create a > visually pleasing interface. > > 2) > Create a GEGL-based processing system. I really like the idea behind > GEGL and think it would be great to integrate it into Shotwell. It's > kind of slow at the moment but there's ongoing work to improve that. > This could also include porting the current stuff over to GEGL. > > > I would really appreciate any kind of feedback! > > with kind regards, > Paul > > > [1] http://fedoraproject.org/wiki/Summer_Coding_2010 > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From bengt at thuree.com Wed Apr 21 06:00:49 2010 From: bengt at thuree.com (Bengt Thuree) Date: Wed, 21 Apr 2010 16:00:49 +1000 (EST) Subject: [Shotwell] unit testing In-Reply-To: References: <55458.59.154.63.92.1271560146.squirrel@denton.thuree.com> Message-ID: <36706.59.154.63.92.1271829649.squirrel@denton.thuree.com> Den On, 2010-04-21, 06:22 skrev Robert Powell: > Hi Bengt, > > We are not using a test-driven design for Shotwell, nor do we have unit >> tests prepared. Rather, we're using an iterative approach of feature >> additions and bug fixes. >> >> > At Yorba, we do have a few unit tests in the Fillmore/Lombard/Marina > projects if you are looking to see one approach with Vala. I'm not > thrilled > with our usage of that test framework, so I'd love to hear of other > approaches. The main problem is setting up the fixtures for the test > cases. There will certainly be more as time allows, and I do use > test-driven development when the task is appropriate. Thanks for the reply :) Yes, I will look at those ones and see how it is done. I do hope that you are planning for more unit testing of the logic in Shotwell in the near future, since it is much easier to implement it now than later when it is a much more mature product. Test Driven approach sure enhances the end quality of the product :) Bengt From palango at gmx.de Thu Apr 22 15:06:21 2010 From: palango at gmx.de (Paul Lange) Date: Thu, 22 Apr 2010 17:06:21 +0200 Subject: [Shotwell] Fedora Summer Coding Project In-Reply-To: <4BCE1CF4.6060705@yorba.org> References: <1271786667.7549.0.camel@localhost.localdomain> <4BCE1CF4.6060705@yorba.org> Message-ID: <1271948781.2177.16.camel@localhost.localdomain> Hey, thanks for the feedback and ideas. What I mean with compare photo view is shown on this website: http://www.adobepress.com/articles/article.asp?p=1233193&seqNum=4 The following page shows what I mean with "pass in" or "fill (here zoom to fit" mean: http://help.adobe.com/en_US/Lightroom/2.0/WS666FE5AB-F4E3-40a2-BDD1-98CBF68773F3.html The creation of the GEGL pipeline by the core team makes sense to me. However I really like the idea of improving the slideshow mode. Adding transitions and background music sounds like a great project to me. Do you have any ideas on how to implement that? sound should work via Gstreamer but transitions could be implemented with Clutter or Cairo (F-Spot does this). regards, Paul ps. @adam: built libraw, trunk builds now. thanks a lot :) pps. does anyone else has problems with sending pgp-signed mails to the list? Am Dienstag, den 20.04.2010, 14:30 -0700 schrieb Adam Dingle: > Paul, > > it's great to hear you're interested in working on Shotwell this > summer. We'd certainly be happy to have your help. > > I can comment on a couple of your proposed ideas. First, zooming has > recently been implemented in the trunk (try it!) We're also interested > in replacing Shotwell's photo transformation pipeline with GEGL (that's > http://trac.yorba.org/ticket/1624) but that will be a major project with > lots of architectural consequences for Shotwell as a whole, so I think > that is probably a project for the core team. > > I'm not sure what you mean by "pass in" or "fill" modes - can you > explain? Also, how would the "compare photos" view work? Shotwell > already lets you compare the unedited and edited versions of any photo, > by the way - just press the Shift key. > > I'd suggest that you look at our existing Wiki page listing summer > coding ideas: > > http://trac.yorba.org/wiki/SummerCodeIdeas > > You can also look through our ticket database > (http://trac.yorba.org/report/16) for ideas. You might want to take on > some smaller tickets at first to help you get to know the code. Let us > know what you think you might want to work on first and we'll be happy > to provide some ideas and feedback. Thanks! > > adam > > Paul Lange wrote: > > Hey, > > > > my name is Paul and I'm studying Mechanical and Process Engineering in > > Darmstadt, Germany. > > I'm interested in participating in Fedora Summer Coding [1] this summer, > > therefore I'm currently searching for a project. As one of my hobbies is > > photography I'm really interested in photo management/editing software. > > Because of this I think improving Shotwell would be a great project. > > > > I have two ideas for which I would like to hear what you think about: > > > > 1) > > Improve the display of photos. Add zooming and add display modes like > > "pass in" or "fill". Furthermore things like a "Compare photos" view > > would be nice. Parts of this could be done using Clutter to create a > > visually pleasing interface. > > > > 2) > > Create a GEGL-based processing system. I really like the idea behind > > GEGL and think it would be great to integrate it into Shotwell. It's > > kind of slow at the moment but there's ongoing work to improve that. > > This could also include porting the current stuff over to GEGL. > > > > > > I would really appreciate any kind of feedback! > > > > with kind regards, > > Paul > > > > > > [1] http://fedoraproject.org/wiki/Summer_Coding_2010 > > > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > From adam at yorba.org Thu Apr 22 23:07:42 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 22 Apr 2010 16:07:42 -0700 Subject: [Shotwell] Fedora Summer Coding Project In-Reply-To: <1271948781.2177.16.camel@localhost.localdomain> References: <1271786667.7549.0.camel@localhost.localdomain> <4BCE1CF4.6060705@yorba.org> <1271948781.2177.16.camel@localhost.localdomain> Message-ID: <4BD0D6BE.7020700@yorba.org> Paul, > What I mean with compare photo view is shown on this website: > http://www.adobepress.com/articles/article.asp?p=1233193&seqNum=4 > Yes - that would be a nice feature for Shotwell. I've created a ticket for this at http://trac.yorba.org/ticket/1810 . > The following page shows what I mean with "pass in" or "fill (here zoom > to fit" mean: > http://help.adobe.com/en_US/Lightroom/2.0/WS666FE5AB-F4E3-40a2-BDD1-98CBF68773F3.html > Aha - I see. I think we can probably live without that feature for the moment, but feel free to create a ticket for this if you like. > > The creation of the GEGL pipeline by the core team makes sense to me. > However I really like the idea of improving the slideshow mode. Adding > transitions and background music sounds like a great project to me. Do > you have any ideas on how to implement that? sound should work via > Gstreamer but transitions could be implemented with Clutter or Cairo > (F-Spot does this). We think that enhancing Shotwell's slideshows would be a great summer project. We just looked at the Fedora Summer Coding web page (https://fedoraproject.org/wiki/Summer_Coding_2010). It looks like the next step is for us to create an idea page for Shotwell on the Fedora Summer Coding wiki. Then you can submit a project proposal and if it is accepted (you'll find out in late May) it looks like you would begin work in June. We have a couple of questions about the process and so I just sent an email to the Summer Coding mailing list, but with any luck we can get the ball rolling soon. We're not yet sure whether transitions should be implemented using Clutter, Cairo, OpenGL or something else - maybe we can all think about that and discuss in the near future. cheers adam From asubedi at gmail.com Fri Apr 23 00:49:02 2010 From: asubedi at gmail.com (asubedi) Date: Thu, 22 Apr 2010 20:49:02 -0400 Subject: [Shotwell] RAW support in Shotwell Message-ID: I recently heard about Yorba and Shotwell and installed Shotwell in Ubuntu 10.4. Compared to F-spot it's pretty good and it is really responsive. I also plugged in my Cannon 40D to import my photos. But it did not work. However, Nautilus and F-spot could download the pics. Before filing a bug, I thought I would try to fix it myself and have checked out the source from subversion. There seems to be some bug in initializing the camera through libgphoto but I haven't pin-pointed it yet. I'll do some work this weekend and if I don't make any progress, will file a bug. Regarding the RAW support, GEGL based work flow would be the best :-) In the meantime, I would probably prefer use of libraw if I used Shotwell. I am a (very) amateur photographer and I do most of my photoprocessing in my MacbookPro using the software that came with Cannon (Digital Photo Professional). I do not own Photoshop and find that the simple program suffices my needs. The only modifications I make on my photos are change brightness, contrast, tone, saturation, and sharpness. I also modify histogram curves that correspond to various picture styles -- landscape, portrait, faithful, etc. One thing the Cannon DPP does not do is rotate pics by arbitrary angle (so I can level the pics). However, the main reason I am beholden to my Mac for my photography is the colour profile management. Hopefully, some thought has gone into incorporating and managing ICC profiles. Best, Alaska PS: Another thing for which I use my Mac is viewing and playing the MIDI of Powertab files using TabView. I hope Fillmore will fulfill this need someday. Good luck for you Yorba guys! From adam at yorba.org Fri Apr 23 02:25:51 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 22 Apr 2010 19:25:51 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <20100420192726.24bb0560@proton-sss.ru> References: <20100420192726.24bb0560@proton-sss.ru> Message-ID: <4BD1052F.2010004@yorba.org> Ruslan, thanks for your email. As you probably know, we're also interested in hierarchical tagging. I think at this point we'd like to implement a single-parent system, in which each tag can have multiple children but only one parent. This is ticket 1401. After that, we might consider extending the system to support multiple parents in some way. A single-parent tag system in Shotwell would work like this. In the sidebar, the user should be able to drag any tag A onto any other tag B; then A becomes a child of B. If the user drags any tag onto the Tags heading, then it becomes a top-level tag. If the user selects any tag, then Shotwell should display all photos which belong to the tag or any of its children. The set of photos is sorted according to the View->Sort Photos settings. If a photo belongs to multiple child tags, it is displayed only once in the sorted set. All tag names must be globally unique. For example, I can't create a tag named "washington" under a parent "states", and another tag also named "washington" under a parent tag "cities". You said you might like to participate in coding this feature - that would be great. If the description above sounds reasonable to you, as a next step maybe you could look at the Shotwell code and send a brief design proposal to this mailing list. In your proposal, please describe the database schema changes you intend, plus any new major classes introduced (if any) and any major changes to existing classes. We'd be happy to comment on your implementation plan. Thanks! adam Ruslan A. Bondar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello all. > > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, but I'll tell in more details. > > It would be great to allow organizing tags into graph. > So one tag may have multiple parent and multiple children tags. And each of them may be assigned to the photo. > It will be more flexible to organize your photos. > As an owner of large, enough, photo album (~100 GB of photos) I can say - This feature is VERY useful. > > Also I'd like to participate in coding of this feature. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q > =4KsN > -----END PGP SIGNATURE----- > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From fsat at proton-sss.ru Fri Apr 23 12:20:15 2010 From: fsat at proton-sss.ru (Ruslan A. Bondar) Date: Fri, 23 Apr 2010 16:20:15 +0400 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <4BD1052F.2010004@yorba.org> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> Message-ID: <20100423162015.1f53ddb1@proton-sss.ru> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Adam. I think the code change will contain following steps: 1. Add field "ParentTagId" to TagTable 2. Change the TagTable class to handle this field. 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow to provide recursive tree creation for tag tree. 4. Change drag'n'drop handler to allow moving tags between branches. And something more, such as listeners of tag tree alteration etc. I think these changes will not affect any other functionality. And no major changes in design are required. I think it would be better to store only photos "owned" by this tag, but on load build the full list, containing photos from this and all child tags. And for now I see several ways: 1. Create helper table to speedup loading, but this will slow down tag reassigning (Tag moving between branches). This table may contain only 2 fields: TagId and AllTagPhotos. 2. Walk over the table recursively and build the list via concatenation, this will be slightly slower. These are the common thoughts. I'll dig the source deeper during the weekend. On Thu, 22 Apr 2010 19:25:51 -0700 Adam Dingle wrote: > Ruslan, > > thanks for your email. As you probably know, we're also interested > in hierarchical tagging. > > I think at this point we'd like to implement a single-parent system, > in which each tag can have multiple children but only one parent. > This is ticket 1401. After that, we might consider extending the > system to support multiple parents in some way. > > A single-parent tag system in Shotwell would work like this. In the > sidebar, the user should be able to drag any tag A onto any other tag > B; then A becomes a child of B. If the user drags any tag onto the > Tags heading, then it becomes a top-level tag. > > If the user selects any tag, then Shotwell should display all photos > which belong to the tag or any of its children. The set of photos is > sorted according to the View->Sort Photos settings. If a photo > belongs to multiple child tags, it is displayed only once in the > sorted set. > > All tag names must be globally unique. For example, I can't create a > tag named "washington" under a parent "states", and another tag also > named "washington" under a parent tag "cities". > > You said you might like to participate in coding this feature - that > would be great. If the description above sounds reasonable to you, > as a next step maybe you could look at the Shotwell code and send a > brief design proposal to this mailing list. In your proposal, > please describe the database schema changes you intend, plus any new > major classes introduced (if any) and any major changes to existing > classes. We'd be happy to comment on your implementation plan. > Thanks! > > adam > > Ruslan A. Bondar wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hello all. > > > > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, > > but I'll tell in more details. > > > > It would be great to allow organizing tags into graph. > > So one tag may have multiple parent and multiple children tags. And > > each of them may be assigned to the photo. It will be more flexible > > to organize your photos. As an owner of large, enough, photo album > > (~100 GB of photos) I can say - This feature is VERY useful. > > > > Also I'd like to participate in coding of this feature. > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > > > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu > > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q > > =4KsN > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ =LAuc -----END PGP SIGNATURE----- From bengt at thuree.com Fri Apr 23 12:55:56 2010 From: bengt at thuree.com (Bengt Thuree) Date: Fri, 23 Apr 2010 22:55:56 +1000 (EST) Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <20100423162015.1f53ddb1@proton-sss.ru> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> Message-ID: <51148.59.154.63.92.1272027356.squirrel@denton.thuree.com> Perhaps consider checking how DigiKam is storing the tags. DigiKam also have a hierarchy system of the tags (f-spot do not). I think that digikam stores them in the embedded XMP aread as /tag1/tag2/tag3 format. /Bengt Den Fr, 2010-04-23, 22:20 skrev Ruslan A. Bondar: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, Adam. > > I think the code change will contain following steps: > 1. Add field "ParentTagId" to TagTable > 2. Change the TagTable class to handle this field. > 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow > to provide recursive tree creation for tag tree. > 4. Change drag'n'drop handler to allow moving tags between branches. > > And something more, such as listeners of tag tree alteration etc. I think > these changes will not affect any other functionality. And no major > changes in design are required. > > I think it would be better to store only photos "owned" by this tag, but > on load build the full list, containing photos from this and all child > tags. And for now I see several ways: > 1. Create helper table to speedup loading, but this will slow down tag > reassigning (Tag moving between branches). This table may contain only 2 > fields: TagId and AllTagPhotos. > 2. Walk over the table recursively and build the list via concatenation, > this will be slightly slower. > > These are the common thoughts. I'll dig the source deeper during the > weekend. > > On Thu, 22 Apr 2010 19:25:51 -0700 > Adam Dingle wrote: > >> Ruslan, >> >> thanks for your email. As you probably know, we're also interested >> in hierarchical tagging. >> >> I think at this point we'd like to implement a single-parent system, >> in which each tag can have multiple children but only one parent. >> This is ticket 1401. After that, we might consider extending the >> system to support multiple parents in some way. >> >> A single-parent tag system in Shotwell would work like this. In the >> sidebar, the user should be able to drag any tag A onto any other tag >> B; then A becomes a child of B. If the user drags any tag onto the >> Tags heading, then it becomes a top-level tag. >> >> If the user selects any tag, then Shotwell should display all photos >> which belong to the tag or any of its children. The set of photos is >> sorted according to the View->Sort Photos settings. If a photo >> belongs to multiple child tags, it is displayed only once in the >> sorted set. >> >> All tag names must be globally unique. For example, I can't create a >> tag named "washington" under a parent "states", and another tag also >> named "washington" under a parent tag "cities". >> >> You said you might like to participate in coding this feature - that >> would be great. If the description above sounds reasonable to you, >> as a next step maybe you could look at the Shotwell code and send a >> brief design proposal to this mailing list. In your proposal, >> please describe the database schema changes you intend, plus any new >> major classes introduced (if any) and any major changes to existing >> classes. We'd be happy to comment on your implementation plan. >> Thanks! >> >> adam >> >> Ruslan A. Bondar wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hello all. >> > >> > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, >> > but I'll tell in more details. >> > >> > It would be great to allow organizing tags into graph. >> > So one tag may have multiple parent and multiple children tags. And >> > each of them may be assigned to the photo. It will be more flexible >> > to organize your photos. As an owner of large, enough, photo album >> > (~100 GB of photos) I can say - This feature is VERY useful. >> > >> > Also I'd like to participate in coding of this feature. >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v2.0.14 (GNU/Linux) >> > >> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu >> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q >> > =4KsN >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > Shotwell mailing list >> > Shotwell at lists.yorba.org >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > >> > >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg > G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ > =LAuc > -----END PGP SIGNATURE----- > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > -- Bengt Thuree bengt at thuree.com From jim at yorba.org Fri Apr 23 18:54:18 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 23 Apr 2010 11:54:18 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <20100423162015.1f53ddb1@proton-sss.ru> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> Message-ID: So far, this sounds like steps in the right direction. Some notes: Our general strategy in Shotwell is to load the entire database in one swoop at startup and maintain all database rows in memory. Once the application is started, database access is limited to updates and deletes. (There are exceptions, particularly in Event.) Generally it's faster to do searching in memory than via the database. It's a trade-off, but one we take for performance reasons. If you read the architecture overview on Data Structures, I talk about the strategy I use for signalling (i.e. listeners, or observers as I call them). We definitely want each Tag to signal when it's children and parent is altered. I would also recommend having these signals reflected by TagSourceCollection, that way an observer can register once than register for every Tag. For example, LibraryWindow could register once and receive notifications on all Tags being moved around, updating the Sidebar accordingly. Also note that we've invested a lot of code time in fully synchronized data structures for the "big" objects and their collections: Tag, Photo, Event, etc. Since each Tag maintains a ViewCollection of Photo objects, it's easy to recurse up and down the hierarchy gathering a HashSet of Photos. It could be as simple as this: void get_photos_and_children_photos(Gee.HashSet photos) { photos.add_all(get_view().get_all()); foreach (Tag child in children) child.get_photos_and_children_photos(photos); } Since I don't expect Tag hierarchies to be crazy-deep, this is probably sound. (There can be no loops in the tree, of course. You'll need to protect against that.) Alternately, each Tag could monitor additions and deletions of its children and maintain a separate ViewCollection of its Photos and its descendants' photos. I'm not convinced that there's a big win here, but it's possible with the architecture in place. In short, I would discourage looking to the database for anything more than data persistence and organization. My feeling right now is, this can all be done in memory faster and and more efficiently than via SQL. -- Jim On Fri, Apr 23, 2010 at 5:20 AM, Ruslan A. Bondar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, Adam. > > I think the code change will contain following steps: > 1. Add field "ParentTagId" to TagTable > 2. Change the TagTable class to handle this field. > 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow to provide recursive tree creation for tag tree. > 4. Change drag'n'drop handler to allow moving tags between branches. > > And something more, such as listeners of tag tree alteration etc. I think these changes will not affect any other functionality. And no major changes in design are required. > > I think it would be better to store only photos "owned" by this tag, but on load build the full list, containing photos from this and all child tags. And for now I see several ways: > 1. Create helper table to speedup loading, but this will slow down tag reassigning (Tag moving between branches). This table may contain only 2 fields: TagId and AllTagPhotos. > 2. Walk over the table recursively and build the list via concatenation, this will be slightly slower. > > These are the common thoughts. I'll dig the source deeper during the weekend. > > On Thu, 22 Apr 2010 19:25:51 -0700 > Adam Dingle wrote: > >> Ruslan, >> >> thanks for your email. ?As you probably know, we're also interested >> in hierarchical tagging. >> >> I think at this point we'd like to implement a single-parent system, >> in which each tag can have multiple children but only one parent. >> This is ticket 1401. ?After that, we might consider extending the >> system to support multiple parents in some way. >> >> A single-parent tag system in Shotwell would work like this. ?In the >> sidebar, the user should be able to drag any tag A onto any other tag >> B; then A becomes a child of B. ?If the user drags any tag onto the >> Tags heading, then it becomes a top-level tag. >> >> If the user selects any tag, then Shotwell should display all photos >> which belong to the tag or any of its children. ?The set of photos is >> sorted according to the View->Sort Photos settings. ?If a photo >> belongs to multiple child tags, it is displayed only once in the >> sorted set. >> >> All tag names must be globally unique. ?For example, I can't create a >> tag named "washington" under a parent "states", and another tag also >> named "washington" under a parent tag "cities". >> >> You said you might like to participate in coding this feature - that >> would be great. ?If the description above sounds reasonable to you, >> as a next step maybe you could look at the Shotwell code and send a >> brief design proposal to this mailing list. ? In your proposal, >> please describe the database schema changes you intend, plus any new >> major classes introduced (if any) and any major changes to existing >> classes. We'd be happy to comment on your implementation plan. >> Thanks! >> >> adam >> >> Ruslan A. Bondar wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hello all. >> > >> > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, >> > but I'll tell in more details. >> > >> > It would be great to allow organizing tags into graph. >> > So one tag may have multiple parent and multiple children tags. And >> > each of them may be assigned to the photo. It will be more flexible >> > to organize your photos. As an owner of large, enough, photo album >> > (~100 GB of photos) I can say - This feature is VERY useful. >> > >> > Also I'd like to participate in coding of this feature. >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v2.0.14 (GNU/Linux) >> > >> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu >> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q >> > =4KsN >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > Shotwell mailing list >> > Shotwell at lists.yorba.org >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > >> > >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg > G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ > =LAuc > -----END PGP SIGNATURE----- > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Fri Apr 23 19:02:50 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 23 Apr 2010 12:02:50 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <51148.59.154.63.92.1272027356.squirrel@denton.thuree.com> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <51148.59.154.63.92.1272027356.squirrel@denton.thuree.com> Message-ID: I mentioned the architecture overview without providing a URL. In case you've not seen it: http://trac.yorba.org/wiki/ShotwellArchitectureOverview In particular, you'll want to look at Data Structures, Database, and Commands and Command Manager (as we'll want most of these actions to be undoable). -- Jim On Fri, Apr 23, 2010 at 5:55 AM, Bengt Thuree wrote: > Perhaps consider checking how DigiKam is storing the tags. > DigiKam also have a hierarchy system of the tags (f-spot do not). > I think that digikam stores them in the embedded XMP aread as > /tag1/tag2/tag3 format. > > /Bengt > Den Fr, 2010-04-23, 22:20 skrev Ruslan A. Bondar: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, Adam. >> >> I think the code change will contain following steps: >> 1. Add field "ParentTagId" to TagTable >> 2. Change the TagTable class to handle this field. >> 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow >> to provide recursive tree creation for tag tree. >> 4. Change drag'n'drop handler to allow moving tags between branches. >> >> And something more, such as listeners of tag tree alteration etc. I think >> these changes will not affect any other functionality. And no major >> changes in design are required. >> >> I think it would be better to store only photos "owned" by this tag, but >> on load build the full list, containing photos from this and all child >> tags. And for now I see several ways: >> 1. Create helper table to speedup loading, but this will slow down tag >> reassigning (Tag moving between branches). This table may contain only 2 >> fields: TagId and AllTagPhotos. >> 2. Walk over the table recursively and build the list via concatenation, >> this will be slightly slower. >> >> These are the common thoughts. I'll dig the source deeper during the >> weekend. >> >> On Thu, 22 Apr 2010 19:25:51 -0700 >> Adam Dingle wrote: >> >>> Ruslan, >>> >>> thanks for your email. ?As you probably know, we're also interested >>> in hierarchical tagging. >>> >>> I think at this point we'd like to implement a single-parent system, >>> in which each tag can have multiple children but only one parent. >>> This is ticket 1401. ?After that, we might consider extending the >>> system to support multiple parents in some way. >>> >>> A single-parent tag system in Shotwell would work like this. ?In the >>> sidebar, the user should be able to drag any tag A onto any other tag >>> B; then A becomes a child of B. ?If the user drags any tag onto the >>> Tags heading, then it becomes a top-level tag. >>> >>> If the user selects any tag, then Shotwell should display all photos >>> which belong to the tag or any of its children. ?The set of photos is >>> sorted according to the View->Sort Photos settings. ?If a photo >>> belongs to multiple child tags, it is displayed only once in the >>> sorted set. >>> >>> All tag names must be globally unique. ?For example, I can't create a >>> tag named "washington" under a parent "states", and another tag also >>> named "washington" under a parent tag "cities". >>> >>> You said you might like to participate in coding this feature - that >>> would be great. ?If the description above sounds reasonable to you, >>> as a next step maybe you could look at the Shotwell code and send a >>> brief design proposal to this mailing list. ? In your proposal, >>> please describe the database schema changes you intend, plus any new >>> major classes introduced (if any) and any major changes to existing >>> classes. We'd be happy to comment on your implementation plan. >>> Thanks! >>> >>> adam >>> >>> Ruslan A. Bondar wrote: >>> > -----BEGIN PGP SIGNED MESSAGE----- >>> > Hash: SHA1 >>> > >>> > Hello all. >>> > >>> > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, >>> > but I'll tell in more details. >>> > >>> > It would be great to allow organizing tags into graph. >>> > So one tag may have multiple parent and multiple children tags. And >>> > each of them may be assigned to the photo. It will be more flexible >>> > to organize your photos. As an owner of large, enough, photo album >>> > (~100 GB of photos) I can say - This feature is VERY useful. >>> > >>> > Also I'd like to participate in coding of this feature. >>> > -----BEGIN PGP SIGNATURE----- >>> > Version: GnuPG v2.0.14 (GNU/Linux) >>> > >>> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu >>> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q >>> > =4KsN >>> > -----END PGP SIGNATURE----- >>> > _______________________________________________ >>> > Shotwell mailing list >>> > Shotwell at lists.yorba.org >>> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> > >>> > >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.14 (GNU/Linux) >> >> iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg >> G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ >> =LAuc >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > > > -- > Bengt Thuree ? bengt at thuree.com > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From bengt at thuree.com Fri Apr 23 23:33:42 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sat, 24 Apr 2010 09:33:42 +1000 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> Message-ID: <1272065622.3012.11.camel@lappis> Will the performance be ok with a photo collection of 50,000 - 1,000,000 Photos or above? Bengt On Fri, 2010-04-23 at 11:54 -0700, Jim Nelson wrote: > So far, this sounds like steps in the right direction. Some notes: > > Our general strategy in Shotwell is to load the entire database in one > swoop at startup and maintain all database rows in memory. Once the > application is started, database access is limited to updates and > deletes. (There are exceptions, particularly in Event.) Generally > it's faster to do searching in memory than via the database. It's a > trade-off, but one we take for performance reasons. > > If you read the architecture overview on Data Structures, I talk about > the strategy I use for signalling (i.e. listeners, or observers as I > call them). We definitely want each Tag to signal when it's children > and parent is altered. I would also recommend having these signals > reflected by TagSourceCollection, that way an observer can register > once than register for every Tag. For example, LibraryWindow could > register once and receive notifications on all Tags being moved > around, updating the Sidebar accordingly. > > Also note that we've invested a lot of code time in fully synchronized > data structures for the "big" objects and their collections: Tag, > Photo, Event, etc. Since each Tag maintains a ViewCollection of Photo > objects, it's easy to recurse up and down the hierarchy gathering a > HashSet of Photos. It could be as simple as this: > > void get_photos_and_children_photos(Gee.HashSet photos) { > photos.add_all(get_view().get_all()); > foreach (Tag child in children) > child.get_photos_and_children_photos(photos); > } > > Since I don't expect Tag hierarchies to be crazy-deep, this is > probably sound. (There can be no loops in the tree, of course. > You'll need to protect against that.) > > Alternately, each Tag could monitor additions and deletions of its > children and maintain a separate ViewCollection of its Photos and its > descendants' photos. I'm not convinced that there's a big win here, > but it's possible with the architecture in place. > > In short, I would discourage looking to the database for anything more > than data persistence and organization. My feeling right now is, this > can all be done in memory faster and and more efficiently than via > SQL. > > -- Jim > > On Fri, Apr 23, 2010 at 5:20 AM, Ruslan A. Bondar wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hello, Adam. > > > > I think the code change will contain following steps: > > 1. Add field "ParentTagId" to TagTable > > 2. Change the TagTable class to handle this field. > > 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow to provide recursive tree creation for tag tree. > > 4. Change drag'n'drop handler to allow moving tags between branches. > > > > And something more, such as listeners of tag tree alteration etc. I think these changes will not affect any other functionality. And no major changes in design are required. > > > > I think it would be better to store only photos "owned" by this tag, but on load build the full list, containing photos from this and all child tags. And for now I see several ways: > > 1. Create helper table to speedup loading, but this will slow down tag reassigning (Tag moving between branches). This table may contain only 2 fields: TagId and AllTagPhotos. > > 2. Walk over the table recursively and build the list via concatenation, this will be slightly slower. > > > > These are the common thoughts. I'll dig the source deeper during the weekend. > > > > On Thu, 22 Apr 2010 19:25:51 -0700 > > Adam Dingle wrote: > > > >> Ruslan, > >> > >> thanks for your email. As you probably know, we're also interested > >> in hierarchical tagging. > >> > >> I think at this point we'd like to implement a single-parent system, > >> in which each tag can have multiple children but only one parent. > >> This is ticket 1401. After that, we might consider extending the > >> system to support multiple parents in some way. > >> > >> A single-parent tag system in Shotwell would work like this. In the > >> sidebar, the user should be able to drag any tag A onto any other tag > >> B; then A becomes a child of B. If the user drags any tag onto the > >> Tags heading, then it becomes a top-level tag. > >> > >> If the user selects any tag, then Shotwell should display all photos > >> which belong to the tag or any of its children. The set of photos is > >> sorted according to the View->Sort Photos settings. If a photo > >> belongs to multiple child tags, it is displayed only once in the > >> sorted set. > >> > >> All tag names must be globally unique. For example, I can't create a > >> tag named "washington" under a parent "states", and another tag also > >> named "washington" under a parent tag "cities". > >> > >> You said you might like to participate in coding this feature - that > >> would be great. If the description above sounds reasonable to you, > >> as a next step maybe you could look at the Shotwell code and send a > >> brief design proposal to this mailing list. In your proposal, > >> please describe the database schema changes you intend, plus any new > >> major classes introduced (if any) and any major changes to existing > >> classes. We'd be happy to comment on your implementation plan. > >> Thanks! > >> > >> adam > >> > >> Ruslan A. Bondar wrote: > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > Hello all. > >> > > >> > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, > >> > but I'll tell in more details. > >> > > >> > It would be great to allow organizing tags into graph. > >> > So one tag may have multiple parent and multiple children tags. And > >> > each of them may be assigned to the photo. It will be more flexible > >> > to organize your photos. As an owner of large, enough, photo album > >> > (~100 GB of photos) I can say - This feature is VERY useful. > >> > > >> > Also I'd like to participate in coding of this feature. > >> > -----BEGIN PGP SIGNATURE----- > >> > Version: GnuPG v2.0.14 (GNU/Linux) > >> > > >> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu > >> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q > >> > =4KsN > >> > -----END PGP SIGNATURE----- > >> > _______________________________________________ > >> > Shotwell mailing list > >> > Shotwell at lists.yorba.org > >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > >> > > >> > > >> > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > > > iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg > > G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ > > =LAuc > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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 Sat Apr 24 00:31:23 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 23 Apr 2010 17:31:23 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <1272065622.3012.11.camel@lappis> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <1272065622.3012.11.camel@lappis> Message-ID: Shotwell's not designed for that kind of scalability (yet!) I'm more concerned with 10,000 photo collections. Right now I would want to design this correctly and cleanly, then do performance testing to determine if there are bottlenecks and correct them. As I mentioned, we could design it so each Tag maintains its photos and its childrens' photos, adding and removing them dynamically. -- Jim On Fri, Apr 23, 2010 at 4:33 PM, Bengt Thuree wrote: > Will the performance be ok with a photo collection of 50,000 - 1,000,000 > Photos or above? > > Bengt > > On Fri, 2010-04-23 at 11:54 -0700, Jim Nelson wrote: >> So far, this sounds like steps in the right direction. ?Some notes: >> >> Our general strategy in Shotwell is to load the entire database in one >> swoop at startup and maintain all database rows in memory. ?Once the >> application is started, database access is limited to updates and >> deletes. ?(There are exceptions, particularly in Event.) ?Generally >> it's faster to do searching in memory than via the database. ?It's a >> trade-off, but one we take for performance reasons. >> >> If you read the architecture overview on Data Structures, I talk about >> the strategy I use for signalling (i.e. listeners, or observers as I >> call them). ?We definitely want each Tag to signal when it's children >> and parent is altered. ?I would also recommend having these signals >> reflected by TagSourceCollection, that way an observer can register >> once than register for every Tag. ?For example, LibraryWindow could >> register once and receive notifications on all Tags being moved >> around, updating the Sidebar accordingly. >> >> Also note that we've invested a lot of code time in fully synchronized >> data structures for the "big" objects and their collections: Tag, >> Photo, Event, etc. ?Since each Tag maintains a ViewCollection of Photo >> objects, it's easy to recurse up and down the hierarchy gathering a >> HashSet of Photos. ?It could be as simple as this: >> >> void get_photos_and_children_photos(Gee.HashSet photos) { >> ? ? photos.add_all(get_view().get_all()); >> ? ? foreach (Tag child in children) >> ? ? ? ? child.get_photos_and_children_photos(photos); >> } >> >> Since I don't expect Tag hierarchies to be crazy-deep, this is >> probably sound. ?(There can be no loops in the tree, of course. >> You'll need to protect against that.) >> >> Alternately, each Tag could monitor additions and deletions of its >> children and maintain a separate ViewCollection of its Photos and its >> descendants' photos. ?I'm not convinced that there's a big win here, >> but it's possible with the architecture in place. >> >> In short, I would discourage looking to the database for anything more >> than data persistence and organization. ?My feeling right now is, this >> can all be done in memory faster and and more efficiently than via >> SQL. >> >> -- Jim >> >> On Fri, Apr 23, 2010 at 5:20 AM, Ruslan A. Bondar wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hello, Adam. >> > >> > I think the code change will contain following steps: >> > 1. Add field "ParentTagId" to TagTable >> > 2. Change the TagTable class to handle this field. >> > 3. Change the find_parent_marker and add_tag_page methods in LibraryWindow to provide recursive tree creation for tag tree. >> > 4. Change drag'n'drop handler to allow moving tags between branches. >> > >> > And something more, such as listeners of tag tree alteration etc. I think these changes will not affect any other functionality. And no major changes in design are required. >> > >> > I think it would be better to store only photos "owned" by this tag, but on load build the full list, containing photos from this and all child tags. And for now I see several ways: >> > 1. Create helper table to speedup loading, but this will slow down tag reassigning (Tag moving between branches). This table may contain only 2 fields: TagId and AllTagPhotos. >> > 2. Walk over the table recursively and build the list via concatenation, this will be slightly slower. >> > >> > These are the common thoughts. I'll dig the source deeper during the weekend. >> > >> > On Thu, 22 Apr 2010 19:25:51 -0700 >> > Adam Dingle wrote: >> > >> >> Ruslan, >> >> >> >> thanks for your email. ?As you probably know, we're also interested >> >> in hierarchical tagging. >> >> >> >> I think at this point we'd like to implement a single-parent system, >> >> in which each tag can have multiple children but only one parent. >> >> This is ticket 1401. ?After that, we might consider extending the >> >> system to support multiple parents in some way. >> >> >> >> A single-parent tag system in Shotwell would work like this. ?In the >> >> sidebar, the user should be able to drag any tag A onto any other tag >> >> B; then A becomes a child of B. ?If the user drags any tag onto the >> >> Tags heading, then it becomes a top-level tag. >> >> >> >> If the user selects any tag, then Shotwell should display all photos >> >> which belong to the tag or any of its children. ?The set of photos is >> >> sorted according to the View->Sort Photos settings. ?If a photo >> >> belongs to multiple child tags, it is displayed only once in the >> >> sorted set. >> >> >> >> All tag names must be globally unique. ?For example, I can't create a >> >> tag named "washington" under a parent "states", and another tag also >> >> named "washington" under a parent tag "cities". >> >> >> >> You said you might like to participate in coding this feature - that >> >> would be great. ?If the description above sounds reasonable to you, >> >> as a next step maybe you could look at the Shotwell code and send a >> >> brief design proposal to this mailing list. ? In your proposal, >> >> please describe the database schema changes you intend, plus any new >> >> major classes introduced (if any) and any major changes to existing >> >> classes. We'd be happy to comment on your implementation plan. >> >> Thanks! >> >> >> >> adam >> >> >> >> Ruslan A. Bondar wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> >> > Hash: SHA1 >> >> > >> >> > Hello all. >> >> > >> >> > I have an idea, maybe similar to http://trac.yorba.org/ticket/1401, >> >> > but I'll tell in more details. >> >> > >> >> > It would be great to allow organizing tags into graph. >> >> > So one tag may have multiple parent and multiple children tags. And >> >> > each of them may be assigned to the photo. It will be more flexible >> >> > to organize your photos. As an owner of large, enough, photo album >> >> > (~100 GB of photos) I can say - This feature is VERY useful. >> >> > >> >> > Also I'd like to participate in coding of this feature. >> >> > -----BEGIN PGP SIGNATURE----- >> >> > Version: GnuPG v2.0.14 (GNU/Linux) >> >> > >> >> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu >> >> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q >> >> > =4KsN >> >> > -----END PGP SIGNATURE----- >> >> > _______________________________________________ >> >> > Shotwell mailing list >> >> > Shotwell at lists.yorba.org >> >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > >> >> > >> >> >> > >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v2.0.14 (GNU/Linux) >> > >> > iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg >> > G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ >> > =LAuc >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > Shotwell mailing list >> > Shotwell at lists.yorba.org >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > > From bengt at thuree.com Sat Apr 24 03:17:57 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sat, 24 Apr 2010 13:17:57 +1000 (EST) Subject: [Shotwell] Enhansment to shotwell In-Reply-To: References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <1272065622.3012.11.camel@lappis> Message-ID: <56527.59.154.63.92.1272079077.squirrel@denton.thuree.com> Ok, keeping my fingers crossed it will work fine for me (and a lot of other parents:) ) Only have 35,000 or so... and counting... Perhaps add so we can tag by just using keyboard... Something like F-Spot... Works very well. As soon as Shotwell can import XMP (f-spot/Digikam) and IPTC tags, then I am sure a lot of people will be happy to try it out... :) Looking forward to this... /Bengt Den L?, 2010-04-24, 10:31 skrev Jim Nelson: > Shotwell's not designed for that kind of scalability (yet!) I'm more > concerned with 10,000 photo collections. > > Right now I would want to design this correctly and cleanly, then do > performance testing to determine if there are bottlenecks and correct > them. As I mentioned, we could design it so each Tag maintains its > photos and its childrens' photos, adding and removing them > dynamically. > > -- Jim > > On Fri, Apr 23, 2010 at 4:33 PM, Bengt Thuree wrote: >> Will the performance be ok with a photo collection of 50,000 - 1,000,000 >> Photos or above? >> >> Bengt >> >> On Fri, 2010-04-23 at 11:54 -0700, Jim Nelson wrote: >>> So far, this sounds like steps in the right direction. ?Some notes: >>> >>> Our general strategy in Shotwell is to load the entire database in one >>> swoop at startup and maintain all database rows in memory. ?Once the >>> application is started, database access is limited to updates and >>> deletes. ?(There are exceptions, particularly in Event.) ?Generally >>> it's faster to do searching in memory than via the database. ?It's a >>> trade-off, but one we take for performance reasons. >>> >>> If you read the architecture overview on Data Structures, I talk about >>> the strategy I use for signalling (i.e. listeners, or observers as I >>> call them). ?We definitely want each Tag to signal when it's children >>> and parent is altered. ?I would also recommend having these signals >>> reflected by TagSourceCollection, that way an observer can register >>> once than register for every Tag. ?For example, LibraryWindow could >>> register once and receive notifications on all Tags being moved >>> around, updating the Sidebar accordingly. >>> >>> Also note that we've invested a lot of code time in fully synchronized >>> data structures for the "big" objects and their collections: Tag, >>> Photo, Event, etc. ?Since each Tag maintains a ViewCollection of Photo >>> objects, it's easy to recurse up and down the hierarchy gathering a >>> HashSet of Photos. ?It could be as simple as this: >>> >>> void get_photos_and_children_photos(Gee.HashSet photos) { >>> ? ? photos.add_all(get_view().get_all()); >>> ? ? foreach (Tag child in children) >>> ? ? ? ? child.get_photos_and_children_photos(photos); >>> } >>> >>> Since I don't expect Tag hierarchies to be crazy-deep, this is >>> probably sound. ?(There can be no loops in the tree, of course. >>> You'll need to protect against that.) >>> >>> Alternately, each Tag could monitor additions and deletions of its >>> children and maintain a separate ViewCollection of its Photos and its >>> descendants' photos. ?I'm not convinced that there's a big win here, >>> but it's possible with the architecture in place. >>> >>> In short, I would discourage looking to the database for anything more >>> than data persistence and organization. ?My feeling right now is, this >>> can all be done in memory faster and and more efficiently than via >>> SQL. >>> >>> -- Jim >>> >>> On Fri, Apr 23, 2010 at 5:20 AM, Ruslan A. Bondar >>> wrote: >>> > -----BEGIN PGP SIGNED MESSAGE----- >>> > Hash: SHA1 >>> > >>> > Hello, Adam. >>> > >>> > I think the code change will contain following steps: >>> > 1. Add field "ParentTagId" to TagTable >>> > 2. Change the TagTable class to handle this field. >>> > 3. Change the find_parent_marker and add_tag_page methods in >>> LibraryWindow to provide recursive tree creation for tag tree. >>> > 4. Change drag'n'drop handler to allow moving tags between branches. >>> > >>> > And something more, such as listeners of tag tree alteration etc. I >>> think these changes will not affect any other functionality. And no >>> major changes in design are required. >>> > >>> > I think it would be better to store only photos "owned" by this tag, >>> but on load build the full list, containing photos from this and all >>> child tags. And for now I see several ways: >>> > 1. Create helper table to speedup loading, but this will slow down >>> tag reassigning (Tag moving between branches). This table may contain >>> only 2 fields: TagId and AllTagPhotos. >>> > 2. Walk over the table recursively and build the list via >>> concatenation, this will be slightly slower. >>> > >>> > These are the common thoughts. I'll dig the source deeper during the >>> weekend. >>> > >>> > On Thu, 22 Apr 2010 19:25:51 -0700 >>> > Adam Dingle wrote: >>> > >>> >> Ruslan, >>> >> >>> >> thanks for your email. ?As you probably know, we're also interested >>> >> in hierarchical tagging. >>> >> >>> >> I think at this point we'd like to implement a single-parent system, >>> >> in which each tag can have multiple children but only one parent. >>> >> This is ticket 1401. ?After that, we might consider extending the >>> >> system to support multiple parents in some way. >>> >> >>> >> A single-parent tag system in Shotwell would work like this. ?In the >>> >> sidebar, the user should be able to drag any tag A onto any other >>> tag >>> >> B; then A becomes a child of B. ?If the user drags any tag onto the >>> >> Tags heading, then it becomes a top-level tag. >>> >> >>> >> If the user selects any tag, then Shotwell should display all photos >>> >> which belong to the tag or any of its children. ?The set of photos >>> is >>> >> sorted according to the View->Sort Photos settings. ?If a photo >>> >> belongs to multiple child tags, it is displayed only once in the >>> >> sorted set. >>> >> >>> >> All tag names must be globally unique. ?For example, I can't create >>> a >>> >> tag named "washington" under a parent "states", and another tag also >>> >> named "washington" under a parent tag "cities". >>> >> >>> >> You said you might like to participate in coding this feature - that >>> >> would be great. ?If the description above sounds reasonable to you, >>> >> as a next step maybe you could look at the Shotwell code and send a >>> >> brief design proposal to this mailing list. ? In your proposal, >>> >> please describe the database schema changes you intend, plus any new >>> >> major classes introduced (if any) and any major changes to existing >>> >> classes. We'd be happy to comment on your implementation plan. >>> >> Thanks! >>> >> >>> >> adam >>> >> >>> >> Ruslan A. Bondar wrote: >>> >> > -----BEGIN PGP SIGNED MESSAGE----- >>> >> > Hash: SHA1 >>> >> > >>> >> > Hello all. >>> >> > >>> >> > I have an idea, maybe similar to >>> http://trac.yorba.org/ticket/1401, >>> >> > but I'll tell in more details. >>> >> > >>> >> > It would be great to allow organizing tags into graph. >>> >> > So one tag may have multiple parent and multiple children tags. >>> And >>> >> > each of them may be assigned to the photo. It will be more >>> flexible >>> >> > to organize your photos. As an owner of large, enough, photo album >>> >> > (~100 GB of photos) I can say - This feature is VERY useful. >>> >> > >>> >> > Also I'd like to participate in coding of this feature. >>> >> > -----BEGIN PGP SIGNATURE----- >>> >> > Version: GnuPG v2.0.14 (GNU/Linux) >>> >> > >>> >> > iEYEARECAAYFAkvNx+QACgkQRadsTlsSykPASgCcDBrgeobgyNweH2CLTaFt1xZu >>> >> > gqUAn3jfVCjMrDPuwQJQWvh3KBYqdq7q >>> >> > =4KsN >>> >> > -----END PGP SIGNATURE----- >>> >> > _______________________________________________ >>> >> > Shotwell mailing list >>> >> > Shotwell at lists.yorba.org >>> >> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> > >>> >> > >>> >> >>> > >>> > -----BEGIN PGP SIGNATURE----- >>> > Version: GnuPG v2.0.14 (GNU/Linux) >>> > >>> > iEYEARECAAYFAkvRkIYACgkQRadsTlsSykNC4gCeJ6XCVc9RzUwluOwj/lo960xg >>> > G30AnAvyDgsu+DK9raFT2LUZFOtf3APZ >>> > =LAuc >>> > -----END PGP SIGNATURE----- >>> > _______________________________________________ >>> > 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 >>> >> >> >> > > -- Bengt Thuree bengt at thuree.com From dmitry at gribanov.me Sun Apr 25 21:04:13 2010 From: dmitry at gribanov.me (Dmitry Gribanov) Date: Mon, 26 Apr 2010 01:04:13 +0400 Subject: [Shotwell] double click Message-ID: <9ED3E699-79C7-4C1E-B3BC-F0061D066F79@gribanov.me> Hello there, i want to change double click on any photo to view to single click for that action. Is shotwell have option for this? Thanks! From adam at yorba.org Mon Apr 26 14:28:37 2010 From: adam at yorba.org (Adam Dingle) Date: Mon, 26 Apr 2010 07:28:37 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <56527.59.154.63.92.1272079077.squirrel@denton.thuree.com> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <1272065622.3012.11.camel@lappis> <56527.59.154.63.92.1272079077.squirrel@denton.thuree.com> Message-ID: <4BD5A315.10904@yorba.org> Bengt Thuree wrote: > Perhaps add so we can tag by just using keyboard... > Something like F-Spot... Works very well. It's already easy to add tags using the keyboard in Shotwell. Simply press Ctrl+T (the keyboard shortcut for the Tags->Add Tags command) and type the tags you want. If they don't already exist, Shotwell will create them. Or did you mean something else? adam From jim at yorba.org Mon Apr 26 17:56:00 2010 From: jim at yorba.org (Jim Nelson) Date: Mon, 26 Apr 2010 10:56:00 -0700 Subject: [Shotwell] double click In-Reply-To: <9ED3E699-79C7-4C1E-B3BC-F0061D066F79@gribanov.me> References: <9ED3E699-79C7-4C1E-B3BC-F0061D066F79@gribanov.me> Message-ID: If we were to switch it to a single-click, how would you select it? This doesn't seem intuitive, and I don't know of another application that has this behavior. -- Jim On Sun, Apr 25, 2010 at 2:04 PM, Dmitry Gribanov wrote: > Hello there, i want to change double click on any photo to view to single click for that action. Is shotwell have option for this? > Thanks! > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From david.velazquez08 at gmail.com Tue Apr 27 03:55:20 2010 From: david.velazquez08 at gmail.com (David Velazquez) Date: Mon, 26 Apr 2010 23:55:20 -0400 Subject: [Shotwell] Auto Import Pictures into another directory format Message-ID: Currently when importing pictures into shotwell and the "Copy files to Pictures photo library" button is checked it imports them and organizes them by year/month/day they are taken. Is it possible or might it be in the future to organize them in a user specific manner, for example, could it ask for a directory name rather than just assume a user wants it organized by the year/month/day they were taken. I organize my library by event rather than by date of event for example (Christmas 2005 rather than 2005/12/25). Following this thought, I wonder if it's possible to change the Events tab in Shotwell to organize them by actual event rather than date of it. I notice that the tab gets it's information from the metadata also (although not necessarily from how the directory structure is organized). To give a more clear vision of what I'm talking about: When a camera is connected or File -> Import from Folder is clicked Shotwell asks what we want it to import, much like it does now, and where to put it (under what label, lets say). It then performs its magic and grabs the "Event" name from the information entered when it originally asked what directory to put it in. This could, of course, be user editable. Would a preferences button work or am I just complicating things. I've always organized my images by hand as I said before, but it might just be time for me to get with the program :) Thanks! Dave From bengt at thuree.com Wed Apr 28 14:30:22 2010 From: bengt at thuree.com (Bengt Thuree) Date: Thu, 29 Apr 2010 00:30:22 +1000 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <4BD5A315.10904@yorba.org> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <1272065622.3012.11.camel@lappis> <56527.59.154.63.92.1272079077.squirrel@denton.thuree.com> <4BD5A315.10904@yorba.org> Message-ID: <1272465022.24983.2.camel@leo.thuree.com> On Mon, 2010-04-26 at 07:28 -0700, Adam Dingle wrote: > Bengt Thuree wrote: > > Perhaps add so we can tag by just using keyboard... > > Something like F-Spot... Works very well. > > It's already easy to add tags using the keyboard in Shotwell. Simply > press Ctrl+T (the keyboard shortcut for the Tags->Add Tags command) > and type the tags you want. If they don't already exist, Shotwell > will create them. Or did you mean something else? So I see :) But, some small enhancements perhaps ? Does not work in full screen, nor is there any auto-complete. But other things are more important I guess at this stage. /Bengt From bengt.thuree at gmail.com Wed Apr 28 14:39:07 2010 From: bengt.thuree at gmail.com (Bengt Thuree) Date: Thu, 29 Apr 2010 00:39:07 +1000 Subject: [Shotwell] mysql/postgresql as backend? Message-ID: <1272465547.24983.11.camel@leo.thuree.com> Hi Any thoughts/plans on coming up with a proper backend, so the database can be accessed by different persons at the same time. I saw GnuCASH is using libdbi. Would this be of interest in Shotwell? In my case, I have a number of desktops/laptops/thin clients, and one fileserver. I am having the photos and photo db on the file server, and would like to be able to access my photos from which ever computer I want, as well as from multiple computers at the same time. Fingers crossed for this has been thought of :) Bengt From jim at yorba.org Wed Apr 28 17:41:16 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 28 Apr 2010 10:41:16 -0700 Subject: [Shotwell] mysql/postgresql as backend? In-Reply-To: <1272465547.24983.11.camel@leo.thuree.com> References: <1272465547.24983.11.camel@leo.thuree.com> Message-ID: We've thought down these lines, but it's not as simple as it seems. The database is not used by Shotwell in a traditional sense, a la a web application. If we hit the database every time we needed information about a photo or a tag or an event, Shotwell would be slow indeed. This is not a limitation of SQLite; using MySQL or PostgreSQL would not make things different. Much of the database is loaded into memory at startup and maintained there. When a field is changed, it's written out to disk, but kept in memory as well. If another application were to write to the database while Shotwell was running, Shotwell would have no idea the change has been made, and now things are messed up. Some of this thinking is reflected in this ticket: http://trac.yorba.org/ticket/1699 There's a lot to think about there, however. -- Jim On Wed, Apr 28, 2010 at 7:39 AM, Bengt Thuree wrote: > Hi > > Any thoughts/plans on coming up with a proper backend, so the database > can be accessed by different persons at the same time. > > I saw GnuCASH is using libdbi. Would this be of interest in Shotwell? > > In my case, I have a number of desktops/laptops/thin clients, and one > fileserver. I am having the photos and photo db on the file server, and > would like to be able to access my photos from which ever computer I > want, as well as from multiple computers at the same time. > > Fingers crossed for this has been thought of :) > > Bengt > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From jim at yorba.org Wed Apr 28 17:45:12 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 28 Apr 2010 10:45:12 -0700 Subject: [Shotwell] Enhansment to shotwell In-Reply-To: <1272465022.24983.2.camel@leo.thuree.com> References: <20100420192726.24bb0560@proton-sss.ru> <4BD1052F.2010004@yorba.org> <20100423162015.1f53ddb1@proton-sss.ru> <1272065622.3012.11.camel@lappis> <56527.59.154.63.92.1272079077.squirrel@denton.thuree.com> <4BD5A315.10904@yorba.org> <1272465022.24983.2.camel@leo.thuree.com> Message-ID: You are correct -- full-screen mode is lacking a number of features. I've updated a ticket to reflect this: http://trac.yorba.org/ticket/324 Auto-complete is definitely something we want to address in the future: http://trac.yorba.org/ticket/1334 -- Jim On Wed, Apr 28, 2010 at 7:30 AM, Bengt Thuree wrote: > On Mon, 2010-04-26 at 07:28 -0700, Adam Dingle wrote: >> Bengt Thuree wrote: >> > Perhaps add so we can tag by just using keyboard... >> > Something like F-Spot... Works very well. >> >> It's already easy to add tags using the keyboard in Shotwell. ?Simply >> press Ctrl+T (the keyboard shortcut for the Tags->Add Tags command) >> and type the tags you want. ?If they don't already exist, Shotwell >> will create them. ?Or did you mean something else? > > So I see :) > But, some small enhancements perhaps ? > Does not work in full screen, nor is there any auto-complete. > But other things are more important I guess at this stage. > > /Bengt > > From jim at yorba.org Wed Apr 28 17:47:36 2010 From: jim at yorba.org (Jim Nelson) Date: Wed, 28 Apr 2010 10:47:36 -0700 Subject: [Shotwell] RAW support in Shotwell In-Reply-To: References: Message-ID: Thanks for your comments (and praise!) gegl is something we're investigating, as well as color profiles. Just curious, did you learn any more about the initializing problem with your camera? I highly recommend upgrading to the latest gPhoto, which is 2.4.9. -- Jim On Thu, Apr 22, 2010 at 5:49 PM, asubedi wrote: > I recently heard about Yorba and Shotwell and installed Shotwell in > Ubuntu 10.4. Compared to F-spot it's pretty good and it is really > responsive. I also plugged in my Cannon 40D to import my photos. But > it did not work. However, Nautilus and F-spot could download the pics. > Before filing a bug, I thought I would try to fix it myself and have > checked out the source from subversion. There seems to be some bug in > initializing the camera through libgphoto but I haven't pin-pointed it > yet. I'll do some work this weekend and if I don't make any progress, > will file a bug. > > Regarding the RAW support, GEGL based work flow would be the best :-) > In the meantime, I would probably prefer use of libraw if I used > Shotwell. I am a (very) amateur photographer and I do most of my > photoprocessing in my MacbookPro using the software that came with > Cannon (Digital Photo Professional). I do not own Photoshop and find > that the simple program suffices my needs. The only modifications I > make on my photos are change brightness, contrast, tone, saturation, > and sharpness. I also modify histogram curves that correspond to > various picture styles -- landscape, portrait, faithful, etc. One > thing the Cannon DPP does not do is rotate pics by arbitrary angle (so > I can level the pics). However, the main reason I am beholden to my > Mac ?for my photography is the colour profile management. Hopefully, > some thought has gone into incorporating and managing ICC profiles. > > Best, > Alaska > > PS: Another thing for which I use my Mac is viewing and playing the > MIDI of Powertab files using TabView. I hope Fillmore will fulfill > this need someday. Good luck for you Yorba guys! > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From matthias.clasen at gmail.com Thu Apr 29 20:18:41 2010 From: matthias.clasen at gmail.com (Matthias Clasen) Date: Thu, 29 Apr 2010 16:18:41 -0400 Subject: [Shotwell] translation updates for 0.5 Message-ID: Hey, I have gotten at least one bug report in Fedora https://bugzilla.redhat.com/show_bug.cgi?id=583847 asking about translation updates (for Russian). I note that the 0.5 release that we have in F13 _does_ have Russian translation, but the .po file is largely empty, while trunk seems to have pretty complete translations. I don't know about the amount of string changes between 0.5 and trunk, and I wonder if it would be possible to merge the translations from trunk into 0.5 and do a 0.5.2 release that largely focuses on translation updates ? I'm sure it would be well-received in Fedora 13. Keep up the great work, Matthias From adam at yorba.org Thu Apr 29 21:58:41 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 29 Apr 2010 14:58:41 -0700 Subject: [Shotwell] translation updates for 0.5 In-Reply-To: References: Message-ID: <4BDA0111.3070707@yorba.org> Matthias, that's a good idea. We've received several new or greatly expanded translations since 0.5 shipped, including Russian, Ukranian, Greek and Finnish. We'll plan to issue a 0.5.2 release in the next week or two including these translations (and perhaps any others that arrive in the meantime). adam Matthias Clasen wrote: > Hey, I have gotten at least one bug report in Fedora > https://bugzilla.redhat.com/show_bug.cgi?id=583847 asking about > translation updates (for Russian). I note that the 0.5 release that we > have in F13 _does_ have Russian translation, but the .po file is > largely empty, while trunk seems to have pretty complete translations. > I don't know about the amount of string changes between 0.5 and trunk, > and I wonder if it would be possible to merge the translations from > trunk into 0.5 and do a 0.5.2 release that largely focuses on > translation updates ? I'm sure it would be well-received in Fedora 13. > > Keep up the great work, > > Matthias > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From bengt at thuree.com Fri Apr 30 12:48:17 2010 From: bengt at thuree.com (Bengt Thuree) Date: Fri, 30 Apr 2010 22:48:17 +1000 Subject: [Shotwell] mysql/postgresql as backend? In-Reply-To: References: <1272465547.24983.11.camel@leo.thuree.com> Message-ID: <1272631697.6320.11.camel@lappis> Yes I can see that this ticket (D-Bus) would solve some issues. But not the one with a family and a number of computers. For instance, I am updating the photos from my laptop (connected to our file server), while my wife is looking at the old photos (again, through our file server) as well as possible publishing some photos or modifying some tags/ratings here and there. This would not be possible with sqlite as far as I am aware (single program who reads), but very possible with a sql backbone. Perhaps a function that informs all other connected clients to re-read part/all of the database? While on the subject of family :) Perhaps a locking feature, to ensure children can not modify any photos/tags :) /Bengt On Wed, 2010-04-28 at 10:41 -0700, Jim Nelson wrote: > We've thought down these lines, but it's not as simple as it seems. > > The database is not used by Shotwell in a traditional sense, a la a > web application. If we hit the database every time we needed > information about a photo or a tag or an event, Shotwell would be slow > indeed. This is not a limitation of SQLite; using MySQL or PostgreSQL > would not make things different. > > Much of the database is loaded into memory at startup and maintained > there. When a field is changed, it's written out to disk, but kept in > memory as well. If another application were to write to the database > while Shotwell was running, Shotwell would have no idea the change has > been made, and now things are messed up. > > Some of this thinking is reflected in this ticket: > http://trac.yorba.org/ticket/1699 There's a lot to think about there, > however. > > -- Jim > > On Wed, Apr 28, 2010 at 7:39 AM, Bengt Thuree wrote: > > Hi > > > > Any thoughts/plans on coming up with a proper backend, so the database > > can be accessed by different persons at the same time. > > > > I saw GnuCASH is using libdbi. Would this be of interest in Shotwell? > > > > In my case, I have a number of desktops/laptops/thin clients, and one > > fileserver. I am having the photos and photo db on the file server, and > > would like to be able to access my photos from which ever computer I > > want, as well as from multiple computers at the same time. > > > > Fingers crossed for this has been thought of :) > > > > Bengt > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > From tommy.he at linux.com Fri Apr 30 14:43:26 2010 From: tommy.he at linux.com (Tommy He) Date: Fri, 30 Apr 2010 15:43:26 +0100 Subject: [Shotwell] translation updates for 0.5 In-Reply-To: <4BDA0111.3070707@yorba.org> References: <4BDA0111.3070707@yorba.org> Message-ID: Adam, I will try my best to see if someone would like to add Traditional Chinese in these weeks. Regards, On 29 April 2010 22:58, Adam Dingle wrote: > Matthias, > > that's a good idea. We've received several new or greatly expanded > translations since 0.5 shipped, including Russian, Ukranian, Greek and > Finnish. We'll plan to issue a 0.5.2 release in the next week or two > including these translations (and perhaps any others that arrive in the > meantime). > > adam > > Matthias Clasen wrote: > > Hey, I have gotten at least one bug report in Fedora > > https://bugzilla.redhat.com/show_bug.cgi?id=583847 asking about > > translation updates (for Russian). I note that the 0.5 release that we > > have in F13 _does_ have Russian translation, but the .po file is > > largely empty, while trunk seems to have pretty complete translations. > > I don't know about the amount of string changes between 0.5 and trunk, > > and I wonder if it would be possible to merge the translations from > > trunk into 0.5 and do a 0.5.2 release that largely focuses on > > translation updates ? I'm sure it would be well-received in Fedora 13. > > > > Keep up the great work, > > > > Matthias > > _______________________________________________ > > 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 > -- Take a Deep Breath out of Windows From jim at yorba.org Fri Apr 30 18:34:58 2010 From: jim at yorba.org (Jim Nelson) Date: Fri, 30 Apr 2010 11:34:58 -0700 Subject: [Shotwell] Auto Import Pictures into another directory format In-Reply-To: References: Message-ID: This is actually already ticketed: http://trac.yorba.org/ticket/1597. I'll also add to the ticket some of your suggestions about naming the directories. -- Jim On Mon, Apr 26, 2010 at 8:55 PM, David Velazquez wrote: > Currently when importing pictures into shotwell and the "Copy files to > Pictures photo library" button is checked it imports them and organizes them > by year/month/day they are taken. > > Is it possible or might it be in the future to organize them in a user > specific manner, for example, could it ask for a directory name rather than > just assume a user wants it organized by the year/month/day they were taken. > I organize my library by event rather than by date of event for example > (Christmas 2005 rather than 2005/12/25). Following this thought, I wonder if > it's possible to change the Events tab in Shotwell to organize them by > actual event rather than date of it. I notice that the tab gets it's > information from the metadata also (although not necessarily from how the > directory structure is organized). > > To give a more clear vision of what I'm talking about: > > When a camera is connected or File -> Import from Folder is clicked Shotwell > asks what we want it to import, much like it does now, and where to put it > (under what label, lets say). It then performs its magic and grabs the > "Event" name from the information entered when it originally asked what > directory to put it in. This could, of course, be user editable. Would a > preferences button work or am I just complicating things. > > I've always organized my images by hand as I said before, but it might just > be time for me to get with the program :) > > Thanks! > > Dave > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Fri Apr 30 19:15:27 2010 From: adam at yorba.org (Adam Dingle) Date: Fri, 30 Apr 2010 12:15:27 -0700 Subject: [Shotwell] mysql/postgresql as backend? In-Reply-To: <1272631697.6320.11.camel@lappis> References: <1272465547.24983.11.camel@leo.thuree.com> <1272631697.6320.11.camel@lappis> Message-ID: <4BDB2C4F.8040006@yorba.org> Bengt, thanks for your latest message. We're also very interested in extending Shotwell to sync and/or share photos, either across a local network or across the Internet. Of course there are many possible mechanisms we could use to do this - conceivably we could use a database file which is shared across the local network using file sharing (as you suggested), or a server, or peer-to-peer syncing, or some sort of distributed database system. We're as yet undecided about which mechanism to use. None of this will be in the upcoming Shotwell 0.6, but we hope to implement some sort of sharing/syncing in the future, perhaps even later this year. See these tickets: http://trac.yorba.org/ticket/1292 (share/sync photo library between machines) http://trac.yorba.org/ticket/1572 (Shotwell Server) adam On 04/30/2010 05:48 AM, Bengt Thuree wrote: > Yes I can see that this ticket (D-Bus) would solve some issues. > But not the one with a family and a number of computers. > > For instance, I am updating the photos from my laptop (connected to our > file server), while my wife is looking at the old photos (again, through > our file server) as well as possible publishing some photos or modifying > some tags/ratings here and there. > > This would not be possible with sqlite as far as I am aware (single > program who reads), but very possible with a sql backbone. > Perhaps a function that informs all other connected clients to re-read > part/all of the database? > > While on the subject of family :) Perhaps a locking feature, to ensure > children can not modify any photos/tags :) > > /Bengt > > On Wed, 2010-04-28 at 10:41 -0700, Jim Nelson wrote: > >> We've thought down these lines, but it's not as simple as it seems. >> >> The database is not used by Shotwell in a traditional sense, a la a >> web application. If we hit the database every time we needed >> information about a photo or a tag or an event, Shotwell would be slow >> indeed. This is not a limitation of SQLite; using MySQL or PostgreSQL >> would not make things different. >> >> Much of the database is loaded into memory at startup and maintained >> there. When a field is changed, it's written out to disk, but kept in >> memory as well. If another application were to write to the database >> while Shotwell was running, Shotwell would have no idea the change has >> been made, and now things are messed up. >> >> Some of this thinking is reflected in this ticket: >> http://trac.yorba.org/ticket/1699 There's a lot to think about there, >> however. >> >> -- Jim >> >> On Wed, Apr 28, 2010 at 7:39 AM, Bengt Thuree wrote: >> >>> Hi >>> >>> Any thoughts/plans on coming up with a proper backend, so the database >>> can be accessed by different persons at the same time. >>> >>> I saw GnuCASH is using libdbi. Would this be of interest in Shotwell? >>> >>> In my case, I have a number of desktops/laptops/thin clients, and one >>> fileserver. I am having the photos and photo db on the file server, and >>> would like to be able to access my photos from which ever computer I >>> want, as well as from multiple computers at the same time. >>> >>> Fingers crossed for this has been thought of :) >>> >>> Bengt >>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> >> > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From bengt at thuree.com Fri Apr 30 23:18:26 2010 From: bengt at thuree.com (Bengt Thuree) Date: Sat, 01 May 2010 09:18:26 +1000 Subject: [Shotwell] mysql/postgresql as backend? In-Reply-To: <4BDB2C4F.8040006@yorba.org> References: <1272465547.24983.11.camel@leo.thuree.com> <1272631697.6320.11.camel@lappis> <4BDB2C4F.8040006@yorba.org> Message-ID: <1272669506.2515.2.camel@lappis> I need to study the shotwell tickets much more :) I really like where you want to bring Shotwell, and am looking forward to it... Actually, can't wait for shotwell to import xmp/iptc tags so I can start using it more seriously... :) /Bengt On Fri, 2010-04-30 at 12:15 -0700, Adam Dingle wrote: > Bengt, > > thanks for your latest message. We're also very interested in extending > Shotwell to sync and/or share photos, either across a local network or > across the Internet. Of course there are many possible mechanisms we > could use to do this - conceivably we could use a database file which is > shared across the local network using file sharing (as you suggested), > or a server, or peer-to-peer syncing, or some sort of distributed > database system. We're as yet undecided about which mechanism to use. > None of this will be in the upcoming Shotwell 0.6, but we hope to > implement some sort of sharing/syncing in the future, perhaps even later > this year. See these tickets: > > http://trac.yorba.org/ticket/1292 (share/sync photo library between > machines) > http://trac.yorba.org/ticket/1572 (Shotwell Server) > > adam > > On 04/30/2010 05:48 AM, Bengt Thuree wrote: > > Yes I can see that this ticket (D-Bus) would solve some issues. > > But not the one with a family and a number of computers. > > > > For instance, I am updating the photos from my laptop (connected to our > > file server), while my wife is looking at the old photos (again, through > > our file server) as well as possible publishing some photos or modifying > > some tags/ratings here and there. > > > > This would not be possible with sqlite as far as I am aware (single > > program who reads), but very possible with a sql backbone. > > Perhaps a function that informs all other connected clients to re-read > > part/all of the database? > > > > While on the subject of family :) Perhaps a locking feature, to ensure > > children can not modify any photos/tags :) > > > > /Bengt > > > > On Wed, 2010-04-28 at 10:41 -0700, Jim Nelson wrote: > > > >> We've thought down these lines, but it's not as simple as it seems. > >> > >> The database is not used by Shotwell in a traditional sense, a la a > >> web application. If we hit the database every time we needed > >> information about a photo or a tag or an event, Shotwell would be slow > >> indeed. This is not a limitation of SQLite; using MySQL or PostgreSQL > >> would not make things different. > >> > >> Much of the database is loaded into memory at startup and maintained > >> there. When a field is changed, it's written out to disk, but kept in > >> memory as well. If another application were to write to the database > >> while Shotwell was running, Shotwell would have no idea the change has > >> been made, and now things are messed up. > >> > >> Some of this thinking is reflected in this ticket: > >> http://trac.yorba.org/ticket/1699 There's a lot to think about there, > >> however. > >> > >> -- Jim > >> > >> On Wed, Apr 28, 2010 at 7:39 AM, Bengt Thuree wrote: > >> > >>> Hi > >>> > >>> Any thoughts/plans on coming up with a proper backend, so the database > >>> can be accessed by different persons at the same time. > >>> > >>> I saw GnuCASH is using libdbi. Would this be of interest in Shotwell? > >>> > >>> In my case, I have a number of desktops/laptops/thin clients, and one > >>> fileserver. I am having the photos and photo db on the file server, and > >>> would like to be able to access my photos from which ever computer I > >>> want, as well as from multiple computers at the same time. > >>> > >>> Fingers crossed for this has been thought of :) > >>> > >>> Bengt > >>> > >>> _______________________________________________ > >>> 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 >