You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
97 lines
3.1 KiB
97 lines
3.1 KiB
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().]
|