[Kde-imaging] Ownership policy

Aurélien Gâteau aurelien.gateau at free.fr
Fri Apr 9 10:19:06 CEST 2004


Le Vendredi 9 Avril 2004 08:45, Jesper K. Pedersen a écrit :
> On Friday 09 April 2004 00:54, Aurelien Gateau wrote:
> | Hi!
> |
> | I'm trying to write a real implementation of KIPI::Interface in Gwenview.
> | I'm wondering about the ownership policy of currentAlbum() and
> | currentSelection(): Should the caller be responsible of deleting it or
> | should it be up to the KIPI::Interface implementation? If the second,
> | what would be the lifetime of the returned pointer?
>
> I think we came up with this on IRC:
> Some applications may simply return a pointer to their own internal
> datastructure of the data, while others may make them up. Therefore we can
> not hand ownership on to the plugin, as the plugin would delete internal
> data of the application.
> The lifetime of the data is instead until the function generating the data
> is called again. That way you could simply have a static datastructure you
> refill for each usage. (This idea is similar to many C library function,
> though I can't think of any right now)

Isn't it going to be tedious when multiple plugins get called? if we've got 
some non-modal plugins, they might keep a reference to a structure which 
could get changed - or even worse, deleted - behind their back. On the other 
hand having the host application do a fresh copy each time asked is not good 
either.
Maybe we can specify that the ImageCollection objects must live for the whole 
life of the application and add some signals to KIPI::Interface so that the 
host can notify the plugins of changes in the collections. What do you think 
about this?

>
> | PS: I will be away on Sunday (11/4) till next Sunday (18/4). Just so that
> | you don't wonder why I don't answer fast :-)
>
> Damn,
> I've taken next week off to concentrate sololy on KimDaBa, and on the
> plugin structure.
> Are there no chance for you to read email?

I'm afraid it won't be possible :(

Aurélien



More information about the Kde-imaging mailing list