[Bug 225443] New: Fileview preview panning shortcut back to old.

https://bugs.kde.org/show_bug.cgi?id=225443

           Summary: Fileview preview panning shortcut back to old.
           Product: digikam
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

The SVN version of digiKam after 1.1.0 release use new way to pan the preview
of photograph.

1. You click/double click the thumbnail to get it opened as preview
2. You press left mouse button to pan
3. To close the preview you need to double click the preview.

This does not follow the function of showFoto what pans with the mouse middle
click and selects area/draw on left click.

The left click should be about selecting files/area.

Change the exiting of preview back to single click and keep only middle click
as panning. Having a lighttable as well making a selection box on left button
would allow having zooming fast way to wanted position.

Same thing with the preview on digiKam if the preview would be full size.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=225443


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |1.1.0




--- Comment #1 from Gilles Caulier <caulier gilles gmail com>  2010-02-04 09:43:46 ---
This is in oposite than file beow now closed :

http://bugs.kde.org/show_bug.cgi?id=183108

Gilles Caulier

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=225443


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|general                     |Preview




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443


Dotan Cohen <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #2 from Dotan Cohen <kde-51 dotancohen com>  2010-02-04 11:17:51 ---
Just make it optional, Gilles.

Even the statement "You click/double click the thumbnail to get it opened as
preview" is incorrect as _that_ behaviour is optional as well. Both sides of
the argument have this feature as very important to them. I don't see a
compromise any better than the current SVN solution.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #3 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-02-04 19:54:46 ---
Dotan, making it optional solves it for you, which is good, but still leaves us
to decide on the default setting, which is how it works for the majority of
users ;-)

Fri is right mentioning the inconsistency of left-button panning in the image
viewer vs. left-button area selection in the image editor. I would accept this
though, because image viewing (preview and light table) is quite different from
editing.

For me, the workflow in the icon view/preview is much more important. I still
put forward the suggestion to pan when left-dragging, and switch between icon
view and preview with single or double click depending on system settings.

I dont really mind if there is an option.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Johannes Wienke-3]

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #4 from Johannes Wienke <languitar semipol de>  2010-02-04 19:57:34 ---
(In reply to comment #3)
> For me, the workflow in the icon view/preview is much more important. I still
> put forward the suggestion to pan when left-dragging, and switch between icon
> view and preview with single or double click depending on system settings.

That's also what I would like.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #5 from Dotan Cohen <kde-51 dotancohen com>  2010-02-04 22:17:58 ---
> but still leaves us
> to decide on the default setting

Actually, I think that the default setting should stay as it is in SVN, as it
seems to be the behaviour that users expect. I feel that I have authority to
say this as I have installed Digikam (actually, Kubuntu) for lots of people and
this is one of those issues that almost _everyone_ trips over.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443


Fri Duh <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #6 from Fri Duh <friiduh gmail com>  2010-02-05 13:59:07 ---
@Doten "for lots of people and this is one of those issues that almost
_everyone_ trips over."

I have found that old people (and I am as well talking about lots of people,
counted almost in three numbers) likes very much to see a big preview of the
photo in the album view. They want easily to see the photo and rotate it if
needed. But they expect to get the preview away easily or go to next one. And
they are afraid about clicking anything. And when I say "Just click the photo
once as you did to get the preview, you see the album again". And they just
like how intuitive the single click is, because I always configure the single
click function to system because they do not never know when to do single
click, when to do a double click, without mentioning when to do the right
click!

And many does not even understand how to use the wheel scroll otherplaces than
on website or in text editing (if they even know how to open such application).
And they use the zoom slider bottom of the screen and not wheel. At this point
it comes difficult to pan. Because for them, the wheel is up/down movement and
not in/out.

There is the bug in the current preview. It still shows the scrollbars even
that user have not zoomed in at all.

And the idea to have a single click = close and single click + drag = pan. Can
cause problems even as well because even the basic dragging is very difficult
to people. They do mistakes on file management by dragging when clicking and
they get copying and other dialogs and errors in front of them.

So I would take the next functionality if a must.

System set to single click:
1. Click thumbnail in albumb view to get a preview
2. Click preview to get back to albumb view
3. Wheel or Zoom slider to zoom in/out
4. When zoomed in. The left mouse click would pan
5. Double clickin while zoomed in switch to albumb view (some people would
expect to get back to fit-to-screen zoom.)

Pros: User can easily open/close the preview
Cons: User can not wait to expect to know when to do double and when single
click.

System set to double click:
1. Double click in album view the thumbnail to get a preview
2. Double click in album view the preview to get to album view  (at any zoom
level)
3. Wheel / Zoom slider to zoom in/out
4. Left button drags when zoomed in.

Pros: No mistakes between single and double clicking

So what if we change to the feature what needs click+dragging to pan when
having a single click function enabled?
It brings question about how much we need to move cursor to start panning.
20-40px? Does user expect that when taking finger off the preview does not get
closed?

And should then be pop-upped the small thumbnail as clicking the pan button
where sliders cross on bottom right corner? People likes that because they can
see on what direction they are going.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #7 from Dotan Cohen <kde-51 dotancohen com>  2010-02-05 14:20:49 ---
> But they expect to get the preview away easily or go to next one. And
> they are afraid about clicking anything. And when I say "Just click the photo
> once as you did to get the preview, you see the album again".

You yourself say that they are afraid of clicking the photo, therefore, what
you are asking of them is obviously _not_ the intuitive behaviour. In what
other application does one click the main object to go _back_ in the history of
actions? I do agree that the photo itself is a nice large target, but that does
not mean that clicking it should bring one back to the album view. In fact, I
can make an argument for a single click on the photo to advance to the _next_
photo.

Therefore, the option should have these states:

Left click on photo:
    1) Pan
    2) Return to album view
    3) Advance to next photo
    4) Pan if moved, return to album view if not
    5) Pan if moved, advance to next photo if not
