search

gitextensions / gitextensions

Git Extensions is a standalone UI tool for managing git repositories. It also integrates with Windows Explorer and Microsoft Visual Studio (2015/2017/2019).
https://gitextensions.github.io/
Other
7.7k stars 2.08k forks source link

[Idea] Add option to show commit dialog beneath commit graph #5535

Open mdonatas opened 5 years ago

mdonatas commented 5 years ago

Problem

Once Commit dialog is opened, you can't interact with commit graph and if you leave it open in another monitor clicking on main form reveals commit dialog forcing you to close it.

Suggestion

(with some Paint .Net magic) I propose to have an option to place Commit dialog under commit graph next to Diff or File Tree tabs image

We could have an option to pin/unpin it which would switch this dialog between a full blown dialog as it is now and this docked state proposed in the screenshot. [ctrl+space] would work as expected too - focus Commit tab.

vbjay commented 5 years ago

It's been suggested before. That would kill the performance of the main window.

On Mon, Oct 8, 2018, 4:57 AM Donatas notifications@github.com wrote:

Problem

Once Commit dialog is opened, you can't interact with commit graph and if you leave it open in another monitor clicking on main form reveals commit dialog forcing you to close it. Suggestion

(with some Paint .Net magic) I propose to have an option to place Commit dialog under commit graph next to Diff or File Tree tabs [image: image] https://user-images.githubusercontent.com/483659/46599636-7fce7a00-caf0-11e8-8f89-8196228b66a5.png

We could have an option to pin/unpin it which would switch this dialog between a full blown dialog as it is now and this docked state proposed in the screenshot. [ctrl+space] would work as expected too - focus Commit tab.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gitextensions/gitextensions/issues/5535, or mute the thread https://github.com/notifications/unsubscribe-auth/ADdhsS5Fzmx3-apWSHdrMp9m2ZXcIlm3ks5uixOTgaJpZM4XMgJb .

mdonatas commented 5 years ago

Why would it do that? The contents of Commit dialog don't change based on what you do in Commit graph, there'd still be Refresh button to reload it and the form would be initialized only when selecting Commit tab. What am I missing?

vbjay commented 5 years ago

See #564

On Mon, Oct 8, 2018, 5:13 AM Donatas notifications@github.com wrote:

Why would it do that? The contents of Commit dialog don't change based on what you do in Commit graph, there'd still be Refresh button to reload it and the form would be initialized only when selecting Commit tab. What am I missing?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/gitextensions/gitextensions/issues/5535#issuecomment-427767534, or mute the thread https://github.com/notifications/unsubscribe-auth/ADdhsZQJV-p_SJElGhNmig0oqni_hHytks5uixc4gaJpZM4XMgJb .

pmiossec commented 5 years ago

It's like sourcetree does and I don't like it. The space to view diff and list of staged/unstaged files end up to be too narrow...

mdonatas commented 5 years ago

@vbjay the only comment about negative performance in that discussion was yours (dick-move) and the only reply to it was in essence that it wouldn't be a problem because of lazy loading. p.s. thanks for pointing me to a related discussion.

mdonatas commented 5 years ago

@pmiossec Like/not-like is not the same as good-idea/bad-idea ;) This would be an option to dock commit dialog and not replacement of current behavior. Also ctrl+space could first open commit form in its last state and switch between the two states when further invoking ctrl+space == great for small commits and large commits as transformation is quickly invoked.

vbjay commented 5 years ago

Notice the 7 year timespan of the issue. Notice it is still it's own window. Notice that my point was not invalid.

On Mon, Oct 8, 2018, 6:55 AM Donatas notifications@github.com wrote:

@pmiossec https://github.com/pmiossec Like/not-like is not the same as good-idea/bad-idea ;) This would be an option to dock commit dialog and not replacement of current behavior. Also ctrl+space could first open commit form in its last state and switch between the two states when further invoking ctrl+space == great for small commits and large commits as transformation is quickly invoked.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/gitextensions/gitextensions/issues/5535#issuecomment-427792113, or mute the thread https://github.com/notifications/unsubscribe-auth/ADdhsQssLWJ0Cjlbr_1Bk_LBWDfbY7w4ks5uiy84gaJpZM4XMgJb .

