1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
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().]
|
