0.53: The width of the foldername field

[BlackWinny]

Hello everybody


I haven't found a way to get wider the foldername field (placed at left of the "favorites" star in the tool bar). This foldername is very, very, very narrow...

See this picture (I haven't been able to upload an attachment below the writing field of the forum) :




So... Is there a way to get it wider ?


Thanks !

[helmut]

... So... Is there a way to get it wider ?

Width of the path field is calculated automatically, there's no way to set this manually. I've resized the main window and tried to reproduce your screen situation, but without success: Both path field and Zoom slider resized properly, no empty space like in your example.

Perhaps this problem is Windows 7 specific. Or the problem occurs in combination with another setting, only. Could somebody else please try to reproduce the problem?

[oops66]

Perhaps this problem is Windows 7 specific. Or the problem occurs in combination with another setting, only. Could somebody else please try to reproduce the problem?

Hello, maybe the first step is to rename the "xnview.ini" file (or reinstall XnviewMp) to have the default xnview setting, and see if this bug occurs again... FI: I do not have this problem with the linux version v0.51

[helmut]

Hello, maybe the first step is to rename the "xnview.ini" file (or reinstall XnviewMp) to have the default xnview setting, and see if this bug occurs again...

Thanks, oops66, for posting your experience in this matter. Renaming "xnview.ini" and thus trying with standard configuration is a very good idea.

[BlackWinny]

Hello everyone


First, thanks for your answers.

Curiously the problem apprears to be sporadic. Without any change in my actions nor in the technical context. It comes... and goes for several launches... and comes back once... and goes again for some launches... and comes back...

I have tried the excellent idea of oops66 after I've read it. Result : the same behavior.

I have also tried to change the resolution of my Windows screen, changing it from modes to modes (1280x1024, 1024x768, 800x600...) each time for some hours to see how the executable reorganizes the elements. Result : the same behavior.

The problem beeing intermittent, I really feel sure that something in the code of the program seems very sensible to... something in the internal behavior of Windows 64 bits. Perhaps (and probably) a bug which is not in XnViewMP itself but rather in a DLL of Windows 64 bits or in its management of the graphic memory.

My opinion is that we must keep this strange phenomenon in memory... but I think we may avoid to spend time on it for the moment, especially as there is only one alert not yet reproduced elsewhere. The important thing is for us to keep it in a cell of mind.

Don't you think so ?

[helmut]

Thanks, BlackWinny, for your testing with and without .ini file and analysis. Sporadic problems are the worst to track down and solve. Would be very good if we could find steps to reproduce the problem. But I agree: Keeping this problem in memory and keeping an eye on it while working with XnView MP is adequate.

[xnview]

Strange, i have windows 7 x64 too, and no problem, the field is large. If you maximize the window, same thing?

[BlackWinny]

Hello Pierre

Yes, same thing when maximizing the window.

Strange also... the fact that it occurs sporadically. And I haven't yet found any common point to the occurences. I keep my attention on...

[daisensou]

Windows 7 64bit here, same behavior with the 0.61 version. Tried fresh settings + customized layout for screenshot purposes (nothing carried over from the old versions), running with the Wizard default settings doesn't make any difference.

I don't have the exact number, but around 780px (browsing area, not counting the scroll bars), if you use XnviewMP within this limit, the Filelist toolbar will always use 2 rows (Path and Quick Search field on top, icons and Zoom sliders below). Resizing beyond the 780px limit, will make XnviewMP use only 1 row for the Filelist toolbar, that'll lock the Path and Quick Search fields width.

Within the limit:



Beyond the limit (maximized window will also have the same issue):



EDIT:
Same problem under Ubuntu (running under VirtualBox)

[xnview]

I can't reproduce

[daisensou]

Odd.

Ran a few more tests and this caught my eye:

On Windows, if I run the xnview.exe file 'directly' or use the context menu (shell integration "PATHTO\XnViewMP\xnview.exe "%1"" or custom method like "PATHTO\XnViewMP\xnview.exe "%V"" - see EDIT > http://newsgroup.xnview.com/viewtopic.php?f=34&t=22890) will make the Path field behave differently! -- EDIT: By "directly", I mean running only the XnViewMP application, without passing a file or folder as secondary parameter, so it opens at the chosen default path or last used path.

- Running the .exe directly = Path Field will occupy a width of around ~320px (will not resize beyond that, is this the expected behavior?)
- Running XnViewMP through the Context Menu shell integration (or example below) = Path Field will occupy a locked width of around ~130px (see images I posted before)

The same problem will also occur if you manually point the .exe to a file, i.e. PATHTO\XnViewMP\xnview.exe D:\Image.jpg
That will open the image in the Viewer and once you go to File > Browse, the Browse window will also have the Path Field in that small, locked width.

A temporary fix is to change themes, changing the theme will make the Path Field resize! It's only temporary, once you close XnViewMP and reopen it through the Context Menu, the problem will be back. See image (top= changed the theme; bottom= ran the .exe directly:



That may be what we were doing differently? Otherwise, I really can't see what else could be affecting this behavior.


Ah, on the other hand, the problem persists on my tests using the other platforms:

Running Mac Snow Leopard OR Ubuntu 12.04 on Virtual Box, the results are the same as I described before. Nothing I do here (changing layout or theme) changes the Path field behavior. Once the XnViewMP changes from 2 rows to 1 row to display the Filelist toolbar, the path field width gets locked in that small width.



EDIT:
Aaaaaaaaaaaaaaaaaaaaaaaahhhh..... well, further tests do not yield different results anymore. Now it only display that narrow Path Field when in single row mode. Already tried resetting all settings and starting clean... Dang, what an elusive problem.


EDIT2:
I give up.
Ended using the this code on View > Theme > Dark Theme to make sure the Path Field expands to use more space:

Code: Select all

QComboBox{
	height: 18px;
	width: 800px;
 }

SearchLineEdit{
	height: 16px;
}

SearchLineEdit>QLineEdit{
	height: 16px;
	margin-bottom: 2px;
}

[xnview]

I'm unable to have this

[daisensou]

I don't have access anymore to my Windows 7 machine, got a notebook here from my sister, vanilla Windows 8.1. Grabbed a copy of 0.61 x64 and the problem still pops up to me:



It's really an odd issue.

[thibaud]

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.

[daisensou]

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.