| Summary: | make digikamtags protocol public KIO-slave | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Mikolaj Machowski <mikmach> |
| Component: | Database-Albums | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | caulier.gilles, jkyro, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | 0.8.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 5.0.0 | |
| Sentry Crash Report: | |||
|
Description
Mikolaj Machowski
2005-07-26 10:12:43 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. :-) > 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. 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." Marcel, A solution for this problem is to implement a nepomuk interface in KDE4. right ? Gilles Caulier Yes yes we need somehow to expose our data to Nepomuk sooner or later, to integrate better with KDE as a whole... *** Bug 145228 has been marked as a duplicate of this bug. *** Note that bug 145228 still contains some comments worth reading when tackling this wish ... 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 |