Middle click on photo:
    1) Pan
    2) Return to album view
    3) Advance to next photo
    4) Pan if moved, return to album view if not
    5) Pan if moved, advance to next photo if not

I assume a single-click system. I am disabled and cannot use a double click
system, and at this time (our holy day starts in two hours) I cannot call and
ask other users what their expected behaviour would be on a double click
system.


I will not argue about what the default should be any longer, as everyone is
convinced that his preferred behaviour should be the default. Gilles, your
call.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #8 from Fri Duh <friiduh gmail com>  2010-02-05 15:45:03 ---
"You yourself say that they are afraid of clicking the photo, therefore, what
you are asking of them is obviously _not_ the intuitive behaviour."

That does not mean that they are afraid to click the photo because it turns the
preview off. They are afraid to click anything, menus, toolbar... and even more
afraid doing a double click because they have no idea what difference is
between single and double click and when to do them.

Long time users can understand the basic difference of single and double click.
They can even reconize the difference between button and icon.

" In what other application does one click the main object to go back in the
history of actions?"

Almost all. You click to enable something in menu and you click again to turn
it off. You click on toolbar to fullscreen and again to return back. Single
click to back and worth. Not single click to enter somewhere and double click
to go back.
Even Konqueror has the option to turn on the single right click to go back in
history instead using the toolbar buttons.

The only difference example the Back/Forward icons and Fullscreen is that other
gives the indicator that you can turn the function off when clicking it again.
Like menu entries has the [X] checkmark in front of them telling the ON/OFF
function.

And we are still talking about mouse controlled user interface, not
touchscreen. On touchscreen it would be very intuitive and logical to pan view
when sliding finger over it.

And double click is more like "execute" or "Open" and not "close" or
"shutdown".

If we brake up the idea of the Album view.

We are watching first thumbnails a small picture of the photograph. And we have
lots of them (depending the thumbnail size).

Why we want to click a photo?
1) Preview it on bigger size
2) Open it to editor.

When we do open it to editor, it comes to follow showFoto rules, what are now
that the area selection is on left click, pan is on middle click.

but if we open the preview, we get by default the bar of thumbnails as well.
The bar tells us that we can browse the photos as well from there.
But we have two questions here.

a)  How do I get back to album view?
b) How I zoom in?

How does user zoom in? He use the zoom buttons or slider at bottom of the
screen. Where are located other functions to view like previews, zooming
panning and warning indicators.

The Panning is secondary action after the zooming.
When we are at the first step - what was to get the big preview up - the main
question is how to get back (we can make a assumption we want to go the next
photo but it is as wrong as making assumption we want to jump to first photo or
select any other) to the album view. We can click the album again and it can be
intuitive function because it is one place where we change the main view. But
it should not be so that we need to click again the album and get jumped to
first photo. Getting back should happen by same way as we got there. Just by
stepping back.

