[Kde-imaging] feature list for host apps

[Jesper K. Pedersen]

On Friday 07 May 2004 12:15, Aurélien Gâteau wrote:
| Le Vendredi 7 Mai 2004 11:38, Jesper K. Pedersen a écrit :
| > But how about this idea:
| > How about in the KIPI::Interface class have the following code
| >
| > namespace KIPI {
| >   enum Features { AlbumsHaveDescriptions = 0x0001, xxx = 0x0002,
| >                   yyy = 0x0004, ... }
| >   Class Interface {
| >      int features();
| >      ...
| >   }
| > }
| >
| > In plugins which want to integrate well into the apps, they could now
| > have code like
| >
| > if ( interface->features() & AlbumHaveDescriptions  == 0 ) {
| >    // Host app does not have the concept of album description
| >    commentsArea->hide();
| > }
|
| The idea is good, but I'm concerned that the host app will still have to
| provide non working implementations of the missing features. In your
| example, you will have to implement the setAlbumDescription() and
| albumDescription() methods.
Sure, I completely agree, we do not want the host app to crash in case a 
plugin is used that do not care about features.

| I'm wondering if it's possible to access such methods through other
| interfaces which could be implemented or not. I don't have a concrete idea
| yet, but I'm thinking about something like this:
|
| ---
| namespace KIPI {
|   class Interface {
|     AlbumDescriptionInterface* albumDescriptionInterface();
|     /* ... */
|   };
|
|   class AlbumDescriptionInterface {
|     setDescription(const QString&);
|     QString description() const;
|   };
| }
| ---
|
| In KimDaBa, you would implement albumDescriptionInterface() as { return 0;
| }. The plugin code would look like this:
|
| ---
| albumDescIface=interface->albumDescriptionInterface();
|
| if (!albumDescIface) {
|   commentsArea->hide();
| }
| ---
|
| Maybe we could even use dynamic_cast, which would produce something like
| this: ---
| namespace KIPI {
|   class Interface {
|     /* ... */
|   };
|
|   class AlbumDescriptionInterface : public Interface {
|     setDescription(const QString&);
|     QString description() const;
|   };
| }
| ---
|
| Plugin code:
| ---
| albumDescIface=dynamic_cast<KIPI::AlbumDescriptionInterface>(interface);
|
| if (!albumDescIface) {
|   commentsArea->hide();
| }
| ---
|
| What do you think about this?
I think we should stick to the goal that it should be as easy to develop a 
plugin as possible, and if that makes it harder to make your app kipi aware 
then let it be like that.

Your suggestion, is indeed good and clean, but I'm afraid you will see plugins 
developed entirely for app A which do support this interface, and then one 
day someone downloads the plugin and tries it with app B, which simply 
crashes because the code did not check the albumDescIface pointer.

Using enums makes it optional to tailor plugins for the features of the host 
apps, thus easy to develop a plugin, and if you want to make the plugin 
really nice you can take it one step further.

In the example above KimDaBa would simply return an empty string when asked 
for a description of an album, and setDescription would simply be implemented 
as an empty method.

Cheers
Jesper