Version: 0.9.0-svn (using KDE 3.4.2, Mandrake Linux Cooker i586 - Cooker) Compiler: Target: i586-mandriva-linux-gnu OS: Linux (i686) release 2.6.12-12mdk This is somehox related with: - bug #95115, which was actually more a recurvise HTML gallery request - bug #117073 as tag or album export should both have the same kind of easy selection interface But the specificity in this request is that a tag/subtag hierarchy should be handled like a regular filesystem hierarchy. The two most important export functions I'd like to have are: - drag & drop as for albums - basically, the same export plugins as albums (digikam should make it transparent to plugins whether is is a real filesystem hierarchy or virtual, tag-based hierarchy, which should be feasible if the interface is a complete list or URLS)...
Created attachment 14704 [details] Small ruby script that does this Here is a small ruby script that does this. It is called like this (from the root album where digikam3.db is): > ruby export_tags_recursive.rb topmost_tag destination_dir It will export tags and subtags, making copies of the files in the destination dir (and subdirs if required). I'm not aware of the integrability of external scripts into digikam, but as I see it this was only a good exercise and should be considered as a prototype for proper Qt/KDE/digikam integration. I'm not too familiar with drag&drop but I believe it amounts to adding a method somewhere to generate a URL list when a drag action is started. If that"s the case, this should be fairly easy to adapt.
It is impossible to hook external scripts into digiKam (yet, I hope) Check bug 88932.
Is there anybody working on this (or planning to do so) ? I am not too familiar with drag&drop in KDE, but from my rough understanding when a drag action is started, some function is triggered to create the relevant drag object (here a list of URLs). If I understand this correctly, we'd need to allow dragging tags, and implement a function with the same algorithm as the ruby script above to generate the right Q/KDragObject containing the URL list, which could then be dropped in konqueror, k3b or elsewhere. I don't see the details of this clearly, but I think it would be nice...
Vardhman, I add you like CC of this bug since this file is relevant of your current digikam kipi-plugins interface implementation about to export virtual folders to plugins like physical folders. Please post some comments in this thread about the status of your current implementation Thanks in advance Gilles
On 25 Jul 2006 11:26:44 -0000, Gilles Caulier <caulier.gilles@free.fr> wrote: [bugs.kde.org quoted mail] Hi, I haven't even started working on that particular aspect. I am sorry to say I will not be able to do much till August end. So if someone plans to start hacking in to it, be most welcome. regards, Vardhman _______________________________________________ > Digikam-devel mailing list > Digikam-devel@kde.org > https://mail.kde.org/mailman/listinfo/digikam-devel > On 25 Jul 2006 11:26:44 -0000, <b class="gmail_sendername">Gilles Caulier</b> <<a href="mailto:caulier.gilles@free.fr">caulier.gilles@free.fr</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ------- You are receiving this mail because: -------<br>You are the assignee for the bug, or are watching the assignee.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=120945">http://bugs.kde.org/show_bug.cgi?id=120945 </a><br>caulier.gilles free fr changed:<br><br> What |Removed |Added<br>----------------------------------------------------------------------------<br> CC| |vardhman gmail com <br><br><br><br>------- Additional Comments From caulier.gilles free fr 2006-07-25 13:26 -------<br>Vardhman,<br><br>I add you like CC of this bug since this file is relevant of your current digikam kipi-plugins interface implementation about to export virtual folders to plugins like physical folders. <br><br>Please post some comments in this thread about the status of your current implementation<br>Thanks in advance</blockquote><div><br> Hi,<br> I haven't even started working on that particular aspect. I am sorry to say I will not be able to do much till August end. So if someone plans to start hacking in to it, be most welcome. <br></div><br><div>regards,<br>Vardhman <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">_______________________________________________ <br>Digikam-devel mailing list<br><a href="mailto:Digikam-devel@kde.org">Digikam-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/digikam-devel">https://mail.kde.org/mailman/listinfo/digikam-devel</a><br> </blockquote></div><br><br clear="all"><br>-- <br>Blogs: <a href="http://vardhman.blogspot.com">http://vardhman.blogspot.com</a><br>
I would also appreciate this feature. Additionally the same feature for the "virtual albums" as the pictures selected by date.
It seems that this still hasn't been implemented, or at least I could not find it on my current version (1.9.0). Worse, the schema of the db has been changed since the original report (back in 2006 !) and I fear the ruby script would no longer work - though I admit I haven't tested it. I still believe this would be a very interesting and fairly easy feature to add (at least the export part, drag&drop is not as badly needed). Is there any chance that it comes in the not too distant future? One of my ideas with it is to use it to export a virtual hierarchy to a local gallery, and then update a distant (ftp gallery) but only modified files to save bandwidth. Is there possibly another way of doing this? Thanks!
Created attachment 61472 [details] export_tags_recursive.rb (In reply to comment #7) > It seems that this still hasn't been implemented, or at least I could not find > it on my current version (1.9.0). Worse, the schema of the db has been changed > since the original report (back in 2006 !) and I fear the ruby script would no > longer work - though I admit I haven't tested it. It did not work, I don't speak ruby, but changed it to the current scheme > > I still believe this would be a very interesting and fairly easy feature to add > (at least the export part, drag&drop is not as badly needed). Is there any > chance that it comes in the not too distant future? > One of my ideas with it is to use it to export a virtual hierarchy to a local > gallery, and then update a distant (ftp gallery) but only modified files to > save bandwidth. Is there possibly another way of doing this? > > Thanks! Well, it's more work than what you think ;) at the moment we are in -rc and new features should not be added
Nicolas, This file still valid using digiKam 2.4 ? Gilles Caulier
*** Bug 320663 has been marked as a duplicate of this bug. ***
WARNING : with digiKam 6.0.0 and later, we will not support kipi interface anymore. All tools are now located in digiKam core as well for a plan to provide a more power-full integration with Batch Queue Manager and to be able to export a workflow on a web-service. All export tools are now available everywhere : album view, Image editor, Light table, and Showfoto. Previously, only album view from digiKam core was able to deal with export tools through libkipi. All export tools are now located here : https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/webservices All export tools use now a dedicated interface to communicate with the application : - digiKam (database) : https://cgit.kde.org/digikam.git/tree/core/libs/database/utils/ifaces/dbinfoiface.h - Showfoto (files metadata) : https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/common/dmetainfoiface.h There is not direct use of digiKam database for compatibility with Showfoto. We plan later to provide a dynamic loading of export tools using a plugins mechanism. This will reduce overloading of the internal core libraries. A dedicated devel branch have been created for that, but it's not yet complete: https://cgit.kde.org/digikam.git/tree/?h=development/dplugins But take a care, digiKam export tools as plugins will not be shared with another external application. API will still private and only shared between Showfoto and digiKam core. The experience with libkipi was bad and complex to maintain/extend in time. Gilles Caulier