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 530447 - Eye of GNOME opens images resized at 98% or 99% zoom
Eye of GNOME opens images resized at 98% or 99% zoom
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: image viewer
2.22.x
Other All
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 551370 554446 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-28 21:20 UTC by demetris
Modified: 2008-10-08 19:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description demetris 2008-04-28 21:20:31 UTC
Please describe the problem:
Images which there is ample desktop space to display at 100% are opened by eog at 99% or, less often, at 98%.  I cannot seem to detect a pattern for this in the image dimensions:

  360  x  240  >  opens at 100%
  450  x  338  >  opens at  98%
  363  x  450  >  opens at  99%
  500  x  748  >  opens at  99%
  500  x 1030  >  opens at 100%
 1280  x 1024  >  opens at 100%

I'm seeing this in two Ubuntu 8.04 installations:

 1. 32bit, screen resolution 1600x1200.
 2. 64bit, screen resolution 1280x800.

When the Image Collection panel is turned on (View, Image Collection), images are displayed at 100% zoom, provided there is sufficient desktop space.

Steps to reproduce:
1. In Nautilus, open a directory with images,
2. Select an image, hit Enter to view in Eye of GNOME,
3. Hit Alt+F4 to close Eye of GNOME,
4. Repeat a few times, trying to select images small enough that can be displayed at 100% zoom on your desktop.

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Felix Riemann 2008-04-30 11:23:08 UTC
Confirming this on a 1280x1024 display.
Comment 2 Felix Riemann 2008-04-30 11:56:46 UTC
hmm, the problem seems to be that the image viewing widget return wrong/silly allocation values when the collection is hidden on startup:

Without collection:
ImageW: 450 - H: 338
ViewW: 1 - H: 1
WindowW: 341 - H: 103
ScreenW: 1280 - H: 1024
DecoW: 340 - H: 102
FinalW: 790 - H: 440

With collection:
ImageW: 450 - H: 338
ViewW: 202 - H: 100
WindowW: 341 - H: 207
ScreenW: 1280 - H: 1024
DecoW: 139 - H: 107
FinalW: 589 - H: 445


Generally the window width is always enough, we're missing height in the problematic cases.

Btw, the "360  x  240  >  opens at 100%" case works, because the resulting window height is below our minimum window height of 350px (so you get a larger window than needed).
Comment 3 garnettxd 2008-06-10 14:55:21 UTC
hope someone can fix this.
Comment 4 Andreas Moog 2008-09-06 23:24:12 UTC
Hi! Is there any news on this issue? Thanks.
Comment 5 Claudio Saavedra 2008-09-08 13:50:08 UTC
*** Bug 551370 has been marked as a duplicate of this bug. ***
Comment 6 Felix Riemann 2008-10-06 11:42:07 UTC
(In reply to comment #4)
> Hi! Is there any news on this issue? Thanks.
> 

Unfortunately not. The size allocation of the image viewing widget is not correct during this phase of the window initialization and couldn't find the reason for it yet.
Comment 7 Felix Riemann 2008-10-08 19:02:55 UTC
Okay, looks like I got it. :-)
When the collection is hidden the image viewing widget was realized earlier which at this stage broke its allocation. I changed that in SVN now (it will make it into 2.24.1) and all the test images opened correctly.

2008-10-08  Felix Riemann  <>

	* src/eog-window.c: (eog_window_cmd_show_hide_bar): Avoid realizing
	the scrollview too early as that would break its allocation when the
	collection is hidden. Fixes bug #530447.
--------------------------------------------------------------------------------
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 8 Felix Riemann 2008-10-08 19:10:13 UTC
*** Bug 554446 has been marked as a duplicate of this bug. ***
Comment 9 demetris 2008-10-08 19:19:29 UTC
Thank you!