extragear/graphics/digikam/utilities

[Marcel Wiesweg]

SVN commit 986000 by mwiesweg:

Nepomuk coding sprint results:
Initial revision of a Digikam <-> Nepomuk synchronisation bridge.
For now this is implemented as a Nepomuk service running independently
from the main digikam instance.
Syncs rating, comment and tags; tags is one-way currently, syncing tags
from Nepomuk to digikam is awaiting implementation.
Changes in digikam are immediately pushed to Nepomuk by listening to
digikam's DBus signals. After first start, a full sync of all entries
is triggered. The initial sync is recorded in the database.
Changes in Nepomuk are registered by listening to global change signals.
After a timed delay a Sparql query retrieves all relevant changes
that occurred since the last check. The time is recorded in the database.
The database file path is read from the digikam configuration file.
If an instance is running, it is queried directly. If the database file
changes, the service is informed by digikam. (This does not scale well to
several
instances running different DBs, but digikam does not support this scenario
anyway)
Both syncing directions are independently configurable. Default is false for
now;
we should consider defaulting to true.

Note: I am running KDE4.3beta2 at the moment. If there is code not compiling
with
KDE4.2, we must add a conditional switch to CMake.

CCMAIL: [hidden email], [hidden email]

 A             nepomuk (directory)  
 A             nepomuk/digikamnepomukservice.cpp   [License: GPL (v2+)]
 A             nepomuk/digikamnepomukservice.desktop  
 A             nepomuk/digikamnepomukservice.h   [License: GPL (v2+)]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

I can't compile / link (KDE 4.2.4):

Scanning dependencies of target kio_digikamtags
Scanning dependencies of target kio_digikamsearch
[ 71%] Building CXX object
digikam/kioslave/CMakeFiles/kio_digikamtags.dir/digikamtags.o
[ 71%] Building CXX object
digikam/kioslave/CMakeFiles/kio_digikamsearch.dir/digikamsearch.o
[100%] Built target digikam
/home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepomuk/digikamnepomukservice.cpp:
In member function ‘void Digikam::NepomukService::syncTagsToNepomuk(const
QList<long long int>&, const QList<int>&, bool)’:
/home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepomuk/digikamnepomukservice.cpp:533:
error: no matching function for call to
‘Nepomuk::Resource::removeProperty(QUrl, Nepomuk::Tag&)’
/usr/include/KDE/Nepomuk/../../nepomuk/resource.h:311: note: candidates are:
void Nepomuk::Resource::removeProperty(const QUrl&)
/usr/include/KDE/Nepomuk/../../nepomuk/resource.h:316: note:                
void Nepomuk::Resource::removeProperty(const QString&)
/home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepomuk/digikamnepomukservice.cpp:
At global scope:
/home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepomuk/digikamnepomukservice.cpp:772:
warning: unused parameter ‘tags’
make[2]: ***
[digikam/digikam/CMakeFiles/digikamnepomukservice.dir/__/utilities/nepomuk/digikamnepomukservice.o]
Error 1
make[1]: *** [digikam/digikam/CMakeFiles/digikamnepomukservice.dir/all] Error
2
make[1]: *** Waiting for unfinished jobs....
Linking CXX shared module ../../lib/kio_digikamtags.so
[100%] Built target kio_digikamtags
Linking CXX shared module ../../lib/kio_digikamsearch.so
[100%] Built target kio_digikamsearch
make: *** [all] Error 2

Andi

On Tuesday 23 June 2009 23:24:57 Marcel Wiesweg wrote:

> SVN commit 986000 by mwiesweg:
>
> Nepomuk coding sprint results:
> Initial revision of a Digikam <-> Nepomuk synchronisation bridge.
> For now this is implemented as a Nepomuk service running independently
> from the main digikam instance.
> Syncs rating, comment and tags; tags is one-way currently, syncing tags
> from Nepomuk to digikam is awaiting implementation.
> Changes in digikam are immediately pushed to Nepomuk by listening to
> digikam's DBus signals. After first start, a full sync of all entries
> is triggered. The initial sync is recorded in the database.
> Changes in Nepomuk are registered by listening to global change signals.
> After a timed delay a Sparql query retrieves all relevant changes
> that occurred since the last check. The time is recorded in the database.
> The database file path is read from the digikam configuration file.
> If an instance is running, it is queried directly. If the database file
> changes, the service is informed by digikam. (This does not scale well to
> several
> instances running different DBs, but digikam does not support this scenario
> anyway)
> Both syncing directions are independently configurable. Default is false
> for now;
> we should consider defaulting to true.
>
> Note: I am running KDE4.3beta2 at the moment. If there is code not
> compiling with
> KDE4.2, we must add a conditional switch to CMake.
>
> CCMAIL: [hidden email], [hidden email]
>
>  A             nepomuk (directory)
>  A             nepomuk/digikamnepomukservice.cpp   [License: GPL (v2+)]
>  A             nepomuk/digikamnepomukservice.desktop
>  A             nepomuk/digikamnepomukservice.h   [License: GPL (v2+)]
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sebastian Trueg]

