Toolbar position is not saved or restored

[pmiossec]

Current behaviour

Since #8572, I always end up with this toolbar at startup:

Even if I move the toolbars. Even when only on instance is opened.

Even with #8679 fix (to only save the toolbar settings)

Expected behaviour

I can configure the toolbar position and it is saved (or restored) well.

Steps to reproduce

1. Get a dev version of GE (portable from CI or your custom version) and launch it
2. Change toolbar setup
3. Restart
4. See toolbar position configuration is the same as initally

Screenshots

See above.

Did this work in previous version of GitExtensions

Never since the feature was introduced...

Environment

• Git Extensions 33.33.33
• Build 3245408
• Git 2.28.0.windows.1
• Microsoft Windows NT 10.0.17134.0
• .NET Framework 4.8.4261.0
• DPI 192dpi (200% scaling)

Diagnostics

The main goal to opening this issue is:

How can I debug it easily?
Where the configuration data are stored?

[mstv]

I cannot reproduce exactly this but:

• When positioned as in the issue screenshot, the original layout is restored. So I have kind of the opposite behavior.
• Perhaps it depends on the scaling factor. (I will not touch this setting of 100% on this machine!)
• (When moving the toolbars, they jump around in an unexpected way.)
• When positioned stacked vertically (just fooling about), the lower toolbar is moving to the right with every start. After 3rd:
  

[pmiossec]

* Perhaps it depends on the scaling factor. (I will not touch this setting of 100% on this machine!)

I will give it a try to see if that changes the behavior.

* (When moving the toolbars, they jump around in an unexpected way.)

The same. And it is a pain to successfully arrange them...

[RussKie]

This is very gnarly one... I've spent several hours trying different thigs, but so far I couldn't get it working reliably. Reading and then setting the same location moves a toolbar laterally.

[RussKie]

The toolbar gets pushed by something:

It is wild, and requires a deeper investigation. It's plausible there's something in our codebase that's causing it, similar to the weird behaviours observed in #8698 (comment).

[RussKie]

I've debugged the Windows Forms source, and it looks like the implementation isn't working correctly when a toolstrip panel has non-zero padding.

The following workaround appears to yield the expected results:

        public override void OnLoad(EventArgs e)
        {
            // Restore the toolbars layout
            ToolStripManager.LoadSettings(this, "toolsettings");

            // Apply the padding
            this.toolPanel.TopToolStripPanel.Padding = new System.Windows.Forms.Padding(4, 0, 4, 0);
        }

        protected override void OnFormClosing(FormClosingEventArgs e)
        {
            // Reset padding to zero before saving
            this.toolPanel.TopToolStripPanel.Padding = new System.Windows.Forms.Padding(0, 0, 0, 0);

            // Persist the toolbars layout
            ToolStripManager.SaveSettings(this, "toolsettings");
        }