Suggested redesign of currentAlbum() / currentSelection() / allAlbums() ======================================================================= Problem 1 ========= Plugins should be as similar as possible when it comes to user interaction. The topic for discussion here are what set of images does the plugin work on. Currently most KIPI plugins have been changed so that they use Interface::currentScope() which uses the selection if one exist, otherwise they use the currentAlbum if that exists. However, some plugins do not work like this, examples of alternative ways are: - always use selection (set wall paper) - ask what to use using a set of radio buttons ( can't remember which does this) - ask the user to select albums using check boxes. Problem 2 ========= Asking the user for an image set by the last method above only work well when the host application uses the concept of an Album - which KimDaBa doesn't. Solution - step 1 ================= Aurelien suggested the following solution, which works well when an application uses the concept of Albums: Replaces all the different ways above with a QListView showing the albums as returned by allAlbums(). The album returned by currentAlbum() would be selected by default. In the case of Gwenview, allAlbums() would return three virtual albums: - Selected images - All images in the current dir - All images in the current dir and subdirs In the case of KimDaBa, allAlbums() would return the list of keywords and a special "Any" keyword which would be contains the union of all the other keywords. Solution - step 2 ================= The above will seriously break with how KimDaBa approaches albums. A solution to this would be to make it up to the individual host applications to offer a browser for selecting images. The implementation would looks something like this: class Interface { ... virtual Browser browser() = 0; } class Browser { public: Browser( BrowserShared* ); virtual QWidget* widget( QWidget* parent ); KURL::List images(); // all the other stuff to make a shared class. signals: void descriptionChanged( const QString& ); void previewChanged( const QPixmap& ); } class BrowserShared { public: virtual QWidget* widget( QWidget* parent ) = 0; KURL::List images() = 0; signals: ... } The widget method should return the configuration widget, this might e.g. be the listview suggested by aurelien, or something else If the widget returned are 0, then the application do not want to offer any configuration, and the images must somehow be chosen before the plugin appears (This will be the case in KimDaBa). The images() method must return the selected images to operated on. The signals are for host application which offers dir==album, and have a description and preview for the dir (as is the case for digikam). The above replaces the currentAlbum(), currentSelection(), currentScope() and allAlbums() from KIPI::Interface. [Question: Should we remove these methods?] Also the ImageCollection class goes away. [Question: What do we do about uploadPath() and uploadURL().]