Bug 225443 - Fileview preview panning shortcut back to old.
Summary: Fileview preview panning shortcut back to old.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Keyboard (show other bugs)
Version: 1.1.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-03 22:57 UTC by Fri13
Modified: 2017-08-02 17:41 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fri13 2010-02-03 22:57:54 UTC
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.
Comment 1 caulier.gilles 2010-02-04 09:43:46 UTC
This is in oposite than file beow now closed :

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

Gilles Caulier
Comment 2 Dotan Cohen 2010-02-04 11:17:51 UTC
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.
Comment 3 Marcel Wiesweg 2010-02-04 19:54:46 UTC
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.
Comment 4 Johannes Wienke 2010-02-04 19:57:34 UTC
(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.
Comment 5 Dotan Cohen 2010-02-04 22:17:58 UTC
> 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.
Comment 6 Fri13 2010-02-05 13:59:07 UTC
@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.
Comment 7 Dotan Cohen 2010-02-05 14:20:49 UTC
> 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.
Comment 8 Fri13 2010-02-05 15:45:03 UTC
"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.
Comment 9 Fri13 2010-02-05 15:53:47 UTC
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).
Comment 10 Marcel Wiesweg 2010-02-05 19:48:39 UTC
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.
Comment 11 Dotan Cohen 2010-02-06 13:41:02 UTC
> 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!
Comment 12 Marcel Wiesweg 2010-02-06 15:00:18 UTC
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".
Comment 13 Johannes Wienke 2010-02-06 15:06:30 UTC
Or if the global KDE settings is double click, use double click for getting into preview and out.
Comment 14 Dotan Cohen 2010-02-06 15:21:12 UTC
> 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.
Comment 15 Fri13 2010-02-10 13:41:36 UTC
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.
Comment 16 Dotan Cohen 2010-02-11 08:11:47 UTC
> 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.
Comment 17 Fri13 2010-02-11 19:41:35 UTC
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.
Comment 18 Marcel Wiesweg 2010-02-25 17:32:11 UTC
SVN commit 1096047 by mwiesweg:

In the preview:
a) For single click system settings:
	- Click        -> back to icon view
	- Click + Drag -> pan if zoomed
b) For double click systems:
	- Double click -> back to icon view
	- Click + Drag -> pan if zoomed

Dragging is defined by the Qt's startDragDistance()

This is not the big solution envisioned by some comments, but it is the small
solution that most people can live with, and which restores good old behavior.

BUG: 225443

 M  +2 -1      NEWS  
 M  +1 -1      digikam/imagepreviewview.cpp  
 M  +56 -24    libs/widgets/common/previewwidget.cpp  
 M  +4 -0      libs/widgets/common/previewwidget.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1096047
Comment 19 Dotan Cohen 2010-02-25 23:32:26 UTC
Sounds good, Marcel. Thanks.
Comment 20 caulier.gilles 2010-02-26 14:43:47 UTC
Marcel, 

today, i see that a regression is introduced in imagepreview / imageregionwidget It's easy to reproduce : take White Balance tool (just ported to imageregionwidget) and zoom in at 100% for Ex. Render preview to push Try button. Now move preview content with middle mouse button... preview area is not refreshed as well. I suspect commit #1096047 (:=)))

I'm sure to have tested this case before. Can you reproduce the problem ?

Gilles Caulier
Comment 21 caulier.gilles 2010-02-26 14:50:00 UTC
Marcel,

Screenshot of the problem is there :

http://farm3.static.flickr.com/2789/4389144349_75cabb9065_o.png

Gilles Caulier
Comment 22 Marcel Wiesweg 2010-02-26 19:19:49 UTC
SVN commit 1096474 by mwiesweg:

Add missing update()

CCBUG: 225443

 M  +1 -0      previewwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1096474
Comment 23 Marcel Wiesweg 2010-02-26 19:21:07 UTC
With this commit the painting artifact is fixed.
What still does not work is automatic recreation of the preview, that is, I have to press "Try" again after each move operation, which I found a bit irritating. Was that different before my change?
Comment 24 caulier.gilles 2010-02-26 19:32:30 UTC
Marcel,

It's another problem. signal/slot connection is just missing in each tools to handle this event.

But take a care, i remember a file where Andi has already talk about this suject with users. Some time they want this behavior, sometime, no...

Gilles
Comment 25 Andi Clemens 2010-03-24 20:36:31 UTC
We still need some option to turn off this label and the overlay buttons. They are really annoying, so annoying that I currently use gwenview or showfoto to view my images. Users should not be forced to have something painted above their images ;-)
Comment 26 caulier.gilles 2010-03-25 08:22:47 UTC
Andi, 

I understand your whish, and i'm agree with you.

But i want to explain why i set this annotation overlay in preview mode. The problem is to give some feedback to end user about what he see in preview mode. Sometime user think to see real full image but it's not the case, especially with RAW files. Do you remember all post in mailling list about this subject ?

For me, providing an option to disable this overlay is fine but option must be on by default.

Gilles Caulier
Comment 27 Fri13 2010-03-25 12:01:11 UTC
I think the overlay of information (is it a preview or a original) could be shown someway nicer way so it is not so disturbing.
Comment 28 caulier.gilles 2010-03-25 12:06:27 UTC
Fri13,

Andi speak about preview mode, F3 in album gui, not preview of effects in image editor.

Gilles Caulier
Comment 29 Fri13 2010-03-25 14:53:08 UTC
Gilles, I meant that as well. The top right "Reduced size preview"

All do not need the rotation/next/previous or back buttons. But the "Reduced size preview" info alone as well is very handy for many.
Comment 30 Andi Clemens 2010-03-25 20:44:40 UTC
(In reply to comment #26)
> Andi, 
> 
> I understand your whish, and i'm agree with you.
> [...]
> For me, providing an option to disable this overlay is fine but option must be
> on by default.

As long as there is an option, I don't care if the default is to display those overlays / the label. I can turn it off anyway :-)
I know this label might be important for some users, but wouldn't it be better to have this in the status bar or so? An overlay is too distracting when viewing images.
Comment 31 Fri13 2010-03-26 10:52:10 UTC
I think we need to open a wish for the overlay discussion. Because it has multiple different features and causes what it makes.
Comment 32 caulier.gilles 2011-12-16 11:23:04 UTC
Fri13,

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 33 caulier.gilles 2012-06-26 14:53:11 UTC
This file still valid using last 2.6.0 release ?

Gilles Caulier
Comment 34 Dotan Cohen 2012-06-26 15:07:15 UTC
The behaviour in Digikam 2.5 seems very intuitive and seems to meet most of the requirements that I see posted above. As far as I am concerned this issue can be closed.