We did first a single click to get a preview. Making again a click is intuitive
way to get back. But this is a case only when we do have a single click on
system. On double click functions the double clickin is the intuitive way to go
back.

And specially on the case where we have turned off the thumbnails bar on
preview or the statusbar, the mouse buttons turns to be more vital to functions
by intuitive way than what the GUI tells us (example this case clicking the
album turns to be intuitive if single click does not turn back to original
view).

This questions is as well about how many buttons do we have on mouse and what
they actually do.

_Normal three button mouse:_
Left | Middle | Right

Left enters to preview and quits it.
Middle zoom In/Out and Pans
Right brings up the context menu.

_If we would have two button mouse:_
Left | Right

Left enters to preview and pans it.
Right brings up the context menu.
Right+Left zoom In/Out.
Double clickin quits the preview.

_Five button mouse:_
Left | Middle | Right
Back | Forward

Left enter to preview and close it
Middle zoom in/out and pan
Right click opens the context
Back and Forward moves to next/last photo

And these would be on single click system. The double click adds a new choise
to have a single left click to pan the view and not the default view button,
the middle click with zoom in/out function.

I can understand very well the double click to exit preview when having a
double click system. I have desktop computers in such way configured and other
advanced users who I know.
But on laptop what I mainly use with only a touchpad, the single click to
enter/exist is more intuitive when using just one finger. But when using two
fingers touchpad+mouse buttons that I can keep left click pressed, I wait that
I can do a selection like on thumbnails etc. And one reason _I wait_ next
thing, is that I have a multitouch capable touchpad. I zoom in/out with two
fingers and I pan with three fingers (middleclick) just like I would do with
middle button on my mouse.

The whole single click vs double click question is a very huge and it depends
so much about what questios we do have in our mind, what we want to do and how
to reverse the actions what we just did and how we do not do mistakes.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #9 from Fri Duh <friiduh gmail com>  2010-02-05 15:53:47 ---
Forgot to include the last point:

As I said, on double click system the double click to exist the preview is
totally sane and intuitive way.

But on single click systems, we can not set any function to double click.
Because every action is behind single click. Existing the preview back to the
album view is more used function than panning around. And we do have a pan
button in the crossing section of scroll bars for double and single click
users.

Normal can not be expected to know how to turn off the preview with double
click when they have whole system under the single click functionality and hey
use mouse.

As mentioned, we can not tie panning to single click as long as the user has
made second step = zoomed IN and that is already on advance section where view
controls are affecting.

So I would still say that the default case is that user watch thumbnails and
wants to see one of them in bigger size. In the single click systems the single
click opens preview and it close the preview. No panning, no zooming and other
features without using their controls (scroll wheel, buttons on panel etc).

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #10 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-02-05 19:48:39 ---
Fri Duh, I support a lot of what you say here. I like the methodological
approach.

The distance to call a drag a drag is usually defined by the system.
Showing the small drag preview in the right bottom corner while panning should
be feasible.

You propose zooming by mouse wheel, but as soon as the image is zoomed a bit
and scroll bars appear, I expect the mouse wheel to scroll.

I don't care about middle mouse button because I do not expect users to know
about this.

Can you summarize your opinion on the pan-when-dragging-go-back-when-clicking
suggestion? That's not clear to me.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #11 from Dotan Cohen <kde-51 dotancohen com>  2010-02-06 13:41:02 ---
> As I said, on double click system the double click to exist the
> preview is totally sane and intuitive way.

> But on single click systems, we can not set any function to double
> click. Because every action is behind single click.

I am a single click user, and I do not see anything wrong with single click
going back so long as a single click and drag will pan. In fact this is how I
would prefer it to work, even though I would not have come up with the idea
myself. As this is the current SVN behaviour, I have a hard time understanding
what your objection to this behaviour is (in the context of a single click
system). It might be somewhere in your post, but it's long and my English is
bad :)

Please make this clear:

Do you object to "single left click: back | left drag: pan" behaviour for
single-click mode? If so, on what basis?

Do you object to "single left click: back | left drag: pan" behaviour for
double-click mode? If so, on what basis?

Do you object to the options proposed in Comment #7? If so, on what basis?

