Re: default image zoom



Hi Mike,

> > [...]
> > Ok, I think I could reproduce the behaviour. It will work if your image is
> > large enough (in kbytes) to switch to progressive image loading. This is
> > used for images > 1MB. If your image size is smaller it is loaded in one
> > run.  In this case the image size detection is broken. This is definetly a
> > bug.
> > 
> Fantastic!  I've just upgraded to 2.3.3 and I don't see this problem any more.
> Great work guys, thanks!

the odd thing is, I didn't had time to fix it yet. It seems there is a
race conditions somewhere in the code, which lets it sometimes work,
sometimes not :-/. 

> > [...]
> > Eog looks for your visible screen size and scales the image so that it's
> > dimension is maximal 75% of your screen size (for both axes). Eg. for 
> > an 1024x768 pixel image this will result in an zoom factor of 58% 
> > if the screen has a resolution of 800x600 pixel.
> > 
> I'm seeing large images (which don't fit) being scaled down to a tiny size
> well below 75% of the available screen area.  I can't tell exactly why yet.
> 
> There is also a little oddness with some images I have which should fit
> normally on the screen, but for reasons that I can't determine, are scaled
> down.

See above. 

> > What is the use case for this? I mean, if you start in image viewer 
> > to view an image, I suppose you want to see it completely. 
> > 
> My biggest use case is weather maps, which you can find at weather.noaa.gov.
> These things are quite large, and when you are viewing them, you want to see
> the whole thing, as large as it will go (and sometimes larger to see if a
> wind speed is really 40 knots, or if it is really two 20 knots overlapping
> each other).  Generally, I'll download more than one (high altitude winds,
> low altitude, sea state, and 24, 48, and 72 hour predictions of each), using
> a script, and then view them.
> 
> Full screen mode (F11) doesn't cut it because the scroll bars disappear, and
> the image is only scaled to fit (and ctl-= no longer works).  In fact, with
> some of my smaller images (non-weather), they get scaled up!

Hm. Simple '+' and '-' keys should work. This isn't very consistent, needs
fixing :-/. The default in FullScreen mode is to always fit the image to
the screen, even if the zoom is > 100%. There is a not functional option
in the preferences, which eventually will force the zoom to the range of
1-100%. [Patches appreciated]
 
> As far as window size goes, it seems to me to be a policy that should be
> determined by the window manager.  75% seems like a decent size, but I'd like
> to argue that if you are going to hard code a policy like this into a
> program, then you should give the user the option of setting the value
> including the option of being able to deactivate it.

The problem: The WM does not know anything about the content you are
viewing. If you open an empty eog window, the window manager will assign
it the smallest size possible (which is in this case _very_ small). If you
then open a large image the window wont' increase automatically. This is
left to the user, which is in this special case (image viewing) IMO not
required, because you can assume that the user want to see the whole
image. 

I am not totally convinced that putting more options for controlling the
window size policy is a good or necessary step. Eg. if you open your
wether maps, displaying only the top left quarter of your whole picture
and are looking for more detailed information in a certain region you must
scroll through it. If you first get the whole image presented, you get an
overview. Then zoom into the region (eg. with the scroll wheel of your
mouse) putting the mouse cursor at the position you are interested in.
IMHO this way you can access the details of the map more easily, whithout
scrolling through the image, not knowing where you exactly are.

> I can sympathize with you about feature bloat, sometimes it seems that the
> worst thing about open source is that good programs never reach the point
> where they have fully matured; there is always some guy out there, like me,
> who wants a new feature that perhaps no one else will ever use.

See below.

> [...]
> but what I'd really like is a feature more like the GIMP's which lets you
> assign the hot keys yourself...

Such feature should be handled in a general framework on gtk or gnome
level.

> Don't get me wrong, I love EOG!  At least it has scrollbars, and navigable
> controls, unlike xv.  Keep up the good work!

Don't get _me_ wrong. I love to get your input. People developing stuff,
don't know always how their software is used in real life and what
features may be missing in a certain use case. So I want to encourage you
and others, to report bugs and feature requests to bugzilla. Even if it is
obvious to you, that something needs fixing, it may not obvious to us
developers. Though, I can't promise that everything will be integrated
into eog :).

Regards,

   Jens




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]