very cool. Below a comment which could avoid some code duplication:

On Tuesday 23 June 2009 23:24:57 Marcel Wiesweg wrote:

> Nepomuk coding sprint results:
> Initial revision of a Digikam <-> Nepomuk synchronisation bridge.
> For now this is implemented as a Nepomuk service running independently
> from the main digikam instance.
> Syncs rating, comment and tags; tags is one-way currently, syncing tags
> from Nepomuk to digikam is awaiting implementation.
> Changes in digikam are immediately pushed to Nepomuk by listening to
> digikam's DBus signals. After first start, a full sync of all entries
> is triggered. The initial sync is recorded in the database.
> Changes in Nepomuk are registered by listening to global change signals.
> After a timed delay a Sparql query retrieves all relevant changes

You can use Soprano::Utils::SignalCacheModel to get cached signals using a
configurable timeout.

> that occurred since the last check. The time is recorded in the database.
> The database file path is read from the digikam configuration file.
> If an instance is running, it is queried directly. If the database file
> changes, the service is informed by digikam. (This does not scale well to
> several
> instances running different DBs, but digikam does not support this scenario
> anyway)
> Both syncing directions are independently configurable. Default is false
> for now;
> we should consider defaulting to true.
>
> Note: I am running KDE4.3beta2 at the moment. If there is code not
> compiling with
> KDE4.2, we must add a conditional switch to CMake.
>
> CCMAIL: [hidden email], [hidden email]
>
>  A             nepomuk (directory)
>  A             nepomuk/digikamnepomukservice.cpp   [License: GPL (v2+)]
>  A             nepomuk/digikamnepomukservice.desktop
>  A             nepomuk/digikamnepomukservice.h   [License: GPL (v2+)]

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> /home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepomuk
>/digikamnepomukservice.cpp:533: error: no matching function for call to
> ‘Nepomuk::Resource::removeProperty(QUrl, Nepomuk::Tag&)’

Indeed, this method is 4.3 only.
Anyway, Nepomuk doesn't even really take off with 4.3, not to talk of 4.2. I
have added CMake statements to compile the nepomuk service only with >=4.3
versions (hope I got the right CMake call)

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Tuesday 23 June 2009 23:24:57 Marcel Wiesweg wrote:
> SVN commit 986000 by mwiesweg:
>
> The database file path is read from the digikam configuration file.
> If an instance is running, it is queried directly. If the database file
> changes, the service is informed by digikam. (This does not scale well to
> several
> instances running different DBs, but digikam does not support this scenario
> anyway)

Despite your comment I wonder if this could not be used in future for several
instances of digiKam working together over network, even sharing thumbnails
db?

m.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > The database file path is read from the digikam configuration file.
> > If an instance is running, it is queried directly. If the database file
> > changes, the service is informed by digikam. (This does not scale well to
> > several
> > instances running different DBs, but digikam does not support this
> > scenario anyway)
>
> Despite your comment I wonder if this could not be used in future for
> several instances of digiKam working together over network, even sharing
> thumbnails db?

You can open as many instances of digikam as you like. (see how changes are
distributed across open instances as well). But if you currently change the db
path in the config dialog it will write it to the config file, and the nepomuk
service will read from this config file.
There is no principal problem as well with having two instances of digikam
accessing different DBs.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Yes, now it is compiling and linking.
Thanks!

Andi

On Wednesday 24 June 2009 10:57:12 Marcel Wiesweg wrote:

> > /home/andi/Programmieren/KDE/digiKam/digikam_KDE4/digikam/utilities/nepom
> >uk /digikamnepomukservice.cpp:533: error: no matching function for call to
> > ‘Nepomuk::Resource::removeProperty(QUrl, Nepomuk::Tag&)’
>
> Indeed, this method is 4.3 only.
> Anyway, Nepomuk doesn't even really take off with 4.3, not to talk of 4.2.
> I have added CMake statements to compile the nepomuk service only with
> >=4.3 versions (hope I got the right CMake call)
>
> Marcel
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel