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

List:       kde-imaging
Subject:    Re: [Kde-imaging] RFC: next kipi & co. generation
From:       Colin Guthrie <gmane () colin ! guthr ! ie>
Date:       2006-09-28 18:56:44
Message-ID: efh5pj$tga$1 () sea ! gmane ! org
[Download RAW message or body]

Aurélien Gâteau wrote:
>> Obviously for non-permanent collections (like e.g. the current
>> selection?) it would not make sense to provide a KConfig interface, so
>> the plugin should check to see that it is provided before using it!
>>
>> Also it would be optional for a host application to provide this, so it
>> doesn't have to be implemented but the host app would loose certain
>> functionality of the plugin.
> 
> Hmm, beware of "flexibility overflow". While it sounds nice, it means a plugin
> should be tested on different hosts to make sure it works consistently on all
> of them.
> 
> I would rather only add a isPermanent() method to ImageCollection so that a 
> plugin can determine if it can store settings. If an host app doesn't want to
> implement support for permanent settings it only needs to return false in 
> isPermanent(). This could even be the default implementation of isPermanent().

True, that should be enough :)

Tho' if we are e.g. returning a KConfig* from e.g. a GetConfig() method,
it is still good practice to do null checks etc. Hense why I was
thinking that the default implementation of GetConfig() would just be
"return NULL;" and that would make it, by default, optional. It doesn't
really matter all in all really as long as, in principle, I'm not
suggesting something stupid :)

Col.

_______________________________________________
Kde-imaging mailing list
Kde-imaging@kde.org
https://mail.kde.org/mailman/listinfo/kde-imaging

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