Bug 179840

Summary: External access to digiKam searches
Product: [Applications] digikam Reporter: Ian Hubbertz <kde_bugs>
Component: Plugin-Generic-WishForNewToolsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: caulier.gilles, marcel.wiesweg
Priority: NOR    
Version: 0.10.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Ian Hubbertz 2009-01-06 21:15:30 UTC
Version:           0.10.0-beta7 (using Devel)
Installed from:    Compiled sources

It would be nice to have external access to digikam virtual search folders.

I came to the idea when thinking about a "digikamFS" virtual filesystem implemented with FUSE.

This can be very useful for various purposes:

* public network share (SMB) for selected fotos
* easy export to external devices
* external slideshow applications can use this as folder (e.g. KDE's workplace background or picture frame widget).

It may be possible to implement this by using the digikamsearch: kio-slave, but therefore digikam must run.

So, more a library will be more useful. Database access is already quite easy, but the search is stored as xml-file, so it cannot be easily parsed.

So, a library function is needed that takes a string containing the name of a stored search and that returns a list of files including full path matching the search is needed.

Additional functions may return the list of stored searches or offer to run a newly entered query.

With that, it is easy to write digikamFS with FUSE. Fuse bindings are available for various languages.

Later versions of digikamFS then may implement other features like on the fly resizing or converting to other image formats.
Comment 1 Marcel Wiesweg 2009-01-06 22:10:01 UTC
The easiest solution for this would be to implement the listDir method in the digikamsearch ioslave. Currently the listing uses a custom format, but standard listDir would be possible as well.

As to the library you are talking about: Look at the digikamsearch ioslave, it is only a bit of glue code. There are the libraries libdigikamcore.so and libdigikamdatabase where all necessary code is contained. But: this is not public API, which means that API and BC will change with every digikam version.
So the option above is to be preferred.
Comment 2 Ian Hubbertz 2009-01-08 00:44:10 UTC
I started to write some digikam python bindings with boost.python, which should be quite easy.

However, digikamcore.so links to a lot of other libs (e.g libmarblewidget.so), so 
this will be a quite heavy python library.
Comment 3 Arnd Baecker 2009-01-08 07:57:12 UTC
What do you mean by "heavy python library"?
(Large resulting file/slow to load/difficult to use/many functions ... ? ;-)

Just as a remark: marble itself also has python bindings
(though I haven't tested them myself, and they need to be activated 
during cmake).

Moreover, let me also mention https://bugs.kde.org/show_bug.cgi?id=146866
which is about KROSS support for digikam (which would also provide,
among others, a python interface; more details are in that link).

Personally I think that providing a python interface to digikam
could/should have a substantial impact in that it would allow
users which are not familiar with coding C++ to provide additional tools/scripts/.... 
Comment 4 Marcel Wiesweg 2009-01-08 19:24:48 UTC
I want to stress the issue of libdigikamcore and libdigikamdatabase once more: We created these libraries to efficiently share code among the various components of digikam. It's just the main part of digikam
s code. Disclaimer: this is not a public interface, there is and will be no stable API, interfaces will change between every single minor release.

The Kross interface is pretty interesting. I did not read about the Kross API yet and have only a vague idea, but a scripting API can allow powerful addons.
Comment 5 Arnd Baecker 2009-01-20 19:26:22 UTC
It seems that there is an implementation in C#, using Mono.Fuse
http://mail.kde.org/pipermail/digikam-users/2006-September/002027.html
Not sure if this still works with 0.10 ....
Comment 6 caulier.gilles 2016-11-26 09:55:11 UTC
As Marcel Said in comment #4, the solution to this issue is to add a scriptting interface to digiKam. We have already a file about this topic with bug #146866

Gilles Caulier

*** This bug has been marked as a duplicate of bug 146866 ***