"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.)
2 comments
Comment actions Permalink

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.

0
Comment actions Permalink

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

  • edit
  • use the local changes list to easily navigate between changes files
  • use the preview diff and UP/DOWN buttons to quickly get an overview of all changes
  • use the project tree to get an overview about the structure in specific places

All that without ever replacing any toolwindow or even the editor view.

No context switch, very focused.
A typical scenario might be

  • use "F4" on a specific change in the preview diff, which brings me to the editor
  • editing something there
  • then using "Select in -> Project view" (which I have mapped to Ctrl-^), navigating to a related file that also needs to be changed.

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:

  • add a toolbar button in the toolwindow to toggle the "commit part" (commit toolbar buttons, commit message and buttons).
    When not visible and the Commit action is invoked (via menu, shortcut or toolbar) show the commit dialog.
  • provide a way to move the diff either to the editor pane or to the toolwindow itself. When placed in the editor it should *not* appear as a regular editor tab, but be pinned to the left and replace all editor splits.
0

Please sign in to leave a comment.