[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-imaging
Subject: [Kde-imaging] Ownership policy
From: aurelien.gateau () free ! fr (=?iso-8859-15?q?Aur=E9lien=20G=E2teau?=)
Date: 2004-04-09 11:25:16
Message-ID: 200404091124.43998.aurelien.gateau () free ! fr
[Download RAW message or body]
Le Vendredi 9 Avril 2004 10:50, Jesper K. Pedersen a ?crit :
> | 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.
If we allow non-modal plugin dialogs (and I think we should), execution will
come back to the main program while the plugin dialog is still visible.
> | 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.
What cleanup method are you talking about?
> 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.
This sounds good to me. I think having signals to notify plugins about changes
in the collections would be a nice addition too.
Aur?lien
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic