gitextensions
gitextensions copied to clipboard
gitextensions
Restore the order of the branch view options
Proposed changes
I'm struggling with the new order of the branches view options having built a muscle memory for the past 10+ years.
Screenshots
v3.x
v4 beta
Fixed
Merge strategy
I agree that the maintainer squash merge this PR (if the commit message is clear).
:black_nib: I contribute this code under The Developer Certificate of Origin.
This was changed (I believe it was modified due to feedback) to have the options in a logical order, most to least. (Order of Filtered and current could be debated, but multiple branches may be filtered.) To revert back just due to have it like it was before is not a good enough argument for me. However, I will not vote against this change.
Good that the 4.0 doc was not updated again.
To revert back just due to have it like it was before is not a good enough argument for me.
We had this discussion before when the order of context menus changed in the Commit dialog.
We shouldn't changed orders of menus that would have significant disruptions to UX/muscle memory.
- Placing reflogs (which not long ago were claimed to be largely unknown to most users) at the top is wrong, it's not the most used option.
- The current branch option preceded the filtered option for decades, this is too very disruptive.
On Sun, 9 Oct 2022, 2:43 am Gerhard Olsson, @.***> wrote:
@.**** requested changes on this pull request.
If this is changed, the default filter should be changed to 0
line 31
// Select an option until we get a filter bound. SelectShowBranchesFilterOption(selectedIndex: 1);
— Reply to this email directly, view it on GitHub https://github.com/gitextensions/gitextensions/pull/10234#pullrequestreview-1135237156, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBTEXRQ2BT3XASZAZQVOEDWCGJBBANCNFSM6AAAAAARAGZXIA . You are receiving this because you were assigned.Message ID: @.***>
Context commands are not the same as general menus. A general menu presents the functionality of the application in some logical way.
Will not block, but also not approve, unless traded for something else.
Related: The toolbar menu should display the shortcuts, as done in the View menu (that could be removed). As the commands are related to the RevisionGrid, RevisionGrid needs a method to set the shortcuts with the reference to the FilterToolBar with the GetShortcutKeys() method. (MenuCommands has a _revisionGrid reference and calls GetShortcutKeyDisplayStringFromRevisionGridIfAvailable(), probably not needed).
A general menu presents the functionality of the application in some logical way.
Correct. The most logical way is how often a given feature is used by the majority of users. The vast majority of users would likely use "all branches" most of the time because it's the default option and because it's the git's default. Filtering - i.e., viewing the current branch or selected other branches - would likely be the 2nd and 3rd most used options. The order has been like this for at least a decade, so users likely have developed muscle memory. As discussed many times here, reflogs is likely the less known feature to many git users, and that was one of the reasons to add to the toolbar in https://github.com/gitextensions/gitextensions/pull/9528 - to make it more visible to users in hope that it'd spark some curiosity. But since it's not likely used by the majority of users, it's inappropriate to have it placed before the other items.
..unless traded for something else.
I don't like where this is going. I can start blocking PRs too.
Related: The toolbar menu should display the shortcuts, as done in the View menu (that could be removed).
I have mixed feelings about this. Adding shortcuts will make the dropdown portion wider than it is now. We have the shortcuts in the menu already. Also, I don't believe it's a common practice to add shortcuts to the toolstrip dropdowns - I've checked Windows Explorer, Visual Studio and Office for such example, and I couldn't find any.
E.g.: the toolstip dropdown doesn't have any shortcuts...
...while the menu - does:
Also, when there are multiple controls that have the shortcuts applies - which one would get invoked?
If this is changed, the default filter should be changed to 0
line 31
// Select an option until we get a filter bound. SelectShowBranchesFilterOption(selectedIndex: 1);
Thank you, I missed this.
Taking the time to think a little bit of the change, I think that would be good to add a separator before the "Reflog" options to kind of a "special" option that they should not work with it enabled.
Because from my experience that's sometimes an option that beginners enable and not understanding well what it is doing, kept it enabled and bringing afterwards a lot of confusion. If I remember well, we already had multiple issues opened in the past on GE wrongly behaving and it was in fact the user enabling the feature.
And even perhaps with a more suggestive tooltip.
Something like:
PS: To add my point of view on the discussion, I found strange to have the reflog at the top because that's an option that you use not that often and temporarily even if I understand the idea of logical order...
