Break the toolstrip

[RussKie]

Relates to #5525

Proposed changes

• Break the main toolbar into two - general operations and filters. This is arbitrary, filters were the easiest to break out. The main point of the PR was to attempt the split and see how well it works. This then maybe used as a foundation for further refactoring of the toolstrip area, such as moving user scripts to own toolstrip, view-related, repo-related... Possibilities are endless.
• Save/restore positions of the toolbars

Screenshots

Before

After

---

✒️ I contribute this code under The Developer Certificate of Origin.

[codecov]

Codecov Report

Merging #8572 into master will increase coverage by 0.04%.
The diff coverage is 87.23%.

@@            Coverage Diff             @@
##           master    #8572      +/-   ##
==========================================
+ Coverage   55.06%   55.10%   +0.04%     
==========================================
  Files         901      902       +1     
  Lines       65156    65220      +64     
  Branches    11755    11753       -2     
==========================================
+ Hits        35875    35939      +64     
+ Misses      26504    26501       -3     
- Partials     2777     2780       +3     

Flag	Coverage Δ
#production	42.09% <87.23%> (+0.07%)	⬆️
#tests	94.82% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[gerhardol]

Relates to #5525

Is this the correct reference?

I like the change, but I rather like to remove/add specific buttons:
#4952 (comment) (or some other issue)

I hardly use the filters, but most buttons in the (new) main toolstrip (except toggle panel and hardly branches (but submodule "up").
However, the filters do not occupy any used space for me, they are just hidden in windowed mode.

The code looks good and works as expected, but I believe that was not what you asked for.

Will continue discussion in #4952

[ghost]

👍
How can I hide / show the panel?

[RussKie]

Relates to #5525

Is this the correct reference?

Yes, there was a discussion pertaining to breaking the main toolbar into different ones (e.g. #5525 (comment)).

I like the change, but I rather like to remove/add specific buttons:
#4952 (comment) (or some other issue)

This one is a good one too, 👍

The code looks good and works as expected, but I believe that was not what you asked for.

This is the first step to allow users customise the toolbar - either via a coarser solution of showing/hiding toolbars, or via a fine-grainer one of showing/hiding individual buttons.
This is something has been on my mind, for at least 3 years now judging by commits in https://github.com/RussKie/gitextensions/tree/rework_toolbars

[gerhardol]

This is the first step to allow users customise the toolbar - either via a coarser solution of showing/hiding toolbars, or via a fine-grainer one of showing/hiding individual buttons.

I am not opposing the change in any way. It also requires a way to hide/show the toolbars to be really useful, as well as splitting up the toolbars further.
However, if someone puts time on this, I rather see that the effort is on the individual buttons rather than the toolbars.

[ghost]

I see several strategies here.
One panel and customizable buttons.
Multiple panels and the ability to disable a panel.
Both options.

[ghost]

Plugins could also register their buttons.

[RussKie]

Since it bothered me, and you asked for it - there you go:

NB: FormFileHistory is unaffected, though it uses the same FormBrowseMenus API.

[RussKie]

Btw, the toolbars settings are stored in a local user config located somewhere like this: C:\Users\<user>\AppData\Local\Git_Extensions\GitExtensions.exe_Url_<some crazy string>\33.33.33.0\user.config

[drewnoakes]

If you arrange the toolbars on the same row, and the leftmost one reduces its width, does the right one stay still or move to the left?

Or in other words, if you don't want to give up any vertical screen height and you want both toolbars, will this make the experience different/worse?

[RussKie]

Thank you @ivangrek, can you please explain the nature of your changes? [EDIT] What did I miss? Found it - checkboxes get out of sync.

Also your changes introduce a number of perf regressions - LINQ is significantly more expensive and requires more allocations (for example).

[RussKie]

If you arrange the toolbars on the same row, and the leftmost one reduces its width, does the right one stay still or move to the left?

This would be the default behaviour of Windows Forms. If toolbars are sequentially positioned (i.e. no gaps) they remain together when the left one contracts or expands - this is easy to verify by switching repositories (the repositories toolbar dropdown changes width).

. . .

I'm currently unhappy with the visual tearing when the toolbars are refreshed, something is missing somewhere... #Resolved

[RussKie]

What I see as immediate low hanging fruits from here

• breaking user scripts into own toolbar, and
• adding the following items to the 'Filters' toobar:
  • Show all / current branch only / filtered - either as 3 different buttons or a dropdown list (requires POC to see what works best for UI/UX)
  • Show reflogs
  • ❔ Highlight the current branch - whilst not filtering, I find myself using it often, going to the menu feels distracting.

[ghost]

Also your changes introduce a number of perf regressions - LINQ is significantly more expensive and requires more allocations (for example).

needs to choice

[ghost]

If you arrange the toolbars on the same row, and the leftmost one reduces its width, does the right one stay still or move to the left?

Would be nice to "float left"

[ghost]

[RussKie]

This is how a user positioned the toolbars, the runtime obeys the user's choice.
We could maybe add "Reset" option to reset back to the default, but this is outside the scope of this change.

[ghost]

Just VS UX.
We could create new issue when ok.

[pmiossec]

@RussKie

Save/restore positions of the toolbars

I see in the description of the PR that the positions of the toolbars are saved and restored. Should it be the case or is it in fact not yet implemented?

Because I always end up with this configuration (that I hate):

Only hidding of toolbar is saved for me.
Tested with custom version, version build from HEAD and the portable version from AppVeyor.

Tell me and I will open an issue if that's already implemented...

[gerhardol]

Only hidding of toolbar is saved for me.

Positions are normally stored for me, but not always if they are viewed or not...
But probably the same cause

Mentioned in #8636