Total Commander

As far as I understand, if a section like [1400x1050 (8x16)] is found in wincmd.ini, it is used to setup the total commander geometry. If the screen resolution is not 1400x1050, then the section is ignored.

This works great for normal monitors where normally just one and at most few screen resolutions are used. However, in virtual machines the screen resolution is often determined by the host window size and varies greatly making it impractical to list all possible resolutions.

What if the largest section that is smaller or equal to the actual screen resolution is used?

F1: Configuration and switches b. INI-File settings: wincmd.ini

ResolutionSpecific=0
0: Resolution-specific data like font style+size are stored in a single section called [AllResolutions]
1: Resolution-specific data is stored in sections like [1024x768 (10x20)]

HTH
Holger

ResolutionSpecific=0

It just fixes size an position - what Octagon seems to want, is that when a new resolution is detected by TC, then TC should use the nearest smaller already existing resolution as a template for the new resolution section in wincmd.ini.

I think that sounds like a good idea - the only thing that can be difficult is: what dimension, horizontal or vertical should be used to determine what is the smaller resolution?

For example - is 1152x864 smaller or bigger than 1366x768. By total number of pixels 1152x864 is smallest, but if you mainly adjust the windows by height and not width then 1152x864 would be the best resolution to choose.

I do work with virtual machines and all i can say "it's sufficient".
The problem is: you lose all your font settings every time the VM-Windows is resized and TC detects a new
screens size during startup.
The main advantage for different font sizes is to adapt TC to different DPI, but because you always use the same monitor (with the same DPI) switching to different sections is not really necessary.

TC already adapts windows sizes and positions.
So dialogs are never off-screen or over-sized (bigger than the actual screen resolution).

as a template for the new resolution section

After a while, there will be thousands of sections.

Regards
Holger

The main problem I solve with geometry settings is to get rid of the necessity to make the TC window larger each time TC starts. Other settings are minor, but also useful. Thus, not only the DPI, but the size of the screen also matters.

As for comparison of sections by size, I guess it is possible just ignore sections where one one dimension is smaller and another one is larger.

Octagon wrote:The main problem I solve with geometry settings is to get rid of the necessity to make the TC window larger each time TC starts.

This is because TC always use defaults settings (should also work with 800x600 resolution) if a new screen size is detected.
You should try ResolutionSpecific=0.

Other settings are minor, but also useful. Thus, not only the DPI, but the size of the screen also matters.

As both font and position settings are stored inside a single section, also font settings are reverted to defaults.

One big problem i see in multiple section is the number of sections that would be created over the time.
This may inflate your ini-file to an unusable size.

Another problem is:
Assume you set the font settings for one specific resolution, and create every time you change the resolution a new section with parameter inherited from an existing nearest section.
After a while you have dozens of sections with same font settings.
Now change your mind and select another font.
Guess whats happens: every time you start TC with a resolution which is already stored in wincmd.ini, you will see the old font settings.

So what would be needed:
a) A possibility to use one common font setting and multiple resolution specific size/position settings.
b) A limited number of nearest resolution sections, selected by an algorithm not comparing the exact screen resolution but considering an aberration of lets say 10%-20% as equal.

Change a) may be incompatible to the existing solution, and change b) is not really a huge benefit compared to ResolutionSpecific=0.

Regards
Holger

HolgerK wrote:b) is not really a huge benefit compared to ResolutionSpecific=0

This may be true. Anything beyond All Resolutions is either a small benefit or a niche interest. I guess the desire to have 2 startup sizes is a pure niche interest.

As far as I understand, plugins are not loaded until needed and do not have access to top level TC functions like window positioning, tabs opening and navigation, and so on.

What if a 4th kind of plugins is added that has access to such functions (like what button bar buttons do plus window positioning), is loaded when TC starts, and receives notifications when TC starts and exits?

This will allow to perfectly satisfy the original request and potentially lots of niche interests.

Suffered from the same problem.

Solved in 3 steps:

1) Added ResolutionSpecific=0.
2) Added [AllResolutions] section.
3) Made wincmd.ini read-only.

Here is a part from my config.
[AllResolutions]
FontCharset=204
FontSize=8
FontName=Tahoma
FontWeight=400
FontCharsetDialog=204
FontSizeDialog=8
FontNameDialog=Tahoma
FontWeightDialog=400
FontCharsetWindow=204
FontSizeWindow=8
FontNameWindow=Tahoma
FontWeightWindow=400
IconSize32=16
Maximized=1
X=0
Y=0
Divider=500
DividerComments=800
DividerQuickView=500
TabStops=100,110,175,-1,432,200
CompareMax=1
CompareX=0
CompareY=0
CompareDivider=500
RenameMax=1
RenameX=0
RenameY=0
RenameTabs=270,320,640,740,850
SyncMax=1
SyncX=0
SyncY=0
SyncTabs=250,350,450,480,580,680
SearchMax=1
SearchX=0
SearchY=0

3) Made wincmd.ini read-only.

In stead of write-protecting wincmd.ini, you could redirect the [AllResolutions] section - for example:

[AllResolutions]
RedirectSection=display.ini

And then write-protect display.ini in stead - a little less drastic.

Thank you. I know about redirection but I prefer to restrict whole wincmd.ini as I prefer config once and use always.

I prefer to restrict whole wincmd.ini

Isn't it unpractical to restrict sections like:

[SearchText]
[Selection]
[MkDirHistory]
[rename]
[RenameSearchFind]
[RenameSearchReplace]
[SearchName]
[SearchIn]
[Command line history]

I prefer not to save history because I do not really need it and I am constantly sharing my wincmd.ini between other users. It can be unpractical for someone but for me it is very useful.