Thanks!

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=225443


Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #12 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-02-06 15:00:18 ---
In current SVN, a single click does not bring me back, it does nothing. That's
why I am involved here at all! I want the single click to bring me back.

To reconcile with the recent changes, Johannes and me proposed "single left
click: back | left drag: pan".

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Johannes Wienke-3]

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #13 from Johannes Wienke <languitar semipol de>  2010-02-06 15:06:30 ---
Or if the global KDE settings is double click, use double click for getting
into preview and out.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #14 from Dotan Cohen <kde-51 dotancohen com>  2010-02-06 15:21:12 ---
> In current SVN, a single click does not bring me back, it does nothing. That's
> why I am involved here at all! I want the single click to bring me back.

So long as it leaves "pan on left drag" then I agree with you that this should
be the behaviour for single-click systems. For double-click systems, of course,
it should require a double click.


> To reconcile with the recent changes, Johannes and me proposed "single left
> click: back | left drag: pan".

I agree with this.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443


Fest <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #15 from Fri Duh <friiduh gmail com>  2010-02-10 13:41:36 ---

Single click systems:

Single click -> Back
Single click + Drag -> Nothing
Single click + Drag -> Pan when zoomed in
Double click -> Nothing

Double click systems:

Single click -> Nothing
Single click + Drag -> Nothing
Single click + Drag -> Pan when zoomed in
Double click -> Always back

I still would not place the panning to left click because we have the middle
click for view functions to zoom in/out and pan. This way the left click
controls the functions while middle click controls the view and it works on
every tool in digiKam same way.

If we are later going to add a face tagging etc. we need left click + drag to
area selection. That we show a preview and drag the face and tag that.

Thats why I would keep the single click + drag doing nothing yet until it would
come the selection.

When imagining this, it would come on single click systems (double click is not
affected):

Single click -> Back
Single click + Drag -> Area selection
Single click + Drag -> area selection when zoomed in
Middle click + Drag -> Pan the view when zoomed in

Otherwise we should need to invent something to area selection function (like
for face tagging) and it would be again different than in image editor
(showFoto) or Lighttable.

Or we can make all tools to work same way by removing the Click+Drag being a
selection in Image editor (showFoto) and be it a middleclick + Drag because
users are expected to get a panning with left click + drag when zoomed in and
not the selection.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #16 from Dotan Cohen <kde-51 dotancohen com>  2010-02-11 08:11:47 ---
> Otherwise we should need to invent something to area selection function (like
> for face tagging) and it would be again different than in image editor
> (showFoto) or Lighttable.

Everyone wants his pet favorite feature to be the default left-click /
left-drag implementation. This is why there should be option. Alice may never
pan, and Bob may never tag.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=225443





--- Comment #17 from Fri Duh <friiduh gmail com>  2010-02-11 19:41:35 ---
And still we would have the middle button what currently does panning in all
digiKam tools = similar.

And putting behind the options the functionality to choose between panning/area
selecting is not good idea.
If we want to keep the pannin on left click + drag. Then it must be same on
image editor and all other tools. Then make the selection to something else.

And the panning with click+drag is not always best way because many seems to
use the reduced preview and does not allow to be loaded the full size. What
means that we can not zoom much inside to pan.

And if we want to keep single click + drag as panning. We need to change the
mouse cursor as a hand icon and not keep it as arrow what gets changed as cross
when dragging. The icon change is needed to give the information to user that
dragging the photo it pans.

It is just weird that we have one button button what opens/close the preview
and other button what controls the view to zoom in/out and pan. And same thing
works in both single and double click systems?

One good thing what having a double click function in single click system is
that with single click + drag we could assign a fit/100% view change to middle
button.

Other thing what supports single click + drag is the touch screens. What is
used with one finger most times. But touch screens works different way than
mouse and such screens are not good to edit photos, but they are good to browse
photos. But should all be designed by the basis of touch screens?

So is the best choice if we have configuration for single click systems:

Click enter/exist
Click + drag to pan
Wheel forward/back zoom to pointed area
Middle click to Fit/100% to pointed area
Ctrl+Drag to area selection

This would mean we need to change the editor as well to pan the view when left
click + draggin. And doing a area selection with Ctrl+ Drag (do we need much
the area selection in the editor?).

But the single click + drag should be marked as hand cursor like the Marble in
the sidepanel that user can know the single click + drag is panning.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel