After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 311297 - Zoom setting should be global not per image. Remember Zoom.
Zoom setting should be global not per image. Remember Zoom.
Status: RESOLVED OBSOLETE
Product: eog
Classification: Core
Component: collection
3.4.x
Other All
: Low enhancement
: ---
Assigned To: EOG Maintainers
EOG Maintainers
eog-plugin
: 579437 582300 655158 792700 794671 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-07-22 19:55 UTC by Alan Horkan
Modified: 2021-06-19 08:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds options to toggle remembered zoom level. If on zoom stays the same (after user input) when hitting next/prev (61.60 KB, patch)
2011-03-03 23:04 UTC, Ian Hands
rejected Details | Review

Description Alan Horkan 2005-07-22 19:55:47 UTC
I think it would be an improvement if Eog remembered the zoom setting. 

So I choose 50% or Fit Width it stays that way until until I switch back.  

The current behaviour requires changing the zoom for every image which quickly
becomes annoying if you want to view a collection of images that
are too large to fit onscreen and you have to hit Zoom ever time.  

Having a keybinding for Zoom Normal makes it very easy to switch back so keeping
I dont think there is much of a downside to keeping the last used Zoom setting.

GQView has a setting for Remember this but I encourage you to try it out and
consider making it the default for EOG.
Comment 1 Teppo Turtiainen 2006-03-27 18:58:11 UTC
Bug 315413 is a feature request for the exact opposite of this.
Comment 2 Andrew Conkling 2006-04-15 14:57:54 UTC
Both requests are for EOG to remember the settings, albeit different ones.

In this case, it seems like the question is to avoid seeing pictures that are zoomed in more than the screen can show.  Maybe it could be implemented to show pictures at 100% or screen size, whichever is less?  And when the user zooms out, the zoom setting could be remembered across images, but if he zooms in, the next image would be loaded at the available maximum.

This seems closer to doing the Right Thing.
Comment 3 Leandro Nunes 2007-04-25 12:00:29 UTC
Hy gnome's time,

hy gnome's time,    I'm new in the gnome's world but I'm interesting to fix this bug. I tried to solve it but I had some difficulty that I think you can help me.

My solution to this problem it's to pass the zoom definition of the old image to the new image chosen. Is it correct?

If it's a good solution i have a doubt. 

The zoom is defined at the context of eog-scroll-view as private, so if I had a EogScrollView class I can change the zoom easily.    

But when we choose a new image, it's defined at the context eog-thumb-view, more specifically at eog_thumb_view_select_single. At this context we don't have a EogScrollView class because the next, prev, first and last buttons always pass  EOG_THUMB_VIEW (priv->thumbview) by the method  eog_thumb_view_select_single and not EOG_SCROLL_VIEW (priv->view).

In EOG_SCROLL_VIEW I have the zoom definition but in the EOG_THUMB_VIEW no.

It's anything stupid?

Can you indicated any read?

Sorry about the bad english!!!
Comment 4 Marcus Dapp 2008-07-15 20:34:24 UTC
I v2.22.2 the default behaviour in full-screen mode is that every next image is shown in screen-fit size.

Suggestion:

A tick box saying "[X] Remember last zoom setting in full-screen view." in the preferences would be simple and clear and allow for the two main needs:
- see every next image in screen-fit mode.
- see every next image in the zoom-size the user set during the last image.

Could that be done?


(see also the discussion on eog mailing list on 15-07-2008, "When a photographer uses eog")
Comment 5 Felix Riemann 2009-04-24 12:47:36 UTC
*** Bug 579437 has been marked as a duplicate of this bug. ***
Comment 6 Ian Hands 2011-03-03 23:04:22 UTC
Created attachment 182417 [details] [review]
Adds options to toggle remembered zoom level. If on zoom stays the same (after user input) when hitting next/prev

This should resolve the bug.
Comment 7 Ian Hands 2011-03-03 23:07:00 UTC
I used glade to edit the /data/eog-preferences-dialog.ui xml file (to add the menu items). It seems to have changed the formatting (white space and comments) of the file a bit.

I would not mind going through the xml and manually bringing over the additional elements if the patch is deemed messy. Please let me know whether I should.
Comment 8 Felix Riemann 2011-06-11 07:38:26 UTC
Review of attachment 182417 [details] [review]:

Hey Ian,
unfortunately we don't use GConf anymore in eog.
Version 2.28 isn't really a safe starting point for development anymore, especially since the 3.0 release (but I remember reading you use RHEL so I can understand why you chose it).

Also, I think the functionality shouldn't live in EogWindow but in EogScrollView which is actually responsible for displaying the image.
Comment 9 Felix Riemann 2011-07-23 09:36:22 UTC
*** Bug 655158 has been marked as a duplicate of this bug. ***
Comment 10 Federico Mena Quintero 2012-01-24 23:24:59 UTC
Adding Máirín Duffy to the CC list.

This bug discusses having a "sticky zoom" setting, where the current zoom factor is preserved across image changes.

The mailing list thread referenced in comment #4 is http://mail.gnome.org/archives/eog-list/2008-July/msg00001.html and point (3) in there is for the same feature.

I started implementing this in eog-scroll-view.c, as Felix suggests; then I realized the following:

1. Implementing "zoom stays the same across image changes" is easy enough.  To make it good for comparing images, the current relative scrolling offset should also stay the same; this is also easy to do.

2. This, however, is not quite what Máirín wants.  She wants to use EOG to browse folders of GUI mockups at 1:1 scale, so what she really needs is a "make each image change go back to a certain zoom factor", in particular 1:1, not "preserve the zoom factor (whatever it is) during an image change".

Having a "sticky zoom" toggle as in (1) is easy enough.  How could we go about implementing (2) as well, without starting to have too many options for controlling the zoom?  Maybe a "-1" command line option for her specific use case, or some plugin that makes EOG go back to 1:1 on image changes?
Comment 11 Tobias Wolf 2012-03-30 20:47:48 UTC
Please just finish this. I’m seeing myself using Chromi tabs for image comparison more and more often.
Comment 12 mahfiaz 2012-07-28 00:19:50 UTC
There is a duplicate bug which describes the most common use case well. https://bugzilla.gnome.org/show_bug.cgi?id=582300
Comment 13 nodiscc 2012-07-28 13:48:10 UTC
*** Bug 582300 has been marked as a duplicate of this bug. ***
Comment 14 Dmitri 2016-12-20 13:54:39 UTC
I was about to file new bug for this, and noticed this 11 years old ticket.

We now have a CtrL+Shift+0 shortcut that fits the image width inside the window width (not sure since when), it's labeled "shrink the image" and has a "1" icon in full screen view.

When you are working with web design, and want to showcase many long pages, this automatic zoom is a life saver.

However, when you go to next/previous image you lose the zoom, so you have to press your "CTRL+SHIFT+1" shortcut again... not very cool when you are doing your live client presentation, specialy since you go back and forth every time discussing every page and capturing feedback.

So making the "CtrL+Shift+0" a "toggle button" that persists state between two images instead of a stateless "button", seems like an obvious choice, and a great UX improvement for everyone working with web designs.

It might be a "small UX enhancement" but for majority of users this kind of small details make people love or hate their desktop environment (and programs preinstalled by default)...
Comment 15 Felix Riemann 2018-04-04 13:53:00 UTC
*** Bug 792700 has been marked as a duplicate of this bug. ***
Comment 16 Felix Riemann 2018-04-04 13:53:27 UTC
*** Bug 794671 has been marked as a duplicate of this bug. ***
Comment 17 André Klapper 2021-06-19 08:46:55 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/eog/-/issues/

Thank you for your understanding and your help.