"Non-modal commit interface": Tail wagging the dog
Answered
A lot has been said already about the topic, but anyway:
After the latest option to make a double click in the "commit" toolwindow open a file insted of showing the diff, I gave the non-modal setting another chance and used it for work for a couple of days.
Still, I see no real advantage, but a lot of disadvantages. IMHO the whole "non-modal" option should be removed. New users aren't getting the best experience here. Also, I am afraid that JetBrains might someday choose to remove the option to have the old UI completely.
Here are my arguments:
- focusing on the "commit" instead of the "coding" is like the tail wagging the dog:
I usually work on a change for hours or sometimes days. This is the main use case that should be supported as best as possible.
Commit is happening once (or twice when I have to incorporate some changes from code review) and I don't mind it being "modal" - it is a singular, specific operation. - In the old UI I have the "Preview Diff" enabled to get a quick overview over my changes and to navigate to a specific change place in the code - all without messing up the editor view.
- In the old UI I can see both my "Local Changes" and the project tree at once, which I find very helpful.
- Using the main editor for a diff view is disorienting. Also when the editor is split (which is almost always is for me), the diff is using only half the screen width, which is just too small.
- Why do I now have to use *two* separate toolwindows for VCS related stuff? It feels more consistent to have that in one tab.
(Actually, it's three tabs with the new UI, because I use the gerrit plugin which also has a separate toolwindow.)
Please sign in to leave a comment.
Thank you for the feedback, Stephen.
In general, we expected that the new UI will not work for all of the users. Especially for those who are fine using the previous UI with a modal dialog. However, we believe having a non-modal commit view makes IDE feel a bit more lightweight and easier to use. This is why it is the default for new installations.
> focusing on the "commit" instead of the "coding"
Could you please clarify how the UI forces you to focus on commit? It is the same list of changes that it used to be, but with some additional controls. It does not block you from doing anything else, especially since it is now possible to open the contents on double-click.
> Commit is happening once
That's your workflow, and the modal commit UI fits it better - so you are welcome to keep using it. There are no plans to remove it in the near future.
There are other workflows, who often use the "commit often" approach and the current view is good for it. This is also a much more common view nowadays.
> I have the "Preview Diff"
Which is too small to be useful if the screen is not big enough.
> In the old UI I can see both my "Local Changes" and the project tree at once, which I find very helpful.
How exactly is it helpful? Why do you need to see both?
Note that you can move the Commit toolwindow around, as any other one (e.g move it back to the bottom, or to the right), to make both visible. If your screen is wide enough, you can move it e.g. to the bottom right which will allow you to have it at the bottom along with the Git toolwindow
> Also when the editor is split
Indeed, for non-default layouts like this, the diff in the editor does not work well. It's a known issue - https://youtrack.jetbrains.com/issue/IDEA-231847
But the majority of users do not use splits.
> Why do I now have to use *two* separate toolwindows for VCS related stuff?
They are focusing on different aspects of VCS-related tasks. If you use GitHub Pull Request view, it will be one more toolwindow, for the same reason. As a bonus, you can see the history while in the commit view, which is sometimes useful.
As mentioned above, you can move the TW to the bottom, next to the GIt, and it will be quite similar to the original view.
Thanks Dmitriy, for the detailed answer!
After pondering on it some more:
What I like about the old UI is: I can do all my coding tasks with the editor and a fixed set of toolwindows that *do not change*.
My standard layout is: Project tree, Local Changes (unstructured list, not grouped by directory), Preview Diff in *digest mode* (with unchanged parts collapsed) and of course the editor.
I can
All that without ever replacing any toolwindow or even the editor view.
No context switch, very focused.
A typical scenario might be
Ironically, the "non-modal commit" that takes away the context switch when commiting, for me leads to more context switches (replacing the editor with a diff and back, replacing the project tree with local changes and back).
Also when used in digest mode the "git" toolwindow is high enough for the preview diff to be usable.
But of course, you are right that the "Commit" toolwindow and the "Local Changes/Shelf" tabs in the "git" toolwindow are *very* similar.
Here's a rough idea how to maybe reconcile both approaches:
When not visible and the Commit action is invoked (via menu, shortcut or toolbar) show the commit dialog.
I completely agree with OP here, the modal commit dialog was one of the most missed things when I switched to vscode for 2 years. Its just a great summary of your work in one place. Now Im back and happy its still there. Please never sun set it...
I totally agree with the OP,
having Non-modal commit interface set on my new laptop after new intallation forced me to spend enormous amount of time to figure out how was the `local changes` tab named in previous version and how to get it back.
This is a single feature that still keeps me using Intellij product, but that new default option is too much
a.kachur
Please feel free to contact us with more details about issues you are having with Non-modal commit interface.
I cannot believe this. Are there any available stats for this? How is this collected?
I could not possibly code without this feature. I remember when Visual Studio Code first came out and i was trying out a bunch of editors and it didn't support triple splits. This was one of the things that made me dislike Visual Studio Code a lot.