XnView Software

daisensou wrote:

thibaud wrote:would it not occur to any of you that the texfield content plays a major role here...
none of the screenshots shows a usability issue (path cropped).
I don't see no problems.

The pathfield does not expand to fit a bigger path, at least, it never did expand in all my tests.

The issue is wasted space, such a small text field is 'useless'. If you re-size the XnView window so it uses 2-rows instead, you will see the pathfield expand or contract accordingly. That one should be the expected behavior.

But this is such an elusive problem, that I truly don't know what else to do. Pierre can't replicate it, yet it always happens to me, doesn't matter the OS I use. This weekend I may get my hands on a Mac and I'll try to run some tests there too.

Let us see:

You see this:
...and Pierre sees this:
Isn't it?


...and this is because, as you tried to explain here, it depends on how XnViewMP is started.

I can reproduce this in 100% from cases, just be sure to have the path long enough to get out from the address field!

If XnView MP is started by double-clicking on the icon, then the address field is wide.
If XnView MP is started by right-clicking on a folder and choosing "Browse with XnView MP", then the address field is narrow.

Pierre, perhaps you do some custom processing with the width of the address field when a file / folder is passed as a command line argument?

m.Th. wrote: Let us see:

You see this:

Address Bar - Small.jpg

...and Pierre sees this:

Address Bar - Large.jpg

Isn't it?


...and this is because, as you tried to explain here, it depends on how XnViewMP is started.

I can reproduce this in 100% from cases, just be sure to have the path long enough to get out from the address field!

If XnView MP is started by double-clicking on the icon, then the address field is wide.
If XnView MP is started by right-clicking on a folder and choosing "Browse with XnView MP", then the address field is narrow.

Pierre, perhaps you do some custom processing with the width of the address field when a file / folder is passed as a command line argument?

YEAH!

But, as you can read in the next update, it stopped having any effect after a while (on Windows 7).

Anyway, here are 2 new captures, in Windows 8.1:

-Started from .EXE, opened the desktop as default location (short path), then navigated to a test directory (long path). Went back to the Desktop, closed then reopened XnViewMP, the pathfield was wider, but not as wide as your example


-Started from .EXE, following your advice, opened the last used directory as default (very long path), now the pathfield expands accordingly and this 'setting' seems to have sticked now


Aww yiss
Thanks for the long path info, I guess I always ran into problems, as I set XnView to always start on D:\ root (my data drive), setting it to start at the last used directory (desktop and test path) really made all the difference.

In the case of the Windows 7 machine, it was really odd, as the tests stopped yielding different results, even after cleaning all profiles and starting from zero. Will see if I can get my hands on another 7 machine and try to replicate it.


EDIT:
Starting from file (then going from Viewer to the Browser), will have the same effect as using the shell context menu integration, the pathfield will be narrow.

Bug confirmed and will be fixed. See issue Issue 159 for current status and details