Bug 109631 - make digikamtags protocol public KIO-slave
Summary: make digikamtags protocol public KIO-slave
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Albums (show other bugs)
Version: 0.8.1
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-26 10:12 UTC by Mikolaj Machowski
Modified: 2017-07-25 10:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikolaj Machowski 2005-07-26 10:12:43 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

Please make digikamtags protocol publicly availabla as KIO-slave to make easy access to photos from all apps which are supporting KIO-slaves (especially through FileChooser).
Comment 1 Jens 2005-07-27 20:52:38 UTC
This would only make sense if the pics are *not* otherwise (easily) visible, ie. if the database folder was hidden. Otherwise you'd provoke lots of bug reports about "I deleted a photo in digikam, because i still had a copy in my ~/Pictures directory, but now that's gone too!"

Been there, done that. Never allow novices two different views on the same file system object. :-)
Comment 2 Mikolaj Machowski 2005-07-27 23:52:09 UTC
> This would only make sense if the pics are
> *not* otherwise (easily) visible, ie. if the database folder was hidden.


And they are not easily visible. To add image in another application
(eg. KPresenter) I have to start separately digiKam.

Also Album organisation isn't the same as Tag organisation.

> Otherwise you'd provoke lots of bug reports about "I deleted a photo in
> digikam, because i still had a copy in my ~/Pictures directory, but now
> that's gone too!"


digikamtags:/ protocol was available for some time and never heard those
complaints. Eventually it could be RO access.
Comment 3 Tom Albers 2005-07-28 00:00:49 UTC
Quoting renchis earlier respons to this request:

"i hope you are aware of how kioslave's internals, otherwise the rest of 
this email is pure gibberish. to list files from a kioslave, you need to 
implement slavebase::listDir(). Since moving to the db based listing, the 
information sent to the frontend includes: the id of the image, id of the 
album, name, date, size and maybe dimensions. since this is customized to 
the needs of digikam, its possible to list files  fast without 
transport of extra information. instead of using slavebase::listdir(), 
slavebase::special() is used for doing the listing. now for the kioslave 
to work with a generic kde frontend one needs to completely implement 
slavebase::listdir() and send the info the frontend expects. And this part 
is not implemented for digikamtags, digikamsearch and digikamdates 
kioslave. now, the only reason to implement it would be to make it work
with other kde frontends and it doesn't give any additional benefit to 
digikam at all."
Comment 4 caulier.gilles 2008-03-18 12:39:56 UTC
Marcel,

A solution for this problem is to implement a nepomuk interface in KDE4. right ?

Gilles Caulier
Comment 5 Marcel Wiesweg 2008-03-18 17:59:07 UTC
Yes yes we need somehow to expose our data to Nepomuk sooner or later, to integrate better with KDE as a whole...
Comment 6 Arnd Baecker 2008-03-18 22:05:21 UTC
*** Bug 145228 has been marked as a duplicate of this bug. ***
Comment 7 Arnd Baecker 2008-03-18 22:06:06 UTC
Note that bug 145228 still contains some comments worth reading when tackling
this wish ...
Comment 8 caulier.gilles 2015-09-25 15:58:40 UTC
With next digiKam 5.0.0, all dedicated KIO-Slave are now dropped for a better portability and to be maintainable easily.

Now digiKam use a multi-core and multi-thread interface to query the database.

Gilles Caulier