[Digikam-devel] Reg Kipi-interface in Digikam

Hi,
       I am trying to hack in to the kipiinterface.cpp/.h files for adding some functionality to the attributes/setAttributes etc functions. I have some doubts whose clarfification will help me a great deal.

The function Albumdb->getItemTagNames( ImageId id)   takes an image id as an argument, while almost all other functions mostly use a combination of Album id and photo Url.
There are some functions which work on ImageId but they are not at all used in implementation.

As far as I can see there is no easy way to obtain an ImageId given a DigikamImageInfo object. Therefore I would like to ask if it would be okay to add another method in albumDb interface to allow seeking the tag info by combination of AlbumId and imageURL or a function should be added to return the imageId of a image given its AlbumId and imageURL in the albumDB file again ?

Thanks in anticipation!
Regards,
Vardhman
--
Blogs: http://vardhman.blogspot.com

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

[Gilles Caulier-2]

Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit :

> Hi,
>        I am trying to hack in to the kipiinterface.cpp/.h files for adding
> some functionality to the attributes/setAttributes etc functions. I have
> some doubts whose clarfification will help me a great deal.
>
> The function Albumdb->getItemTagNames( ImageId id)   takes an image id as
> an argument, while almost all other functions mostly use a combination of
> Album id and photo Url.
> There are some functions which work on ImageId but they are not at all used
> in implementation.
>
> As far as I can see there is no easy way to obtain an ImageId given a
> DigikamImageInfo object. Therefore I would like to ask if it would be okay
> to add another method in albumDb interface to allow seeking the tag info by
> combination of AlbumId and imageURL or a function should be added to return
> the imageId of a image given its AlbumId and imageURL in the albumDB file
> again ?
>
> Thanks in anticipation!
> Regards,
> Vardhman
> --
> Blogs: http://vardhman.blogspot.com

Vardhman,

I'm currently finalize Minolta makenote support in Exiv2 project.

http://dev.robotbattle.com/~cvsuser/cgi-bin/ns_viewcvs.cgi/exiv2/trunk/src/minoltamn.cpp

I will take a look about your questions tomorrow (:=)))...

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

[Gilles Caulier-2]

Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit :
> Hi,
>        I am trying to hack in to the kipiinterface.cpp/.h files for adding
> some functionality to the attributes/setAttributes etc functions. I have
> some doubts whose clarfification will help me a great deal.
>

You want said these methods :

QMap<QString,QVariant> DigikamImageInfo::attributes()
void DigikamImageInfo::clearAttributes()
void DigikamImageInfo::addAttributes( const QMap<QString,QVariant>& )

right ?

> The function Albumdb->getItemTagNames( ImageId id)   takes an image id as
> an argument, while almost all other functions mostly use a combination of
> Album id and photo Url.
> There are some functions which work on ImageId but they are not at all used
> in implementation.
>
> As far as I can see there is no easy way to obtain an ImageId given a
> DigikamImageInfo object. Therefore I would like to ask if it would be okay
> to add another method in albumDb interface to allow seeking the tag info by
> combination of AlbumId and imageURL or a function should be added to return
> the imageId of a image given its AlbumId and imageURL in the albumDB file
> again ?

Yes, you can do it. Just overload the current methods and don't touch the
current implementation. Like this you don't unbreak the tests released on
this methods for 0.9.0 release.

Please, add comments in method headers, like others current methods using
Doxygen syntax.

When you commit, please CCMAIL on [hidden email]. Thanks in advance...

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

Hi,
       There is something extra which I guess needs to be discussed. Most of the methods in KipiInterface just use albumDB interface to fetch/set some data about the photo in the database. This construction doesn't basically allow some temporary data storage which might be required for the session purposes only, let me explain.

If the user says he wants to upload the photos to flickr and wants to add some extra tags to the photos when they are uploaded to flickr and doesn't want to effect his original tags in digikam database. We cannot use AlbumDB object here to store the temporary information.

The solution in my opinion is to allow a DigikamImageInfo::QMap<QString,QVariant> attributes; member in the DigikamImageInfo to allow saving of data temporarily in the object using addAttributes() by the host application, while using attributes() from the plugin code to obtain the data ?

Please let me know ur viewpoints...

Vardhman

On 5/8/06, Caulier Gilles <[hidden email]> wrote:

Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit:
> Hi,
>        I am trying to hack in to the kipiinterface.cpp/.h files for adding
> some functionality to the attributes/setAttributes etc functions. I have
> some doubts whose clarfification will help me a great deal.
>

You want said these methods :

QMap<QString,QVariant> DigikamImageInfo::attributes()
void DigikamImageInfo::clearAttributes()
void DigikamImageInfo::addAttributes( const QMap<QString,QVariant>& )

right ?

> The function Albumdb->getItemTagNames( ImageId id)   takes an image id as
> an argument, while almost all other functions mostly use a combination of
> Album id and photo Url.
> There are some functions which work on ImageId but they are not at all used
> in implementation.
>
> As far as I can see there is no easy way to obtain an ImageId given a
> DigikamImageInfo object. Therefore I would like to ask if it would be okay
> to add another method in albumDb interface to allow seeking the tag info by
> combination of AlbumId and imageURL or a function should be added to return
> the imageId of a image given its AlbumId and imageURL in the albumDB file
> again ?

Yes, you can do it. Just overload the current methods and don't touch the
current implementation. Like this you don't unbreak the tests released on
this methods for 0.9.0 release.

Please, add comments in method headers, like others current methods using
Doxygen syntax.

When you commit, please CCMAIL on [hidden email]. Thanks in advance...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
<a href="https://mail.kde.org/mailman/listinfo/digikam-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: <a href="http://vardhman.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://vardhman.blogspot.com

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

Hi,
      I just commited the code for adding the tags support by attributes() function. On attributes function has been implemented, others like clearAttributes and addAttributes are not.
Albumdb class has a new method now, called getImageId(album Id, path) for the reasons discussed earlier.
Sorry i didn't know how to do CCMAIL in commit mesg, next time I would do that.

Vardhman

On 5/9/06, Vardhman Jain <[hidden email]> wrote:

Hi,
       There is something extra which I guess needs to be discussed. Most of the methods in KipiInterface just use albumDB interface to fetch/set some data about the photo in the database. This construction doesn't basically allow some temporary data storage which might be required for the session purposes only, let me explain.

If the user says he wants to upload the photos to flickr and wants to add some extra tags to the photos when they are uploaded to flickr and doesn't want to effect his original tags in digikam database. We cannot use AlbumDB object here to store the temporary information.

The solution in my opinion is to allow a DigikamImageInfo::QMap<QString,QVariant> attributes; member in the DigikamImageInfo to allow saving of data temporarily in the object using addAttributes() by the host application, while using attributes() from the plugin code to obtain the data ?

Please let me know ur viewpoints...

Vardhman

On 5/8/06, Caulier Gilles <[hidden email]> wrote:

Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit:
> Hi,
>        I am trying to hack in to the kipiinterface.cpp/.h files for adding
> some functionality to the attributes/setAttributes etc functions. I have
> some doubts whose clarfification will help me a great deal.
>

You want said these methods :

QMap<QString,QVariant> DigikamImageInfo::attributes()
void DigikamImageInfo::clearAttributes()
void DigikamImageInfo::addAttributes( const QMap<QString,QVariant>& )

right ?

> The function Albumdb->getItemTagNames( ImageId id)   takes an image id as
> an argument, while almost all other functions mostly use a combination of
> Album id and photo Url.
> There are some functions which work on ImageId but they are not at all used
> in implementation.
>
> As far as I can see there is no easy way to obtain an ImageId given a
> DigikamImageInfo object. Therefore I would like to ask if it would be okay
> to add another method in albumDb interface to allow seeking the tag info by
> combination of AlbumId and imageURL or a function should be added to return
> the imageId of a image given its AlbumId and imageURL in the albumDB file
> again ?

