Version: (using KDE 4.2.95) Installed from: Ubuntu Packages It would be cool if the facebook im/export plugin would be turned into a virtual folder which can be used in dolphin and filedialogues.
What do you mean by Virtual ? "which can be used in dolphin and filedialogues" ??? Please take screenshots... Gilles Caulier
I mean something like the networkressources (ftp, I can use in dolphin or the audiocd browsing with mp3 folders which do not really exist on the cd, but are there and can be used to copy and rip at the sametime. it would be something like facebookalbums:// I would then see folders for my friends names, go through their albums and copy them as there were part of the file system. I the case of my own profile I could then also drag and drop folders/ pictures into it.
This is something I've been planning (but not actually doing) for a loooooong time now. The idea is to integrate all the web-based systems into akonadi and then expose that. akonadi will maintain a cache and allow things to work quickly and efficiently, even when off line. The structure of akonadi is pretty much ideal for handling this and then exposing the data via a kresource style system should be easy, which obviously remaining very simple to use in digikam and other KDE apps too. I've only got very simple prototypes going and have found it hard to find time to make any progress here :(
Pieter, Johannes, Michael, This is another subject to patch libkipi to be able to display remote folder-tree in kipi hosts application. We will talking about in Coding Sprint planed at november Gilles Caulier
I think the best thing would be if it would be included into remote:/ which also has this remote resource configuration assistant.
I firmly believe that this is *not* something that should go into libkipi. There already exists a perfect API with cache-backed storage for dealing with "collections" of data. This is Akonadi. The process to do this is relatively simple and I am happy to discuss the approach with people as to how to achieve the end result, I'm just struggling with time to do the implementation due to commitments on other projects. I think designing this specifically into libkipi would be a big mistake.
I'm agree with you that folder cache mechanism must be done outside libkipi, but... kipi host is relvant of libkipi to play with plugins. So plugins must provide - a base widget to display remote folder content. folder tree view is filled by plugin using a dedicated library, based on Akonady, or something like that. Note that Model/view of folder content must be delegate to kipi host, as it currently done with libkipi::imagecollectionselector.cpp. Like this folder tree view will respect style of kipi host application. - a base widget to display plugin settings. settings content is filled by plugin as well. Typically, the mockup idea for digiKam is : - To not show plugin dialog. - On the right sidebar, to display plugin settings widget in a dedicated tab. - On the left sidebar, to display remote folder tree view in a dedicated tab. Gilles Caulier
Created attachment 37296 [details] new facebook tool mockup integrated in kipi host application
This looks cool! But I think if we do it like this for facebook, we should do it for all export tools. That's one thing I already noticed while browsing through the code of the export / import plugins: there is a high potential for some generalization in the gui work that's currently not used and that is - to my mind - something that's very important for users. Because having the same feeling for all export tools makes using them much easier. My suggestion would be to create a base class (eg. AbstractExportTool) for all export dialogs that creates the basic GUI with the image list (or whatever solution is preferred) and all properties that can generalized over all export services (eg. resizing before uploading). For all capabilities that are unique to some services I would suggest a kind of strategy pattern. Every subclass for a special service like flickr implements a template method that returns a list of capabilites. These capabilities consist of two parts: 1. a QWidget that is filled into the gui by the AbstractExportTool class and 2. a handler class. This handler processes the options provided by the QWidget. With this structure the Capability classes can still be used by different services without the need to reimplement them (at least the gui, eg. most of the services provide a way to create albums. The gui can be reused for a convieniet user experience while the handler code maybe needs to be reimplemented).
>But I think if we do it like this for facebook, we should do it for all export >tools. Of course !!! Facebook is just an example. This is why libkip must provide API to export plugins folder view and plugins settings. >Because having the same feeling for all export >tools makes using them much easier Yes. Factorize code is very important, but can take a while. At least, for the moment, export plugins are separated and are improved one by one. A factorization can be done later, when all plugins implementation will become mature. For the rest of your proposal, i'm agree, in general.
If I understand Gilles comment correct Johannes, then most of what you suggest is already handled by the abstraction layer in Akonadi. I believe Gilles is suggesting a generic client to the Akonadi being added to libkipi such that host applications can implement this external linkage very easily and that makes a lot of sense. In Akonadi you'd write the relevant code to setup and configure each individual external link and it would then expose a standard API for querying and updating the external stuff. As far as the implementation in Kipi is concerned, all it deals with is generic code for searching and listing the objects. Essentially libkipi (or something - doesn't matter where) will provide a class that represents an "image" complete with tags and extra attributes etc. This will be common class that is specifically serialised to/from the Akonadi system. Once this common class is written, it is simply a matter of writing an akonadi resource for each external system. Once all this is in place, it would be trivial to write a standard widget to be included in libkipi and also to expose it in other areas of KDE (e.g. for screen savers or virtualised kio style browsing). I'm a bit out of date with my terminology, but please do read up on Akonadi if you are interested in helping out here. I'd be happy to arrange a time for an interactive chat on IRC so that I can explain things better and hopefully find people to take the idea forward!
Luka, I CC you to this entry. Johanness, accordingly with Luka who is interested by this job, I would to suggest you to write a paper in kipi-plugins/project with all technicals information relevant of this code factoring. At least to be clear. For libkipi stuff, i'm interrested to improve library to share plugin widgets with kipi host. Andrea has already started to work on this part at previous coding sprint. Code is there : http://websvn.kde.org/branches/work/~cgilles/kipitoolsiface/libkipi/ I need to review code to be integrated to trunk Gilles
>I believe Gilles is suggesting a generic client to the Akonadi being added to >libkipi such that host applications can implement this external linkage very >easily and that makes a lot of sense. No, kipi hosts application don't need that. Only plugins... the right place is libkipiplugins... Gilles
@Colin Ok, I'm not into what akonadi can do, but that sounds cool. But can it also handle special attributes like privacies and what happens if for some strange reason one of the services doesn't provide the ability to create albums and so on? @Gilles Ok I can write a bit, but I would need further information to fully understand what's going on in which library and service. Can I contact Luka somewhere on IRC or something like that? And where can I find some Information on Akonadi?
(In reply to comment #14) > @Colin > Ok, I'm not into what akonadi can do, but that sounds cool. But can it also > handle special attributes like privacies and what happens if for some strange > reason one of the services doesn't provide the ability to create albums and so > on? Yeah, it deals with generic collections (and sub-collections there of) in a pretty flexible way. It supports permissions (rights) that control the ability to create sub-collections, adding items to the collections etc., so this information is exposed to us. For a generic framework, it really maps very cleanly to what remote media sites offer. For reference: Overview here: http://pim.kde.org/akonadi/ (it's the underpinning of the general KDE PIM structures so will be responsible for holding e.g. Mail messages, Calendars etc. but it's generic nature allows us to map the storage to anything that has a vaguely tree-based approach. Eventually (very distant future) it may even provide the necessary storage for digikam's own database... but let's not think too hard about that for now). It also has good integration to Nepomuk so semantic information from facebook at your fingertips will be possible too :) General API Docs are here: http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/index.html Collection specific stuff is here: http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Collection.html and as you can see one of the members is the rights() stuff which controls what you can and cannot do with the collection which is: CanChangeItem, CanCreateItem, CanDeleteItem, CanChangeCollection, CanCreateCollection, CanDeleteCollection, CanLinkItem, CanUnlinkItem. @Gilles sorry for the confusion earlier. I'm out of touch with things :s I think I *meant* the right, thing even if I was putting it in the wrong place :D
(In reply to comment #15) > (In reply to comment #14) > > @Colin > > Ok, I'm not into what akonadi can do, but that sounds cool. But can it also > > handle special attributes like privacies and what happens if for some strange > > reason one of the services doesn't provide the ability to create albums and so > > on? > > Collection specific stuff is here: > http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Collection.html > > and as you can see one of the members is the rights() stuff which controls what > you can and cannot do with the collection which is: CanChangeItem, > CanCreateItem, CanDeleteItem, CanChangeCollection, CanCreateCollection, > CanDeleteCollection, CanLinkItem, CanUnlinkItem. Ok, that's one thing, but I was thinking of thinks like "visible only for friend" as e.g. flickr provides. How can that be achieved?
@Johannes, Luka is in copy to this file (lure at kubuntu dot org). He will come to coding sprint too. @Colin : no problem for confusion (:=)))... Just fun... Gilles
SVN commit 1030124 by cgilles: add OO.org doc to list lead tasks to do for 1.0.0 CCBUGS: 199848 AM MainTask1.0.0.ods WebSVN link: http://websvn.kde.org/?view=rev&revision=1030124
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