Hello,
my name is Veaceslav and I will work on implementing a Tag Manager for digiKam as part of Google Summer of Code program. Here is my proposal:
if you use tags a lot and find an important option that should be added, please let me know. Also, all your suggestions are really appreciated. It will help me to build a useful tool. Don't leave you suggestions until it's too late and lots of things must be rewritten. Cheers, Veaceslav _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Keep nepomuk optional for Linux too! Not all of us run KDE desktops!
From your proposal: "digiKam’s nepomuk interface is currently broken due to major changes into Nepomuk Api and it’s currently not in use. Nepomuk sync options are relevant and will allow digiKam to better integrate with KDE Desktop. Other platforms such as Windows or Mac OS, doesn’t offer support for nepomuk, and this features should be disabled when compiling with corresponding CMake flag. Nepomuk interface was written in 2009 when Nepomuk was at early stages of development and Sparql queries were the only way of getting tags." I run Linux but I don't run a KDE desktop. I don't need digiKam to integrate with the KDE desktop. I only have installed the minimal KDE installed to actually run digiKam and krita (these are the ONLY kde apps that I run). I dislike nepomuk intensely and don't want it installed on my computer. If that is what it would take, I would actually consider switching to Windows to avoid nepomuk. I wouldn't actually do it, but I'd seriously consider it. Many people run digiKam because it is the best photo management software available. Many of these people run Linux. Many of them don't use the KDE desktop and hence have no need for nepomuk. Even some KDE users routinely disable nepomuk as soon as they install KDE. So PLEASE keep nepomuk optional even for Linux users, and even for KDE Linux users. Kind regards, Elle Stone -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Am 25.06.2013 16:05, schrieb Elle Stone: > So PLEASE keep nepomuk optional even for Linux users, and even for KDE > Linux users. Yes, please. I use KDE but no nepomuk, will never use it... Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com google+: https://plus.google.com/109534388657020287386 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
Actually digiKam contains code to communicate with nepomuk, but it's deprecated and need to be rewritten. I think I'll keep Nepomuk optional and will add an option to disable nepomuk sync even for users who have nepomuk installed, if devs won't mind.
And yes, I also run a minimal KDE with nepomuk and whole akonadi thing disabled. On Tue, Jun 25, 2013 at 5:05 PM, Elle Stone <[hidden email]> wrote: Keep nepomuk optional for Linux too! Not all of us run KDE desktops! _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hi all,
As Veaceslav said, Nepomuk have been implemented and will still optional. As main code is already here, but have been broken due to API changes from Nepomuk, this interface have been disabled. The goal of Nepomuk job in this project is to re-activate this interface, as Nepomuk recieve a copy of tags from digiKam DB. In all case digiKam DB will never be moved to Nepomuk (:=)))... Best Gilles Caulier 2013/6/25 Veaceslav Munteanu <[hidden email]>: > Actually digiKam contains code to communicate with nepomuk, but it's > deprecated and need to be rewritten. > I think I'll keep Nepomuk optional and will add an option to disable nepomuk > sync even for users who have nepomuk installed, if devs won't mind. > > And yes, I also run a minimal KDE with nepomuk and whole akonadi thing > disabled. > > > On Tue, Jun 25, 2013 at 5:05 PM, Elle Stone <[hidden email]> wrote: >> >> Keep nepomuk optional for Linux too! Not all of us run KDE desktops! >> >> From your proposal: >> >> "digiKam’s nepomuk interface is currently broken due to major changes >> into Nepomuk Api and it’s currently not in use. Nepomuk sync options >> are relevant and will allow digiKam to better integrate with KDE >> Desktop. Other platforms such as Windows or Mac OS, doesn’t offer >> support for nepomuk, and this features should be disabled when >> compiling with corresponding CMake flag. Nepomuk interface was written >> in 2009 when Nepomuk was at early stages of development and Sparql >> queries were the only way of getting tags." >> >> I run Linux but I don't run a KDE desktop. I don't need digiKam to >> integrate with the KDE desktop. I only have installed the minimal KDE >> installed to actually run digiKam and krita (these are the ONLY kde >> apps that I run). >> >> I dislike nepomuk intensely and don't want it installed on my >> computer. If that is what it would take, I would actually consider >> switching to Windows to avoid nepomuk. I wouldn't actually do it, but >> I'd seriously consider it. >> >> Many people run digiKam because it is the best photo management >> software available. Many of these people run Linux. Many of them don't >> use the KDE desktop and hence have no need for nepomuk. Even some KDE >> users routinely disable nepomuk as soon as they install KDE. >> >> So PLEASE keep nepomuk optional even for Linux users, and even for KDE >> Linux users. >> >> Kind regards, >> Elle Stone >> >> -- >> http://ninedegreesbelow.com - articles on open source digital photography >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Veaceslav Munteanu-2
>I think I'll keep Nepomuk optional and will add an option to disable nepomuk sync
>even for users who have nepomuk installed, if devs won't mind. Thanks! Sincerely and heartily thank you! If the devs do mind, let us know so we can try to persuade them otherwise! In the meantime, regarding tagging in general, has someone given you a list of (or have you searched for) the relevant bug reports, feature requests and perhaps relevant recent user threads? Such as this thread? http://digikam.1695700.n4.nabble.com/How-to-remove-quot-left-behind-quot-tag-tree-td4660139.html Regarding synchronizing the database and what's written to files: One feature that I would like very much is having the tags written to the database and the image or xmp files (I only write to xmp sidecar files), but have the "write to sidecar (or image)" action not happen automatically, but only as desired, such as at the end of a tagging session. It might be nice to have an option to automatically offer to write to file before closing digiKam. At present I disable writing to the sidecar files until I'm finished tagging (because writing to the database is so much faster), then re-enable writing to write the tags to the files just before I close digiKam (because I don't trust only having the database hold the information). These extra "disable-enable-disable" steps are fiddly and easy to forget. Also, is better image searching/filtering by tags on your agenda? Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Thank you Elle, for giving me the link. I have some bugzilla entries, but with limited information. That's why I decided to post on this mailing list, maybe users can provide me with more info. For now, I'm working on implementing the user interface(mock-ups from my proposal, if you want to change something tell me as soon as possible) and after this will see what policies to apply to maintain info in database and metadata coherent.
I will contact you if any questions will arise :) On Tue, Jun 25, 2013 at 6:16 PM, Elle Stone <[hidden email]> wrote:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Veaceslav Munteanu-2
Hi Veaceslav,
Bug 268688 https://bugs.kde.org/show_bug.cgi?id=268688 that is mentioned in the thread that Elle linked to contains a number of conflicting wishes. The part of your proposal that seems to address any of those wishes is where you offer to 'Write tags from database to image' and remove obsolete tags. I see this as a heavy handed maintenance operation that will not really fix the underlying issue. The way I would like the bug I would like to see resolved (that got merged into 268688) is when a change is made to the tags hierarchy (ie move or delete a tag) that will render images with applied metadata out of sync, to be offered 3 options or to have one of them selected in preferences: 1) apply change only to database 2) add change to a queue to be actioned later when it will update affected images 3) apply change immediately to database and all affected images. Also please note that I am talking about applying a 'change' - this is not the same as syncing the database to the image metadata. Also I would like to see https://bugs.kde.org/show_bug.cgi?id=309598 resolved. And there should be a bug or wishlist somewhere about copying tags from one image to others. Good luck and all the best, Andrew On 25/06/13 11:18, Veaceslav Munteanu wrote: > Hello, > > my name is Veaceslav and I will work on implementing a Tag Manager for > digiKam as part of Google Summer of Code program. > > Here is my proposal: > > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/slavuttici/35001 > > if you use tags a lot and find an important option that should be added, > please let me know. > > Also, all your suggestions are really appreciated. It will help me to > build a useful tool. > > Don't leave you suggestions until it's too late and lots of things must > be rewritten. > > > Cheers, > > Veaceslav > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
There is a reason why database and image metadata shouldn't be out of sync... If I'm not mistaken, image collection scan read metadata from images and update database. Image scan can be triggered by your changes on local filesystem and you will have all your data from database overwritten. My first idea was to operate all changes on database only. After you're finished, use sync options for either undo all changes by reading from image or save all changes to image by triggering write to image metadata and delete obsolete tags. Still need to read all suggestions, maybe I missed something. Until then, I'm working on user interface. On Jun 25, 2013 9:20 PM, "Andrew Goodbody" <[hidden email]> wrote:
Hi Veaceslav, _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 25/06/13 20:00, Veaceslav Munteanu wrote:
> There is a reason why database and image metadata shouldn't be out of > sync... While this may be true in an ideal world unfortunately there are scenarios that are somewhat reasonable for having them out of sync. eg I have some photos sent to me by a friend that has some tags applied to it. I do not want to remove those tags nor do I wish to import them into my database but I do wish to add my own tags. > If I'm not mistaken, image collection scan read metadata from images and > update database. Image scan can be triggered by your changes on local > filesystem and you will have all your data from database overwritten. > > My first idea was to operate all changes on database only. After you're > finished, use sync options for either undo all changes by reading from > image or save all changes to image by triggering write to image metadata > and delete obsolete tags. A sync operation is going to be very slow on any reasonably large collection of photos unless you are going to maintain a list of affected photos. > Still need to read all suggestions, maybe I missed something. Until > then, I'm working on user interface. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hmm, a couple of times now Veaceslav has asked for input regarding the
tagging user interface, and we all keep responding with comments about the problem of database and image/xmp-sidecar synchronization. So in response to the question of user interface: I like the existing user interface as regards creating new tags and adding tags to images. "- Expand Tag Tree - All tag tree’s children will become visible instead of expanding all parent nodes. This option is a must for a big tag tree, because clicking each parent can be frustrating," Assuming I understand what you are saying, although having the option of expanding all subtags with one click would be a nice touch, some of my tag trees are deep enough that having everything expand by default (no option to disable) would then require scrolling down to get to the desired tag. There is a user interface option that I would really like (although perhaps it's already an option and I just don't know how to do it). When I'm tagging images, often I also want to add a comment. But the comment pane and new tag pane are tabbed, so only one at a time shows. I would like to be able to put the user comment pane above the tag pane, so both show at the same time, instead of having to click the Description and Tags tabs to switch back and forth. The only time I get very frustrated with the interface is when I want to do a search that involves "this tag and not that tag". The search (right panel) and filter (left panel) interfaces are both a bit frustrating (I've never really figured out how to use the search interface), and slooowww when trying to invert using the filter (which never works anyway, so I've given up). Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Andrew Goodbody-3
On 6/25/13, Andrew Goodbody <[hidden email]> wrote:
> On 25/06/13 20:00, Veaceslav Munteanu wrote: >> There is a reason why database and image metadata shouldn't be out of >> sync... > > While this may be true in an ideal world unfortunately there are > scenarios that are somewhat reasonable for having them out of sync. > eg I have some photos sent to me by a friend that has some tags applied > to it. I do not want to remove those tags nor do I wish to import them > into my database but I do wish to add my own tags. > That's an excellent example of when and why you'd want the database tags and image tags out of sync. In an ideal world digiKam would be able to handle "always in sync" and and also "not always in sync". Has anyone ever used a photo-management software that had this kind of functionality implemented? If so, how did the user interface work? How were the options phrased? > > A sync operation is going to be very slow on any reasonably large > collection of photos unless you are going to maintain a list of affected > photos. > This is true. That's why I disable writing to the images until I'm done tagging for the session, then go back and enable writing to the images and write them all at once (a slow process). Maintaining a list of modified images sounds like a nice idea - would that of itself slow things down? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Tue, 25 Jun 2013, Elle Stone wrote: > The only time I get very frustrated with the interface is when I want > to do a search that involves "this tag and not that tag". The search > (right panel) and filter (left panel) interfaces are both a bit > frustrating (I've never really figured out how to use the search > interface), and slooowww when trying to invert using the filter (which > never works anyway, so I've given up). Hello, I happen to do the same kind of search and for this I use the color labels as temporary markers. (I don't use them otherwise, so...) 1. Left panel, tags folder, select "that tag" (the unwanted one). 2. Ctrl-A to select all images then, right panel, tags edition, apply a color label, say red. 3. Back to left panel, select "this tag". 4. Right panel, filter folder, select Color label : none, all "that tag" (colored red) disappear and the final is "this tag but not that tag". Of course, this makes sense only if you don't use color labels in a permanent way in your images collections. Probably, for most users, pick labels or color labels are not definitive metadata and can be used as useful temporary tools. Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
On Mon, 24 Jun 2013, Elle Stone wrote: > My point is all these images that were deleted by digiKam were > read-only. I thought that protected the images from accidental > deletion. A lot of people thing the same thing! IT DOESN'T. > This is how Linux file permissions work. A lot of people think the same thing, and also a lot of developers.:-) Unix files access rights aim to protect users data against other users, not against themselves. From the moment you own, a file, a directory, you can do what you wish with it, it's your stuff. A correct file deletion implementation should first check file status (the stat() or lstat() system calls) and if and only if the write permission is set for the current user/owner should effectively delete the file (the unlink() system call). But very few software implementations are written that way and respect files permissions. The only correct software I know, from that point of view, is the GNU Linux 'rm' command. If you try to remove one of your read-only protected file, the program will check and ask you confirmation for removal. (Also with the 'rm -f' option, you specify force removal and ignore file permissions.) > Alas this issue obtains with any image management software, > unless that software has the ability to disable the delete > option. Anyone know of such a software? Not only images management software, the Dolphin files browser does the same. Most applications don't deal with low level system functions and rather use environment libraries. E.g. Digikam, Dolphin, and probably all KDE based applications, don't delete files themselves but use a KDE library function, KIO::del() And, too bad, this function is not correctly implemented, ignores files permissions and issue a brutal system unlink(). (Same behaviour as 'rm -f') The wise philosophy would be to consider that from the moment you use any data management (edition capable) software, your data arrive into risky-land and you should be paranoiac. And your suggestion (ability to disable delete option in a software) is fine but won't protect you against other problems or bugs. (Recently, Volker Henn reported images destructions while doing batch rotations ! ) So, no way but always working with backups under hand, and backups created before starting working. Thus, restoring a previous state of a file will still remain possible. Regards, Jean-François PS: a bit off-topic but there's a rock solid Unix way to protect data, using read-only filesystems. It's kernel based implemented and when a disk device is mounted read-only in your directories tree, it's impossible to write, modify, delete anything, even under the 'root' account. Typical usage is to have images collections on an external USB drive, mounted in the local drive tree, e.g. /usb/albums Initial mount of the USB device : mount -o ro /dev/your-usb-device /usb/albums Remounting in read-write mode, when needed : mount -o remount,rw /usb/albums Remounting in read-only mode after modifications : mount -o remount,ro,noload /usb/albums (The noload option is to be used with journalised filesystems as ext3 or ext4.) Also, one must su to root to run mount commands. This gives an extra security level because it's not possible to remount read-write from a keyboard typo. Read-only mount is really secure; you the user, any application, even root, won't be able to do any change. The major constraint is to prevent fine control onto individual items. With files permissions it's possible to set one or two files in read-only mode. With a read-only filesystem it's all or nothing. Security or flexibility... As for me, this is the way I work. Having lost files in the past made me a bit paranoiac:-) My workflow looks like : 1. Copy new images from SD card to local drive, into a folder. 2. Do another copy from SD card into a folder on a USB drive, temporarily in read-write mode, then switch back to read-only. (Having two copies of the images, the SD card can be wiped for next use.) 3. Work (images edition, metadata, etc.) on the local drive. 4. At some occasions, e.g. after a working session, remount the USB drive read-write and do a sync from local folder, then back to read-only mode. The current state of USB collections is secured read-only. And this allows all kind of tasks that don't need modifications, folders browsing, copying images, doing searches, uploading to web albums, etc., and images are protected from keyboard mistakes or applications issues. The risky state, read-write, occurs only at some rare occasions. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Veaceslav Munteanu-2
Hi Veaceslav, Good to hear that you help bring Digikam forward :) There are a few things I was previously missing with DigiKam -- maybe because of my ignorance but probably for lack in the software: 1. Copy/Paste of Tags. Often I want a photo to have exactly the same tags as another, previously tagged photo. The way I "copy" the tags now is to highlight both and then search my way through the tag tree. That is really inconvenient, especially if the tree is deep. So a plain "copy/paste" would be real helpful. 2. Automatic application of tags to all photos in a group. I group raws and their jpegs together (whereas they really should just be different versions, but that's a different issue). If I then tag (or rate, or color flag, or or or) I always have to pay attention that I apply these changes to all photos in the group. I think that should be the default without me having to care about it. 3. Recently used tags list: When I work in one album, chances are that the tags are similar. Since I have a large tags tree I have to scroll a lot. I guess that could be significantly shortened if I had a list of the, say 10 (configurable, by dragging a window larger/smaller?), recently applied tags. Greetings, Hajo -- Composed on my tablet. Apologies for typos.
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
On 26/06/13 06:33, Elle Stone wrote:
> Assuming I understand what you are saying, although having the option > of expanding all subtags with one click would be a nice touch, some of > my tag trees are deep enough that having everything expand by default > (no option to disable) would then require scrolling down to get to the > desired tag. I use digikam for tagging and my tag list is also quite big and deep. There are times when I am working on particular photos and wish to tag people and other times where I wish to tag plant or animal attributes. Being able to 'filter tags' so you only see those you are working on would be very useful. Also being able to order tags so you can set up a logical hierarchy would also be good. This would definitely improve my workflow. How I see the filtering is having various parent nodes tagged -- yes, a tag on a tag :) -- with a particular category. These categories could then be applied by checking a tick box on the side. So if I am working on tagging plant/flora photos, I check the "plant/flora" category and only those tags relevant to plants are visible. -- Cheers Simon Simon Cropper - Open Content Creator Free and Open Source Software Workflow Guides ------------------------------------------------------------ Introduction http://www.fossworkflowguides.com GIS Packages http://www.fossworkflowguides.com/gis bash / Python http://www.fossworkflowguides.com/scripting _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by hajo
On 26/06/13 09:45, HaJo Schatz wrote:
> Hi Veaceslav, > > Good to hear that you help bring Digikam forward :) > > There are a few things I was previously missing with DigiKam -- maybe > because of my ignorance but probably for lack in the software: > > 1. Copy/Paste of Tags. Often I want a photo to have exactly the same > tags as another, previously tagged photo. The way I "copy" the tags now > is to highlight both and then search my way through the tag tree. That > is really inconvenient, especially if the tree is deep. So a plain > "copy/paste" would be real helpful. Yes I have the same problem. > 2. Automatic application of tags to all photos in a group. I group raws > and their jpegs together (whereas they really should just be different > versions, but that's a different issue). If I then tag (or rate, or > color flag, or or or) I always have to pay attention that I apply these > changes to all photos in the group. I think that should be the default > without me having to care about it. This would be good. I have the original NEF file and derivative JPG/PNG files in a group and always find I forget to tag each with the same tags. I then have to resort to #1 above! > 3. Recently used tags list: When I work in one album, chances are that > the tags are similar. Since I have a large tags tree I have to scroll a > lot. I guess that could be significantly shortened if I had a list of > the, say 10 (configurable, by dragging a window larger/smaller?), > recently applied tags. This fits into my tag on tags or category of tags mentioned previously. One tag would be dynamic, i.e. recently used, most commonly used, ... > > Greetings, > Hajo > -- > Composed on my tablet. Apologies for typos. > > On 25 Jun 2013, at 19:18, "Veaceslav Munteanu" > <[hidden email] <mailto:[hidden email]>> > wrote: > >> Hello, >> >> my name is Veaceslav and I will work on implementing a Tag Manager for >> digiKam as part of Google Summer of Code program. >> >> Here is my proposal: >> >> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/slavuttici/35001 >> >> if you use tags a lot and find an important option that should be >> added, please let me know. >> >> Also, all your suggestions are really appreciated. It will help me to >> build a useful tool. >> >> Don't leave you suggestions until it's too late and lots of things >> must be rewritten. >> >> >> Cheers, >> >> Veaceslav >> <inline.txt> > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Cheers Simon Simon Cropper - Open Content Creator Free and Open Source Software Workflow Guides ------------------------------------------------------------ Introduction http://www.fossworkflowguides.com GIS Packages http://www.fossworkflowguides.com/gis bash / Python http://www.fossworkflowguides.com/scripting _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by hajo
On 26/06/13 00:45, HaJo Schatz wrote:
> 3. Recently used tags list: When I work in one album, chances are that > the tags are similar. Since I have a large tags tree I have to scroll a > lot. I guess that could be significantly shortened if I had a list of > the, say 10 (configurable, by dragging a window larger/smaller?), > recently applied tags. This exists already although not configurable. It is the small button with the green down arrow at the bottom right of the tags pane on the right. Unfortunately due to https://bugs.kde.org/show_bug.cgi?id=309598 it is not actually as useful as it should be. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Simon Cropper-3
On 26/06/13 02:13, Simon Cropper wrote:
> Being able to 'filter tags' so you only see those you are working on > would be very useful. Also being able to order tags so you can set up a > logical hierarchy would also be good. This would definitely improve my > workflow. Are you aware of the search box in the tags pane on the right? If you have your tags in a hierarchy eg all your friends tags as sub-tags under a tag 'friends' then when you want to tag your friends in a photo, type 'friends' into the search box. The 'friends' tag will be selected and all sub-tags will show as well. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Well, I'm a little confused... please look at Tag Manager window mock-up. It's meant for managing tags (add, delete, edit properties, change hierarchy) and to write/sync changes... A lot of request are on image handling and I have no window here to display photos...
Any request that need to select/add photos can't be added here... it's more like options for either context menu, or left sidebar.
On Wed, Jun 26, 2013 at 10:26 AM, Andrew Goodbody <[hidden email]> wrote:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |