To reproduce:
=rename any picture file to a long filename (I used 45 characters on a .png)
=launch the file in XnView MP (not by drag n drop) I used a separate 'open with' program- 'shelltoys choose program'
=You will notice the tab width stretches, upon file opening, to the full size of the filename but it only does this briefly
Actually in my tests this issue does not occur with drag 'n' drop of files onto so the interface. Also issue happened with an 8 character filename too as I thought it only did this with long filenames. So MP needs to read the tab width setting first before reading the filename+tab thumb, otherwise just copy the code that respects the tab width rightly when drag 'n' drop of file to interface.
-EDIT-
Ok, I just noticed launching some image files from 'recent files' menu does this tab behaviour too
MP 0.34 Win: Tab width 'jumps' (especially long-filename)
Moderators: helmut, XnTriq, xnview
Re: MP 0.34 Win: Tab width 'jumps' (especially long-filename
Yes in 0.35 too.xnview wrote:In 0.35 too?
I think what is needed is for the tab to be drawn first (in programming design) then next to load the filename. Probably it would be more suitable to see the text do the 'jump' rather than the tab.
Re: MP 0.34 Win: Tab width 'jumps' (especially long-filename
Thank you for the improvement in the behavior in the MP 0.38
Right, there is still a small 'tab width jump' issue because I think of the tab thumbnail having to be drawn (thumbnail on tab: enabled)...
..So this could be addressed by drawing an invisible 16x16 box area on the tab for the thumbnail to load within it, even if the thumbnail loads late. This could then mean faster tab displaying because the space allocation itself, for the thumb on tab, would already be created first for simply the thumb to load up within it. This would further reduce or even abolish any "tab width jump".
Do you agree? Is this possible?

Right, there is still a small 'tab width jump' issue because I think of the tab thumbnail having to be drawn (thumbnail on tab: enabled)...
..So this could be addressed by drawing an invisible 16x16 box area on the tab for the thumbnail to load within it, even if the thumbnail loads late. This could then mean faster tab displaying because the space allocation itself, for the thumb on tab, would already be created first for simply the thumb to load up within it. This would further reduce or even abolish any "tab width jump".
Do you agree? Is this possible?