Summary: | Forward / Back (Previous / Next) don't work in preview mode | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Aron Parsons <aronparsons> |
Component: | Preview-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 2.5.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 4.3.0 | |
Sentry Crash Report: | |||
Attachments: | Add Left/Right for Image Preview Navigation Keys |
Description
Aron Parsons
2008-04-09 03:16:04 UTC
Aron, It's not reproducible here. I can use Left/Right to navigate between images in preview mode. Note : you can use also PageUp/PageDown. 1/ Try to test with a fresh account to see if it's reproducible. 2/ Try to reset your ~/.kde/share/config/digikamrc file to rename it with .old extension and restart digiKam Gilles Caulier I started with a fresh account and saw the same behavior. PageUp/PageDown work immediately in preview mode as they should. However, previous/next (shift+left, shift+right) do not unless I do the right-click trick. Are PageUp/PageDown mapped to the Back/Forward functions internally? And if so, why are they not defined in 'Global Shortcuts' for Back/Forward whereas Shift+Left and Shift+Right are? Perhaps the 'Preview Panel' just needs to explicitly be given focus when a new image is presented since giving it focus (right-click method) seems to resolve the Back/Forward functionality? (just a guess, I haven't dived into the code!) What about this bug? I can not reproduce it either. Should we close it? It's still there in 0.9.4. Summary: Double click a thumbnail to view a full size preview in the main frame. I expect left/right arrow keys to work for previous/next image. They do not work until I right-click to bring up the context menu on the image and then hit escape. Once I do that (I guess to give it focus), the left/right arrow keys work as expected for previous/next image in the album. Page down/page up work for previous/next image in the album all the time. But PageUp / PageDown is the normal way to navigate. Why do you except it to be left / right arrow keys? You can use left / right in icon view mode, but this is because int there you are also able to navigate up / down. It doesn't make much sense to use the icon view navigation keys in detail / fullscreen view. For me this is no bug but (somehow) a feature request. I initially reported this as a bug because I recall left/right worked for navigation in an earlier release (sorry, I can't recall at this time). Is there a shortcut configuration meant to control back/forward (or previous/next, whichever the proper labels are)? Page down and page up are not intuitive to use for navigation, whereas the left/right arrow keys are. It goes in line with icons used for navigation as well (left and right arrow icons). Created attachment 26473 [details]
Add Left/Right for Image Preview Navigation Keys
This patch adds the functionality that this bug is about. Perhaps it would be
better to add a configurable shortcut in 'Configure Shortcuts'?
About #6 "Page down and page up are not intuitive to use for navigation, whereas the left/right arrow keys are." I don't agree. It's usual in most tools. Usually, arrows are used to pan inside an image or document (image size bigger than display size) and pageup/pagedown are used to move to the next image/document... I also think that PageUp/PageDown is much more intuitive than left/right arrow keys. Almost every app I used before behaves like that, regardless of using a windows or a Unix GUI app. Interesting. Every photo application I've used (Embedded Image Viewer in Konqueror, iPhoto, Picasa, Windows Gallery) I use left/right for flipping between full-size previews. I guess what feels natural to some is awkward for others. ;-) I do agree that the arrows are used for panning when zoomed in, but that's something I rarely do these days with a high resolution monitor. This bug can be closed at your discretion. It's never been a major issue as I've gotten along fine since 0.9.2 without finding a solution. I'll either add the patch in a Gentoo ebuild or just change my navigation habits. Thanks for feedback. :-) I am not sure what to do with this wish and patch... Let me try to do a summary of the current behaviour: - In the icon view, the Arrow keys go to the left, right, up or down, respectively - In the icon view, PageUp/PageDown go to the previous or next image. According to the discussion summarized in http://bugs.kde.org/show_bug.cgi?id=141730#c6 the conclusion of an IRC discussion was: - PageDown/PageUp should do what they say ;-) - In Preview mode: PageDown/CursorRight and PageUp/CursorLeft should go to the previous/next item. So this would mean to make things consistent and apply Aron's patch #c7 . However, a point we should take into account is Fabiens remark that """Usually, arrows are used to pan inside an image or document (image size bigger than display size) and pageup/pagedown are used to move to the next image/document...""". Note, that currently arrows do not work to pan inside an image. ((One could of course use arrows for panning when the image is not fitting, and arrows to go to the previous/next image, when it fits. However I am not sure what useability experts will say on this ... ;-)). Have you looked at Gwenview's keyboard shortcuts in KDE4? THEY ARE REALLY BAD I think! Space - next image Backspace - prev image I never had to look into the menu or shortcut editor before to find out how to navigate through pictures :-) It always has been PgUp / PgDown or maybe even ArrowLeft / ArrowRight, but the default in Gwenview is really weird, at least for me. You have to move the hand to get this shortcut combination work. Or you have to use the thumb for space and the little finger for backspace, but this is too acrobatic for me :-) Ok, but what should *we* do? Personally I tend to apply the patch given here and try to solve the PageUp/PageDown issue for the icon view (bug 141730). #12 Space/Backspace is traditional navigation through items in Unix based tools. PgUp/PgDn is MS thing (maybe also Apple). OK, why arrows cannot work as "panners"? Look, when we have schema in Album View: PgUp/PgDown navigates by viewports, Arrows are going through individual items this same idea is going in Preview Mode. PgUp/PageDown goes to prev/next item and Arrows are navigating in current item by panning image - as were navigating in current screen in Album View. The same should be applied in IE. Andi, Can you resume there ? This file is solved with current code from svn ? Gilles Caulier Somehow the behavior is still weird in current SVN. Display an image (F3) and press LEFT or right. You'll notice that the thumbnails are selected in the thumbbar, but the preview image doesn't change. You need to press LEFT or RIGHT and ENTER to make it work. This can't be right? Yes I confirm. The reason is probably that the thumbbar shares 90% of its code with the main icon view, which is multi-selection and has "activation" separated from "selection". I think we need to emit imageActivated(ImageInfo) in ImageThumbnailBar reacting to a changed current item already. > Somehow the behavior is still weird in current SVN.
> Display an image (F3) and press LEFT or right. You'll notice that the
> thumbnails are selected in the thumbbar, but the preview image doesn't
> change. You need to press LEFT or RIGHT and ENTER to make it work. This
> can't be right?
This is fixed by now.
There is no doubt that the arrow keys pan when zoomed in, and page up/down
switch the image in preview view.
One question remains: should left/right arrows switch the image in preview
view when the image is not zoomed (fit-to-window)?
Aron, this file still valid using digiKam 2.4 ? Gilles Caulier Aron, I cannot reproduce the problem with current implementation form git/master. Just take a care to have mouse focus on thumbnail bar with preview mode. You can switch between image with left/right keys. To prevent to take focus on thumbbar, i think that imageActivated() signal must be fired as Marcel said in #19... Gilles Caulier This file still valid using last 2.6.0 release ? Gilles Caulier As explained in previous comment current behavior using git/master implementation work perfectly. Gilles Caulier |