mdonatas commented 5 years ago

Duplicate of #564

RussKie commented 5 years ago

I'm going to have this discussion open (because it is newer and easier to find) and close the other one. I'm happy to return to this discussion after v3 is released.

mstv commented 5 years ago

In general, I want to be able to minimize an application regardless whether it shows a modal dialog or not. I expect that minimizing the modal dialog hides the whole application. I expect that the taskbar context menu item Close Window closes the application or at least the active window (which doesn't have any effect on the Commit dialog currently).

Most of the time, I use windows maximized on one of the displays. I like the idea of Ctrl+Space switching between modal Commit dialog (default) and docked operation. I would appreciate to use it when I want to check something in previous commits while reviewing the current commit and when I want to copy parts of a previous commit message.

The commit message should be stored always if modified by the user, especially also if it is a merge message -- on close of the Commit dialog and if docked, on switch of the repository.

drewnoakes commented 5 years ago

@RussKie #564 is not a duplicate. It just suggests making the window modeless, so you can tab between form commit/browse. It's a different proposal, and likely easier to implement. In fact it's not even mutually exclusive. Personally, I would rather see it made modeless than docked beneath the graph. The modal window breaks many desktop paradigms and features.

johndog commented 5 years ago

Hat tip to #564.

My opinion:

I would rarely ever dock it, personally. I would want to use my window manager, multiple monitors, etc, to make sure that the UI has enough space depending on the environment. As others have commented, the docked UI is usually going to be too small.

Today, I launch two separate instances of GitEx: one to run the main window, the other so that I can bring up the modal commit UI. This lets me quickly switch back and forth between the commit UI and the graph -- the graph is essential to helping me compose commit messages, especially !fixups. This is still rather painful, as I have to keep track of which instance has the blocking dialog and which doesn't, so I seek precisely the same experience with one instance of GitEx by way of modeless commit UI. This should have no performance implications, since both UIs are refreshed on demand and independently.

Performance would be maintained in a docking scenario by retaining the same behavior: the windows continue to be refreshed on-demand and independently. It would help if the UI could provide some "stale-ness" indicator. Even in current builds such an indicator would be handy for the main window, which often looks up-to-date but is completely wrong about the current branch, current commit, etc. But we don't have a staleness indicator today, so I don't consider it a blocker for modeless commit UI, though it might be more important for docked UI.

johndog commented 5 years ago

Previously I wrote:

... make the dialog modeless. This addresses most of the challenges of running commit UI and main UI concurrently.

I just realized that describing this as "most of the challenges" is wildly speculative. I can imagine a tremendous amount of refactoring might be required to enable the same Commit UI logic to operate as a modeless window or as a docked window.

It may even be the case that the only thing of value that a modeless implementation would accrue to a dockable implementation is to allow people try it out and expose the flaws in the experience of having Commit UI and main window UI concurrently accessible. That'd still be a good thing to have in hand before starting work on a docked experience.

gluttony38 commented 4 years ago

In my personal opinion, https://github.com/gitextensions/gitextensions/issues/564 would have been better to implement, anyway, there is a workaround, at least under Windows, that is to open folder in file explorer, right click and select "GitExt Commit...", this will open the commit dialog independently to any other Git Extensions window opened.

gerhardol commented 4 years ago

More and more functionality in FormCommit is available in the diff tab for artificial commits When #7825 is merged I will only have to open FormCommit to enter the commit message

githubkusi commented 3 years ago

I don't have a strong opinion for either #5535 (this) or #564, but this is currently quite a nuisance: I often have the commit window next to an application window (Matlab in my case) since I need the application in order to write the commit message. This is not possible if the main GE window is in the way, and there is no way to move the main GE window away.

+1 for modeless commit window or commit tab