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.
This is in oposite than file beow now closed : http://bugs.kde.org/show_bug.cgi?id=183108 Gilles Caulier
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.
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.
(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.
> 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.
@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.
> 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.
"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.
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).
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.
> 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!
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".
Or if the global KDE settings is double click, use double click for getting into preview and out.
> 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.
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.
> 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.
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.
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
Sounds good, Marcel. Thanks.
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
Marcel, Screenshot of the problem is there : http://farm3.static.flickr.com/2789/4389144349_75cabb9065_o.png Gilles Caulier
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
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?
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
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 ;-)
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
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.
Fri13, Andi speak about preview mode, F3 in album gui, not preview of effects in image editor. Gilles Caulier
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.
(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.
I think we need to open a wish for the overlay discussion. Because it has multiple different features and causes what it makes.
Fri13, This file still valid using digiKam 2.4 ? Gilles Caulier
This file still valid using last 2.6.0 release ? Gilles Caulier
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.