| Summary: | FACTORING : allow to synchronize local albums with remote web service albums and vis-versa | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Roman Prots' <rprots> |
| Component: | Plugin-Generic-WishForNewTools | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | caulier.gilles, colin, jaervosz, julien.t43+kde, Julien, kusi, l.mierzwa, philippe.roubach, shouryasgupta, tiago.schumann |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Roman Prots'
2011-05-04 15:35:31 UTC
background service with tray icon for progress reporting would be nice, so that one would not need to keep digikam open to sync albums An increased level of synchronization would be nice * at best, kind of automatic sync dropbox-like * a manual simple sync would already be a great step * allow easy update of meta from local to online service (update of title, description, copyright, ...) * recover online informations (like, comments, ...) in local meta for offline use/backup (may be a IMPTC-X-Comment?) * an optional tag (internal/invisible/...) which references if photo was exported and where (case with multiple album export on different or same service) and a way to add it manually for past albums. Any news on the re-architecture of export functions ? (Picasa, flickr, facebook, ...) Related feature requests: Bug 297290 - Adding Export metadata to pictures corresponding to target service Bug 278347 - when exporting with kipi-plugins, if you have duplicates, you can't ignore/ignore all Bug 215795 - picasaweb ability to synchronize a picasaweb album Bug 181863 - Allow to reupload pictures to Flickr Bug 272451 - Synchronization with online albums (PicasaWeb, Flickr) and crash: Bug 306165 - Crash while starting photo upload to picasa (because of duplicates) *** This bug has been confirmed by popular vote. *** *** Bug 143978 has been marked as a duplicate of this bug. *** *** Bug 215795 has been marked as a duplicate of this bug. *** *** Bug 181863 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 one-way sync of your local database to Smugmug: https://github.com/githubkusi/digikam2smugmug (this is a workaround rather than a solution) *** Bug 306357 has been marked as a duplicate of this bug. *** |