Section width is changing in status bar on navigating around

I've noticed that the status bar layout isn't consistent when navigating around (the sections are occasionally become too wide). I tried to reproduce it and I found a very simple example.


If I use the code given above and start to navigate around on my volumes the left section is "pumping".

For our real status bar configuration (having multiple sections) this is a problem since sometimes there is some unused space popping pushing everything else to the right.

Most times it looks as expected:

But sometimes there pops up some space:

PS: Obviously the whole line doesn't use any padding and everything should be left aligned.

Select all in the folder and the reason for the width difference should become obvious.

Ok, I got it, thanks for the hint. You reserve extra space for {si} according to the maximum width that may be reached.

At least for our configuration this behaves poorly because all other fields don't behave the same. In other words the sections are re-layouted (moved to the left/right) anyway on each navigation operation because all the other fields change their width constantly.

If I replace the {si} with {sb} the second statusbar section is moved to the right (as expected) when the first section growth. This dynamic layout mechanism works very well, thus I can't see any advantage to introduce extra space for {si}.


I assume the behavior is evolved over time, but with the current dynamic layout mechanism, it does not seem to be very useful at all. On the contrary, in complex configurations it would supplant other items that would otherwise fit just yet on the screen.

Which fields move all the time?

And what are you proposing we do instead of make the fields as large as they may need to be for the current folder? If we don't do that then the possibilites are:

  1. Make the fields resize whenever you select anything. Then they'd resize even more often. If your complaint is that things move around, this would be even worse.

  2. Make the fields use the maximum possible size at all times. Then you'd be in a folder with 1 file and the file count field would be 20 characters wide or something. (Whatever the max file count on NTFS requires.)

I don't understand why this actually causes you a problem, nor how it would work better differently.

Sorry, I was not able to explain it correctly. Give me another try ...

If I understand you correct you reserve some space for {si} (and other fields) to let the fields less often be resized.

I tried to explain that this reserved space isn't useful for complex configurations (using different fields) because most of the other fields change their widths constantly (e.g. on navigating). And I really like this behaviour because this makes multiple sections (appended to each other) to allocate as little space as possible.

Thus I want to propose to let all fields only reserve the space that is actually needed to display the current text. If somebody don't like this dynamic layout mechanism he just has to use the flexible padding fields to let some sections always start at certain positions.

In the following example you can see that the extra space (that was dynamically reserved by some of the fields) actually displaces some of the most-right fields that otherwise would just yet fit on the screen.

Certainly you can use padding and right-justification as workaround but that doesn't alter the fact that there are fields using more space than actually needed in situations where only little space is available. Depending on the padding and justification the truncated sections are on the right or in the middle.

On the other hand the reserved extra space by {si} only has a positive effect if many files are selected. But I think that 95% of the time only a single file is selected. Thus this optimization only has a possitive effect for the non-standard use-case.

I can give another example:

Have a look to this stacked statusbars displaying some useful information about different folders. In none of these 4 cases I can see an actual advantage to have this reserved extra space because the total width of the first section also depends on other fields that do not reserve this space. In other words the sections are moving around anyway.

Thus I propose to keep it easy and let the fields only allocate the actual space that is needed to display the current text. But as always that isn't a show stopper it's just a simple suggestion because we use a statusbar configuration that quickly become overcharged on small displays and in such situations I'm wondering about the wasted space at the end of some sections that displaced other useful information.

Those are really verbose status bar definitions. If you're running out of space it's easy to fix.

Yes obviously it can be easily fixed.

But even the default statusbar runs into the same problem. Sometimes I have to use other workstations only having a single display with 1920x1080 pixel resolution. Then I use the splitscreen feature (WIN + CursorLeft/Right) to place two windows aside of each other. In this case even the DOpus standard toolbar displaces some fields on the right due to the reserved space in the middle.

PS: I just want to have a short discussion to find out whether it would make sense to improve the existing behaviour by throwing few lines-of-code away. But maybe there are other cases where this extra space actually provides a positive effect and I just can't currently imagine them. For me it just looks as the reserved space isn't needed anymore since we have so many powerful padding fields.

But again, this is just an insignificant suggestion to make a wonderful tool a little bit more wonderful.

Sorry but I think these justifications are getting ridiculous.

If you want to display four status bars side-by-side on one 1920 wide monitor then of course space will be tight. In the example above, things will be tight even without the oh-so-awful use of four extra characters in one of the fields.

Let's stop, please. The way things work makes sense in almost all cases, and what you're proposing won't really help in many cases and would be annoying in a lot of cases.

Certainly it won't be two DOpus windows put side-by-side if using splitscreen (instead it is an application window left and DOpus lister right).

I just wanted to report a small improvement and certainly not being ridiculous. Sorry for that! Since I have not yet understood in which cases what I am proposing will be annoying I also think we should stop! :thumbsup:

Probably cases in which there is plenty of space for the defined fields. If I understand this correctly that might make variable sized fields expand and contract while providing no value.

I'm not taking any side in the debate, just trying to provide an example of a case in which the proposed behavior might be annoying.