Yes, you can do it. Just overload the current methods and don't touch the
current implementation. Like this you don't unbreak the tests released on
this methods for 0.9.0 release.

Please, add comments in method headers, like others current methods using
Doxygen syntax.

When you commit, please CCMAIL on [hidden email]. Thanks in advance...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
<a href="https://mail.kde.org/mailman/listinfo/digikam-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: <a href="http://vardhman.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://vardhman.blogspot.com

--
Blogs: http://vardhman.blogspot.com

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

[Gilles Caulier-2]

Le Samedi 20 Mai 2006 11:24 PM, Vardhman Jain a écrit :
> Hi,
>       I just commited the code for adding the tags support by attributes()
> function. On attributes function has been implemented, others like
> clearAttributes and addAttributes are not.

Well, still todo... yes?

> Albumdb class has a new method now, called getImageId(album Id, path) for
> the reasons discussed earlier.

ok. have you tested your code with a plugin ? Have you checked your
implementation using valgrind (to be sure of course (:=))) ?

> Sorry i didn't know how to do CCMAIL in commit mesg, next time I would do
> that.

look here on the bottom of the page :

http://developer.kde.org/policies/commitpolicy.html

Thanks for your help

Gilles

>
> Vardhman
>
> On 5/9/06, Vardhman Jain <[hidden email]> wrote:
> > Hi,
> >        There is something extra which I guess needs to be discussed. Most
> > of the methods in KipiInterface just use albumDB interface to fetch/set
> > some data about the photo in the database. This construction doesn't
> > basically allow some temporary data storage which might be required for
> > the session purposes only, let me explain.
> >
> > If the user says he wants to upload the photos to flickr and wants to add
> > some extra tags to the photos when they are uploaded to flickr and
> > doesn't want to effect his original tags in digikam database. We cannot
> > use AlbumDB object here to store the temporary information.
> >
> > The solution in my opinion is to allow a
> > DigikamImageInfo::QMap<QString,QVariant> attributes; member in the
> > DigikamImageInfo to allow saving of data temporarily in the object using
> > addAttributes() by the host application, while using attributes() from
> > the plugin code to obtain the data ?
> >
> > Please let me know ur viewpoints...
> >
> > Vardhman
> >
> > On 5/8/06, Caulier Gilles < [hidden email]> wrote:
> > > Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit:
> > > > Hi,
> > > >        I am trying to hack in to the kipiinterface.cpp/.h files for
> > >
> > > adding
> > >
> > > > some functionality to the attributes/setAttributes etc functions. I
> > >
> > > have
> > >
> > > > some doubts whose clarfification will help me a great deal.
> > >
> > > You want said these methods :
> > >
> > > QMap<QString,QVariant> DigikamImageInfo::attributes()
> > > void DigikamImageInfo::clearAttributes()
> > > void DigikamImageInfo::addAttributes( const QMap<QString,QVariant>& )
> > >
> > > right ?
> > >
> > > > The function Albumdb->getItemTagNames( ImageId id)   takes an image
> > > > id
> > >
> > > as
> > >
> > > > an argument, while almost all other functions mostly use a
> > > > combination
> > >
> > > of
> > >
> > > > Album id and photo Url.
> > > > There are some functions which work on ImageId but they are not at
> > > > all
> > >
> > > used
> > >
> > > > in implementation.
> > > >
> > > > As far as I can see there is no easy way to obtain an ImageId given a
> > > > DigikamImageInfo object. Therefore I would like to ask if it would be
> > >
> > > okay
> > >
> > > > to add another method in albumDb interface to allow seeking the tag
> > >
> > > info by
> > >
> > > > combination of AlbumId and imageURL or a function should be added to
> > >
> > > return
> > >
> > > > the imageId of a image given its AlbumId and imageURL in the albumDB
> > >
> > > file
> > >
> > > > again ?
> > >
> > > Yes, you can do it. Just overload the current methods and don't touch
> > > the
> > > current implementation. Like this you don't unbreak the tests released
> > > on
> > > this methods for 0.9.0 release.
> > >
> > > Please, add comments in method headers, like others current methods
> > > using
> > > Doxygen syntax.
> > >
> > > When you commit, please CCMAIL on [hidden email] . Thanks in
> > > advance...
> > >
> > > Gilles
> > > _______________________________________________
> > > Digikam-devel mailing list
> > > [hidden email]
> > > https://mail.kde.org/mailman/listinfo/digikam-devel
> >
> > --
> > Blogs: http://vardhman.blogspot.com

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

