[Digikam-devel] Reg Kipi-interface in Digikam

[Vardhman Jain]

Hi Gilles,
I was still waiting for hearing from you regarding the approval of the
current code in the attributes() function, if it looks alright then I can go
ahead and roll out the new functionality in flickrexport kipi-plugin.

What I expect to do in the plugin code is call the attributes() function for
obtaining a map. if the map does have something with "tags" key then those
values will be considered as tags else I would assume no tags from the host
application.
As in the following code.

   //Tags from the database
        QMap <QString, QVariant> attribs=info.attributes();
        QStringList tagsFromDatabase=attribs["tags"].asStringList();

        itTags = tagsFromDatabase.begin();
        while( itTags != tagsFromDatabase.end() ) {
            allTags.append( *itTags );
            ++itTags;
        }


 Let me know if this method has the approval or things need to be different?

regards
Vardhman
On 5/22/06, Colin Guthrie <kde at colin.guthr.ie> wrote:
>
> Vardhman Jain wrote:
> > Sure, not a problem, new developers are like always encouraged and
> > welcome... ;) (I was too :))
>
> :)
>
> > I understand the problem, In fact I had similar things to be added to my
> > plugin too. I was thinking about a functionality to save some history
> > for the images I upload. I mean like adding some extra log thing. The
> > issue is kinda more complex then you might think of it.
> >
> > Digikam is just one of the apps that uses the Gallery plugin. To have ur
> > plugin perform consistently probably the data shud be stored in some
> > other place. I look forward for suggestions from other kde-imaging
> > devels on this one. I guess we should move on the discussion to that
> > list, I am doing a CC anyways.
>
> Well, I've only just read the docs and not really fully absorbed it yet,
> but I'm guessing that the attributes() and addAttribute() methods of the
> KIPI::ImageInfo object allow the plugin to store arbitrary key/value
> pairs about an image (provided the host application supports this -
> hasFeature() call needed first I think). So presumably if Digikam
> supports this then I can store a "do not sync this image" flag to any
> given image.
>
> Now, KIPI::ImageCollection (e.g. Album (sometimes), does not support
> this attributes system, so I would propose to add this to libkipi (and
> digikam) such that I can store a "sync this album to this remote gallery
> in this album" attributes.
>
> Then I would need a way to go through all albums. Oh that's already
> there allAlbums().
>
> In the future it would be nice to be able to traverse all the albums
> heirarchically, but htis is not needed in the first instance.
>
> > Hopefully, we will have some solutions/suggestions from the kipi
> > developers...
>
> I've been speaking via personal email with Angelo Naselli from KDE
> Imaging over the last couple of days and he is keen to get people
> involved with KIPI.
>
> He said: "I started checking on bko (bugzilla) trying to save
> kipi-plugins project. Now something somewhow is moving and people are
> working again on this imo great project, and I'm "coordinating" the
> project concerning release scheduling and something more"
>
> So I think he would be open to extending libkipi should the need arise.
>
> I'll ask him on the kde-imaging mailing list if this is OK to do.
>
> Please let me know if you think I've got the wrong end of the stick... ;)
>
> Col.
> --
>
> +------------------------+
> |     Colin Guthrie      |
> +------------------------+
> | kde(at)colin.guthr.ie  |
> | http://colin.guthr.ie/ |
> +------------------------+
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>



-- 
Blogs: http://vardhman.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20060524/9b161377/attachment.html>