[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-imaging
Subject:    [Kde-imaging] Ownership policy
From:       blackie () kde ! org (Jesper K !  Pedersen)
Date:       2004-04-09 10:50:58
Message-ID: 200404091050.51385.blackie () kde ! org
[Download RAW message or body]

On Friday 09 April 2004 10:19, Aur?lien G?teau wrote:
| 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.
Well the idea would be that if teh plugin wants to keep the data for a longer 
time, then it should make a copy.
Remeber, howeverm that we are not talking multi processs or even multi 
threading here, once the plugin is invoked, execution will continue there 
till it returns, as it is the same execution thread as the main program.

| 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?
I dont like the idea of having to explicit call a cleanup method, as that just 
makes the job harder for the plugin developers.

So lets choose on either of the two approaches I suggested. Personally I dont 
care, and I doubt that any application would store their internal data in the 
list of the plugins data structure, so the problem with giving ownership to 
the plugin should be little. Of course this requires the plugin to remember 
to do the clean up.

|
| > | 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 :(
OK
[prev in list] [next in list] [prev in thread] [next in thread]