On 5/21/06, Caulier Gilles <[hidden email]> wrote:

Well, still todo... yes?

Yep, Can we do it when the need is felt ? As of now I don't know if any kipi-plugin needs functionality to write Attributes for an image in to digikam database.

> Albumdb class has a new method now, called getImageId(album Id, path) for
> the reasons discussed earlier.

ok. have you tested your code with a plugin ? Have you checked your
implementation using valgrind (to be sure of course (:=))) ?

Yes, I tested with my own copy of flickrexport. Done some export, but before I can commit the latest flickrexport I have to make some GUI changes to flickrexport, which I will carry on once the code is approved. :)

> Sorry i didn't know how to do CCMAIL in commit mesg, next time I would do
> that.

look here on the bottom of the page :

http://developer.kde.org/policies/commitpolicy.html

Thanks for your help

Gilles

regards,
Vardhman

>

> Vardhman
>
> On 5/9/06, Vardhman Jain <[hidden email]> wrote:
> > Hi,
> >        There is something extra which I guess needs to be discussed. Most
> > of the methods in KipiInterface just use albumDB interface to fetch/set
> > some data about the photo in the database. This construction doesn't
> > basically allow some temporary data storage which might be required for
> > the session purposes only, let me explain.
> >
> > If the user says he wants to upload the photos to flickr and wants to add
> > some extra tags to the photos when they are uploaded to flickr and
> > doesn't want to effect his original tags in digikam database. We cannot
> > use AlbumDB object here to store the temporary information.
> >
> > The solution in my opinion is to allow a
> > DigikamImageInfo::QMap<QString,QVariant> attributes; member in the
> > DigikamImageInfo to allow saving of data temporarily in the object using
> > addAttributes() by the host application, while using attributes() from
> > the plugin code to obtain the data ?

> >

> > Please let me know ur viewpoints...
> >
> > Vardhman
> >
> > On 5/8/06, Caulier Gilles < [hidden email]> wrote:
> > > Le Samedi 06 Mai 2006 11:46 AM, Vardhman Jain a écrit:
> > > > Hi,
> > > >        I am trying to hack in to the kipiinterface.cpp/.h files for
> > >
> > > adding
> > >
> > > > some functionality to the attributes/setAttributes etc functions. I
> > >
> > > have
> > >
> > > > some doubts whose clarfification will help me a great deal.
> > >
> > > You want said these methods :
> > >
> > > QMap<QString,QVariant> DigikamImageInfo::attributes()
> > > void DigikamImageInfo::clearAttributes()
> > > void DigikamImageInfo::addAttributes( const QMap<QString,QVariant>& )
> > >
> > > right ?
> > >
> > > > The function Albumdb->getItemTagNames( ImageId id)   takes an image
> > > > id
> > >
> > > as
> > >
> > > > an argument, while almost all other functions mostly use a
> > > > combination
> > >

> > > of
> > >
> > > > Album id and photo Url.
> > > > There are some functions which work on ImageId but they are not at
> > > > all
> > >
> > > used

