Bug 291759

I second the request. Keeping the zoom between images was a very useful feature in order to compare two images in detail by switching back and forth between them.

I am a bit torn here: Both behaviors have pros and cons, maybe an option is in order indeed. I am going to see if I can revert the change in 4.8.x, the change is a side effect of the refactoring, it shouldn't have happened.

Thanks for the effort. A (side) problem with changing zoom level is that it takes time. So while I wouldn't mind the option, retaining the zoom would be a better default IMHO.

What I also noticed now that I need to switch by hand (correct me if I remember the behavior from 4.7): when changing to 100% with a middle mouse click, the zoomed view is not centered on where I made the click, but instead is centered on the centre of the image.

*** Bug 294915 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

Created attachment 70838 [details]
Reverts zoom/position behavior while changing image  to 4.7

For info, gwenview's behavior changed at commit a75186 "Simplify DocumentPanel::openUrls". Before commit, gwenview used to recycled existing unused views to display new urls. After commit, it destroys and creates new views.

I plainly see the PROs of the old behavior, especially when considering different processings of the same image (smoothing, interpolation, color adjustment, whatever).

I have attached a patch that restores the old behavior, though i'm not sure at all it's the correct way to handle the case.

Could keeping framing be decided by the fact the "Fit" button was pressed or not ?

The patch i've posted is against v4.8.1

Created attachment 70840 [details]
image is squeezed

Your patch works, but I get the following side effect:
When I jump fast from image to image, the current image gets squeezed at the moment i press the next button (on keyboard), until the next image is fully loaded. See attached png.

Benni,

Unfortunately, I cannot do much for this: I've just restored the old way gwenview recycled its views, but there is nothing in the code I've touched that explicitly deals with zoom and framing - nor with aspect ratio. The result is somehow a side effect of not deleting the view, and thus re-using some of its previous settings. Which ones actually ? I don't know. That's just how it used to work, but things have evolved since that time. 

As I've previously said, I'm far from believing that patch is the correct way to deal with the case... The commit I've reverted seems sane at the first place, and cleaner than the previous code. In other words, it looks like a good change, that just happened to inflict co-lateral damage. I use the patch myself - i could not live without a common zoom - but I've posted it mainly in the hope it would help someone else to find a real solution.

*** Bug 293439 has been marked as a duplicate of this bug. ***

I've added a patch to https://bugs.kde.org/show_bug.cgi?id=293103#c7 to fix this problem in a clean way.  It seems to work in most situations, although going backwards (using <BACKSPACE>) does not seem to work correctly if the image has been discarded.

*** Bug 293103 has been marked as a duplicate of this bug. ***

I am going to integrate John Zaitseff patch ( https://bugs.kde.org/show_bug.cgi?id=293103#c7 ) and see if we can polish the remaining issues before 4.9.

Fix has been committed to master.

Many thanks, Aurelien, for fixing this issue!  I very much appreciate that you did so!

Git commit d212ad8dbfa3d4fa6e4a639172d2030c4cfccfee by Aurélien Gâteau.
Committed on 27/06/2012 at 22:48.
Pushed by gateau into branch 'KDE/4.9'.

Make "lock zoom" feature optional

Having used Gwenview with the lock zoom feature back in. I realize it
is a useful feature, but strongly believes should not be enabled by default.

This commit reverts to not locking zoom by default, but introduces an
hidden config option which can be set with:

kwriteconfig --file gwenviewrc --group ImageView \
  --key ShowLockZoomButton --type bool true

When this is set, a lock button appears on the right of the zoom level.
Clicking it will lock zoom, clicking it again will unlock zoom.

I want to find a better solution for this in KDE SC 4.10: I don't like how
the lock button adds clutter to the already cluttered, zoom widgetry, but
this should do for KDE SC 4.9.

M  +23   -1    app/viewmainpage.cpp
M  +1    -0    app/viewmainpage.h
M  +10   -0    lib/gwenviewconfig.kcfg

http://commits.kde.org/gwenview/d212ad8dbfa3d4fa6e4a639172d2030c4cfccfee

It's a shame this fixed wasn't backported to 2.8.4 :(

*** Bug 308334 has been marked as a duplicate of this bug. ***

*** Bug 215734 has been marked as a duplicate of this bug. ***

I tried this but it seems  i dont have the correct version of gwenview.

kwriteconfig --file gwenviewrc --group ImageView \ --key ShowLockZoomButton --type bool true

My version is: 4:4.8.4-2

I work with a lot of images and to compare then i need to have same zoom.

I need to see the same to select witch is best.

What can i do?

For the people that needs that fixed very fast I have found other application that has that funtionalty: Geeqie

(In reply to comment #21)
> What can i do?

If you don't want to upgrade your distro you could try to build gwenview yourself. I would try version 4.9.3 because it has less depencies than 4.10.x:
http://download.kde.org/stable/4.9.3/src/gwenview-4.9.3.tar.xz

It seems like zoom lock button is present and works in windowed mode only but it doesn't work in full screen mode. If I am not missing any other hidden button or config option then this bug/feature request cannot be assumed as completely fixed. That is because old Gwenview versions had zoom lock feature in full screen mode.

(In reply to comment #17)

> I want to find a better solution for this in KDE SC 4.10: I don't like how
> the lock button adds clutter to the already cluttered, zoom widgetry, but
> this should do for KDE SC 4.9.

As a user story...  I use the application to check proofs of images.   I've probibly use it to select best images out of several thousand for my macro photography work.   So for example I may take a burst of 40 images of some bug, or whatever, and want to determine which is the sharpest.   Zooming in and scrubbing through the images leaving the zoom level, and the relative view intact made this a 10 second mission.  Then it became useless for this purpose, painful in fact.

The OLD version did not require an insipid lock button, and it was very much implied and intuitive that the zoom level stayed fixed.   The 100% button is already on screen.   So the old solution was superior in terms of UI clarity and simplicity.

This is one of the distinguishing features of your image viewer ( well, it is again ) and it should not be a double secret hidden feature that end users need to poke to use.   There is no need for tainting the UI with more buttons.   Make it work the way it did previously, and if the user is an imbecile, then so be it.

Most commenters see the old behavior of maintaining zoom as a useful default option.
User experience wise I see this as NOT fixed, because
a) it is not the default and it's non-obvious to find and configure the required ShowLockZoomButton option and
b) it's incomplete because, as said in comment #24, the zoom lock button has no effect in full screen mode.

How many users will get to the ShowLockZoomButton "hidden configuration option", which can be found when following a link in a "Tipps" section of the gwenview manual page?
Thus most users are will not have locked zoom and position, which is a real nuisance when going through a series of  similar images.
(In reply to comment #25)
>  So the old solution was superior in terms of UI clarity and simplicity.
I would second that.

I would appreciate if this would be reopened (I cannot).

*** Bug 193885 has been marked as a duplicate of this bug. ***

*** Bug 327889 has been marked as a duplicate of this bug. ***

I sbmitted related bug #334530 "gwenview lock zoom button does not work in fullscreen"