XnView Software

Here my personal wishlist of minor changes that make imo xnview even
better usable than it already is.

1) Possibility to optionally suppress the scrollbar in non-fullscreen mode
wben picture is larger than window?
(Preferred inside-window navigation method in this case should be the
arrow keys).
-> When heavily browsing, due to the scrollbar paint operations
the behaviour appears less speedier as for instance acdsee
(which truncats the invisible part of the window in that case)

For me very important:
2) Make the option "Fit image to desktop, all" to work like
acdsee: (x) change window size zo fit image
auto image size: (x) zoom to fit window/screen // or similar
Actually it does not really stretch small picutres, but paints a big grey
frame araound them.

3) Option for viewer mode: space bar acts for "get next file"
(maybe already committed?)

4) Size changes of the viewer window should never affect the browser
windows size (width. height)
(as of now you have carefully to set the correct options for not to see
the browser windows size 'corrupted' after wiewer operations)

5) Imo the browser layout # 3 (preview panel beyond the directory tree)
should be the default layout (more efficient, less usage of wasted space)

6) Stop XnView connecting to the Internet when it encounters an .url file
(eg. in XnView program folder) in thumbnail mode

7) (Remark:)
Saw some threads about speed issues in comparision with acdsee.
I had the same problem (viewer mode, heavily pressing pgdown
for next picture; saw cascades of repaint operations on the window
frames [und obviously much disk operations, at least as my ears tel
l me ..]),
Then i tested with "read an image ahead" -> switched to "off"
(generally cache stays enabled)
- ... and wow!
So the question: did i miss any reasonable benefit from
to set this option to "on"?
For me it appears to be more or less a speed killer.

merci beaucoup and best wishes!

Context: XnView 1.80.1, Windows 98 SE

Anonymous wrote:1) Possibility to optionally suppress the scrollbar in non-fullscreen mode
wben picture is larger than window?
(Preferred inside-window navigation method in this case should be the
arrow keys).
-> When heavily browsing, due to the scrollbar paint operations
the behaviour appears less speedier as for instance acdsee
(which truncats the invisible part of the window in that case)

Ok i'll add it

For me very important:
2) Make the option "Fit image to desktop, all" to work like
acdsee: (x) change window size zo fit image
auto image size: (x) zoom to fit window/screen // or similar
Actually it does not really stretch small picutres, but paints a big grey
frame araound them.

Why? There is a minimum size for XnView..

3) Option for viewer mode: space bar acts for "get next file"
(maybe already committed?)

I'll add an option

4) Size changes of the viewer window should never affect the browser
windows size (width. height)
(as of now you have carefully to set the correct options for not to see
the browser windows size 'corrupted' after wiewer operations)

You have option/General/Use different size

5) Imo the browser layout # 3 (preview panel beyond the directory tree)
should be the default layout (more efficient, less usage of wasted space)

Not for all users

6) Stop XnView connecting to the Internet when it encounters an .url file
(eg. in XnView program folder) in thumbnail mode

I'll add an option

7) (Remark:)
Saw some threads about speed issues in comparision with acdsee.
I had the same problem (viewer mode, heavily pressing pgdown
for next picture; saw cascades of repaint operations on the window
frames [und obviously much disk operations, at least as my ears tel
l me ..]),
Then i tested with "read an image ahead" -> switched to "off"
(generally cache stays enabled)
- ... and wow!
So the question: did i miss any reasonable benefit from
to set this option to "on"?
For me it appears to be more or less a speed killer.

I don't understand, when cache option is off, speed is better?

Hello Pierre,

many thanks for reply and the options you agreed!

- Unexpected size changes of the browser ...
You have option/General/Use different size
-> yes, and i'm careful that it is ever "on" ... however playing around with
diverse view and autosize modes to be applied to the viewer, oftenly my
browser window was left in strange positions afterwards.
(sorry, i had the impression it is a kwnon problem;
obviously i need to find a reproducable test case for that)

- layout # 3 .. not best for all users -> ok (sigh)

- Performance boost by read one image ahead = "off"
Yes! Browser>>Cache>>Enable caching is "on"
View>>File list>> read one image ahead is "off",
keep current image in cache is "off"
The effect is as follows: if i iterate in the viewer quickly
from file to file by constantly pressing PgDown, the speed appears
to me to be very fast (although i don't habe a power machine .. 650Mhz)
when using "read one image ahead = off".
But if i set it to "on" (which is obviously the default value)
i notice a lot of paint actions on windows frames (i see
2, 3, 4 .. window frames being painted / invalidated .. at the same time).
My impression is that the read-forward action is blocking a quick response.
(I saw some similar findings in this forum)

- "Fit image to desktop, all", grey frame
Why? There is a minimum size for XnView..
--> ? I don't understand.
The effect is that the viewer window is stretcehd to desktop, but not
the image herein. I would have expected that the image zooms out to
the windows size too .. as acdsee does.
Is it possible to enlarge the iamge accordingly to the enlarged window?

I tried various settings to achieve the following, but i didn't succeed:
using: "Fit image to desktop, all"
- or -
"Fit image to window heignt" (! just trying that, i again notice the
corrupted browswer window's size, no: the corruption of the
positions of the inner child windows; how i can i send you a screenshot?
I think this is a bug)
I would expect that the height of an image is enlarged to fit the
windows height. And the width of the windows is calculated accordingly,
to be large enough (or small enough) that the image exactly may fit herein.
Is that possible?

A friendly guest

4. I have some similar problems, but when I restart xnview I can't reproduce it again. There is also a known bug with maximized xnview. Please start new topic for this problem.

5. I agree with "Guest", I think there was several similar suggestions in test forum, maybe we should start a poll...

Dreamer wrote:5. I agree with "Guest", I think there was several similar suggestions in test forum, maybe we should start a poll...

I also used the layout #3 (preview panel below the directory tree), and found it extremely efficient.
(I don't use preview anymore for my photos, but large thumbnails instead, thanks to a suggestion by ch3n3... )

Olivier