> > >
> > > > in implementation.
> > > >
> > > > As far as I can see there is no easy way to obtain an ImageId given a
> > > > DigikamImageInfo object. Therefore I would like to ask if it would be
> > >
> > > okay
> > >
> > > > to add another method in albumDb interface to allow seeking the tag
> > >
> > > info by
> > >
> > > > combination of AlbumId and imageURL or a function should be added to
> > >
> > > return
> > >
> > > > the imageId of a image given its AlbumId and imageURL in the albumDB
> > >
> > > file
> > >
> > > > again ?
> > >
> > > Yes, you can do it. Just overload the current methods and don't touch
> > > the
> > > current implementation. Like this you don't unbreak the tests released

> > > on

> > > this methods for 0.9.0 release.
> > >
> > > Please, add comments in method headers, like others current methods
> > > using
> > > Doxygen syntax.
> > >
> > > When you commit, please CCMAIL on [hidden email] . Thanks in
> > > advance...
> > >
> > > Gilles

> > > _______________________________________________
> > > Digikam-devel mailing list
> > > [hidden email]
> > > https://mail.kde.org/mailman/listinfo/digikam-devel
> >
> > --
> > Blogs: http://vardhman.blogspot.com
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: http://vardhman.blogspot.com

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

Vardhman Jain wrote:

> On 5/21/06, *Caulier Gilles*
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Well, still todo... yes?
>
>
> Yep, Can we do it when the need is felt ? As of now I don't know if any
> kipi-plugin needs functionality to write Attributes for an image in to
> digikam database.

SOrry for hijacking your thread on my first post to this mailing list
but perhaps this is a good opportunity for me to understand a little bit
more about Digikam before I start any development work.

I want to code tighter integration with the Gallery2 plugin into
Digikam. This would involve allowing additional configuriation of
"Albums" to allow sync'ing to a particular G2 Album. Allowing certain
images to be excluded from the sync, and downloading user comments from
G2 for viewing in Digikam (may require modifying the G2 end).

I have not started looking at the Digikam code yet so apologies if this
is premature... I hope to be able to have a look in the next few months.

Would these methods you are talking about be needed to e.g. write a "Do
not sync to G2" flag against a given image?

The reason I posted here on this thread was because you mentioned Flikr
and I see the Flikr and G2 syncs as being very similar (conceptually at
least).

All the best

Col.

--

+------------------------+
|     Colin Guthrie      |
+------------------------+
| kde(at)colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+

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

On 5/21/06, Colin Guthrie <[hidden email]> wrote:

SOrry for hijacking your thread on my first post to this mailing list
but perhaps this is a good opportunity for me to understand a little bit
more about Digikam before I start any development work.

Sure, not a problem, new developers are like always encouraged and welcome... ;) (I was too :))

...
I have not started looking at the Digikam code yet so apologies if this
is premature... I hope to be able to have a look in the next few months.

Would these methods you are talking about be needed to e.g. write a "Do
not sync to G2" flag against a given image?

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.

The reason I posted here on this thread was because you mentioned Flikr
and I see the Flikr and G2 syncs as being very similar (conceptually at
least).

Hopefully, we will have some solutions/suggestions from the kipi developers...

All the best

Col.

best regards,
Vardhman

--

+------------------------+
|     Colin Guthrie      |
+------------------------+
| kde(at)colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+

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

--
Blogs: http://vardhman.blogspot.com

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

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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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 <[hidden email]> 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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: http://vardhman.blogspot.com

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

Hi,
Haven't heard any opinions on this one, Shall I go ahead and roll out the functionality in my kipi-plugin ?

Vardhman

On 5/24/06, Vardhman Jain <[hidden email]> wrote:

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 <[hidden email]> 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  |
| <a href="http://colin.guthr.ie/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://colin.guthr.ie/ |
+------------------------+

_______________________________________________
Digikam-devel mailing list
[hidden email]
<a href="https://mail.kde.org/mailman/listinfo/digikam-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: <a href="http://vardhman.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://vardhman.blogspot.com

--
Blogs: http://vardhman.blogspot.com

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