* Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” @ 2019-09-13 2:54 Allan Ford 2019-09-13 14:32 ` Pratyush Yadav 0 siblings, 1 reply; 13+ messages in thread From: Allan Ford @ 2019-09-13 2:54 UTC (permalink / raw) To: git Dear Git Authors, Not a bug, but a suggestion consideration for “Git Gui” Can a double click on the file name in the “unstaged” area move the item to “staged changes” .. (rather than having to click on the small icon to the left of the file name?) cheers, Allan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 2:54 Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” Allan Ford @ 2019-09-13 14:32 ` Pratyush Yadav 2019-09-13 20:27 ` Bert Wesarg ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Pratyush Yadav @ 2019-09-13 14:32 UTC (permalink / raw) To: Allan Ford; +Cc: git On 13/09/19 12:24PM, Allan Ford wrote: > Dear Git Authors, > > Not a bug, but a suggestion consideration for “Git Gui” > > Can a double click on the file name in the “unstaged” area move the > item to “staged changes” .. (rather than having to click on the small > icon to the left of the file name?) It has been something on my radar for some time. Shouldn't be something too difficult to do. While I like the idea in general, I have a question that I'd like to ask other git-gui users: If we implement something like this, what happens when you single-click on the icon? Do we treat that as a stage/unstage command? If we keep the legacy behaviour of single-click on the icon stages/unstages, then a part of the row is single-click and the rest double-click. If we make an entire row of the stage/unstage widget double click, it messes with people who are already used to it. Is partial single and partial double click behaviour acceptable? Or should we make the entire row double click only? Or something else that I missed? -- Regards, Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 14:32 ` Pratyush Yadav @ 2019-09-13 20:27 ` Bert Wesarg 2019-09-13 21:06 ` Pratyush Yadav 2019-09-14 16:07 ` David 2019-09-13 21:53 ` Marc Branchaud 2019-09-14 7:24 ` Johannes Sixt 2 siblings, 2 replies; 13+ messages in thread From: Bert Wesarg @ 2019-09-13 20:27 UTC (permalink / raw) To: Pratyush Yadav; +Cc: Allan Ford, Git Mailing List On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav <me@yadavpratyush.com> wrote: > > On 13/09/19 12:24PM, Allan Ford wrote: > > Dear Git Authors, > > > > Not a bug, but a suggestion consideration for “Git Gui” > > > > Can a double click on the file name in the “unstaged” area move the > > item to “staged changes” .. (rather than having to click on the small > > icon to the left of the file name?) > > It has been something on my radar for some time. Shouldn't be something > too difficult to do. > > While I like the idea in general, I have a question that I'd like to ask > other git-gui users: I miss a general problem description: Whats wrong with the single-click on the icon to begin with? I consider adding a second way as not not acceptable. I also consider double-click on a file in a GUI an "open" action. But in git-gui, this "open" action (showing the diff) is already done with a single-click. From my point of view, it can stay as is. Best, Bert > > If we implement something like this, what happens when you single-click > on the icon? Do we treat that as a stage/unstage command? If we keep the > legacy behaviour of single-click on the icon stages/unstages, then a > part of the row is single-click and the rest double-click. > > If we make an entire row of the stage/unstage widget double click, it > messes with people who are already used to it. > > Is partial single and partial double click behaviour acceptable? Or > should we make the entire row double click only? Or something else that > I missed? > > -- > Regards, > Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 20:27 ` Bert Wesarg @ 2019-09-13 21:06 ` Pratyush Yadav 2019-09-14 16:07 ` David 1 sibling, 0 replies; 13+ messages in thread From: Pratyush Yadav @ 2019-09-13 21:06 UTC (permalink / raw) To: Bert Wesarg; +Cc: Allan Ford, Git Mailing List On 13/09/19 10:27PM, Bert Wesarg wrote: > On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav <me@yadavpratyush.com> wrote: > > > > On 13/09/19 12:24PM, Allan Ford wrote: > > > Dear Git Authors, > > > > > > Not a bug, but a suggestion consideration for “Git Gui” > > > > > > Can a double click on the file name in the “unstaged” area move the > > > item to “staged changes” .. (rather than having to click on the small > > > icon to the left of the file name?) > > > > It has been something on my radar for some time. Shouldn't be something > > too difficult to do. > > > > While I like the idea in general, I have a question that I'd like to ask > > other git-gui users: > > I miss a general problem description: Whats wrong with the > single-click on the icon to begin with? The way I see it, there are two parts. Objectively, it is harder to click the icon than it is to click anywhere on the entire row. The small size of the icon adds to the problem. Subjectively, I personally came from using Atom for quite a while, and it staged the file on double click. I think some other editors do this too. So, I was used to that way of doing things, and had to adapt to the git-gui way. > I consider adding a second way as not not acceptable. I also consider > double-click on a file in a GUI an "open" action. But in git-gui, this > "open" action (showing the diff) is already done with a single-click. Well, that's the other point of view, and it makes sense too. As I was afraid, this seems to be a personal preference problem and it will be difficult to reach agreement. And I'm generally inclined to keep things like they are rather than making drastic changes with debatable benefit. > From my point of view, it can stay as is. How about something in the middle? How about larger icon sizes? Will that help your workflow Allan? > > > > If we implement something like this, what happens when you single-click > > on the icon? Do we treat that as a stage/unstage command? If we keep the > > legacy behaviour of single-click on the icon stages/unstages, then a > > part of the row is single-click and the rest double-click. > > > > If we make an entire row of the stage/unstage widget double click, it > > messes with people who are already used to it. > > > > Is partial single and partial double click behaviour acceptable? Or > > should we make the entire row double click only? Or something else that > > I missed? -- Regards, Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 20:27 ` Bert Wesarg 2019-09-13 21:06 ` Pratyush Yadav @ 2019-09-14 16:07 ` David 2019-09-14 19:08 ` Pratyush Yadav 1 sibling, 1 reply; 13+ messages in thread From: David @ 2019-09-14 16:07 UTC (permalink / raw) To: Git Mailing List On Sat, 14 Sep 2019 at 06:51, Bert Wesarg <bert.wesarg@googlemail.com> wrote: > On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav <me@yadavpratyush.com> wrote: > > On 13/09/19 12:24PM, Allan Ford wrote: > > I miss a general problem description: Whats wrong with the > single-click on the icon to begin with? No problem here, but see my other message for further thoughts. > I consider adding a second way as not not acceptable. I also consider > double-click on a file in a GUI an "open" action. Yes! In fact, I've often fantasized how useful it would be that if I double clicked on that file name in the unstaged pane or the staged pane, then that would open the file for editing in my preferred/configured editor. Now for me *that* would be a very frequently used improvement! I wonder what other readers think about this idea? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-14 16:07 ` David @ 2019-09-14 19:08 ` Pratyush Yadav 2019-09-15 3:41 ` David 0 siblings, 1 reply; 13+ messages in thread From: Pratyush Yadav @ 2019-09-14 19:08 UTC (permalink / raw) To: David; +Cc: Git Mailing List On 15/09/19 02:07AM, David wrote: > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg <bert.wesarg@googlemail.com> wrote: > > On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav <me@yadavpratyush.com> wrote: > > > On 13/09/19 12:24PM, Allan Ford wrote: > > > > I miss a general problem description: Whats wrong with the > > single-click on the icon to begin with? > > No problem here, but see my other message for further thoughts. > > > I consider adding a second way as not not acceptable. I also consider > > double-click on a file in a GUI an "open" action. > > Yes! > > In fact, I've often fantasized how useful it would be that if I double > clicked on that file name in the unstaged pane or the staged pane, > then that would open the file for editing in my preferred/configured editor. > > Now for me *that* would be a very frequently used improvement! > > I wonder what other readers think about this idea? Sounds reasonable. I've wanted something similar, but for commit messages. But one major reason I didn't come up with a patch for editing commit messages in the editor of your choice is terminal based editors. I don't think there is any way of finding out the default terminal emulator in Linux, and I don't think there is a standard way of making terminal emulator launch programs you want. So your suggestion works only for GUI based editors. We would have to mention that only GUI based editors can open files. I like the idea, but I thought I'd point a problem I saw with this feature. Also, the file viewer in git-gui opens the blame viewer, but I suppose that's not what most people want. -- Regards, Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-14 19:08 ` Pratyush Yadav @ 2019-09-15 3:41 ` David 2019-09-16 17:49 ` Pratyush Yadav 0 siblings, 1 reply; 13+ messages in thread From: David @ 2019-09-15 3:41 UTC (permalink / raw) To: Git Mailing List On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav <me@yadavpratyush.com> wrote: > On 15/09/19 02:07AM, David wrote: > > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg <bert.wesarg@googlemail.com> wrote: > > > I consider adding a second way as not not acceptable. I also consider > > > double-click on a file in a GUI an "open" action. > > > > Yes! > > > > In fact, I've often fantasized how useful it would be that if I double > > clicked on that file name in the unstaged pane or the staged pane, > > then that would open the file for editing in my preferred/configured editor. > > > > Now for me *that* would be a very frequently used improvement! > > > > I wonder what other readers think about this idea? > > Sounds reasonable. I've wanted something similar, but for commit > messages. > > But one major reason I didn't come up with a patch for editing commit > messages in the editor of your choice is terminal based editors. Hi again Pratyush Yadav, and other readers! I hope I don't sound like I am arguing or enthusiastically promoting change in this subthread. I'm not, my attitude is rather just to explore an idea to see what others think of it. Some days I have good ideas, other days my ideas have flaws that I missed, so I like to discuss first. More important, I want to say that I am very happy to see that there are folks interested to discuss the Tcl/Tk git GUI tools. In fact I have local Tcl patches myself, bugfixes and enhancements for git-gui and gitk, which I would be happy to share except that I do not know how to do that effectively. I don't enjoy Tcl and because of that I have avoided it and don't consider my skill level to be very high. I find it rather obtuse, especially the way it does namespacing, and "upvar" in particular. I struggle to read it without comments. But I learned enough of Tcl specifically to improve aspects of git-gui and gitk that were bothering me in the past. As well as bug fixes, I have enhancements to both that greatly assist my workflow. For example, in git-gui, I have a hotkey that pastes the currently highlighted pathname into the commit message. In gitk, I have added "find all files in commit" to the file list pane, and fixed the flawed regex matching and associated controls. My workflow involves a lot of large rebases, and merge conflicts can occur in the middle of them that affect dozens of files, that need editing to resolve. That's where easily being able to start an editor from git-gui in that situation would benefit my workflow. But, it's not a big deal. Now, to specific comments you made: > I don't > think there is any way of finding out the default terminal emulator in > Linux, and I don't think there is a standard way of making terminal > emulator launch programs you want. I agree where you say there is no "standard way", because the various GUI environments are not consistent (Gnome, LXDE, etc) and neither are the command line arguments of various terminal emulators, and sometimes those don't work as expected. > So your suggestion works only for GUI based editors. We would have to > mention that only GUI based editors can open files. Here, I disagree. My suggestion was to provide a double-click facility that would trigger a command that can be *configured by the user*. And it is wrong to say that only GUI editors can open files. For example, my OS is Debian, my GUI is LXDE, and my terminal emulator is lxterminal. (I don't recommend it, but that's another story). If I have a terminal window open, I can type the command: $ lxterminal -e vi foo and a new independent terminal window opens with the editor 'vi' editing the file foo. Similar functionality can be achieved from a .desktop file, or from a shell script. Here is a demo Tcl script (working here) that confirms one way of spawning an editor from Tcl in a terminal window under LXDE: ##### begin script ##### #!/usr/bin/tclsh package require Tk # name of this script set scriptname [info script] # demo user command set command "lxterminal -e vi -R $scriptname" # create text widget pack [text .t] # add text to show that we are running .t insert end "$scriptname: Running: $command\n" # run the demo command set chan [open "| $command"] # (at this point, a new terminal window appears # containing vi displaying this script file) # add text to show that we did not block on command .t insert end "$scriptname: Reached end\n" ##### end script ##### ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-15 3:41 ` David @ 2019-09-16 17:49 ` Pratyush Yadav 0 siblings, 0 replies; 13+ messages in thread From: Pratyush Yadav @ 2019-09-16 17:49 UTC (permalink / raw) To: David; +Cc: Git Mailing List On 15/09/19 01:41PM, David wrote: > On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav <me@yadavpratyush.com> wrote: > > On 15/09/19 02:07AM, David wrote: > > > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg <bert.wesarg@googlemail.com> wrote: > > > > > I consider adding a second way as not not acceptable. I also consider > > > > double-click on a file in a GUI an "open" action. > > > > > > Yes! > > > > > > In fact, I've often fantasized how useful it would be that if I double > > > clicked on that file name in the unstaged pane or the staged pane, > > > then that would open the file for editing in my preferred/configured editor. > > > > > > Now for me *that* would be a very frequently used improvement! > > > > > > I wonder what other readers think about this idea? > > > > Sounds reasonable. I've wanted something similar, but for commit > > messages. > > > > But one major reason I didn't come up with a patch for editing commit > > messages in the editor of your choice is terminal based editors. > > Hi again Pratyush Yadav, and other readers! > > I hope I don't sound like I am arguing or enthusiastically promoting change > in this subthread. I'm not, my attitude is rather just to explore an idea to see > what others think of it. Some days I have good ideas, other days my ideas > have flaws that I missed, so I like to discuss first. > > More important, I want to say that I am very happy to see that there are > folks interested to discuss the Tcl/Tk git GUI tools. In fact I have local Tcl > patches myself, bugfixes and enhancements for git-gui and gitk, which I > would be happy to share except that I do not know how to do that effectively. > > I don't enjoy Tcl and because of that I have avoided it and don't consider > my skill level to be very high. I find it rather obtuse, especially the way > it does namespacing, and "upvar" in particular. I struggle to read it without > comments. But I learned enough of Tcl specifically to improve aspects > of git-gui and gitk that were bothering me in the past. I have quite the opposite experience with Tcl. I've been a C person for a long time, and was never a big fan of scripting languages. But I have been enjoying hacking in Tcl. But I do agree that some parts of Tcl are rather strange, and not easy for readability. I'd be happy to look at your enhancements, and try to fine tune the code, but I would point out that some things might just be too specific to your workflow, and won't work for the rest of the people using git-gui. So do take that into account if you do decide to send some improvements in. > As well as bug fixes, I have enhancements to both that greatly assist > my workflow. For example, in git-gui, I have a hotkey that pastes the > currently highlighted pathname into the commit message. In gitk, > I have added "find all files in commit" to the file list pane, and fixed > the flawed regex matching and associated controls. FYI, I'm not the maintainer of gitk. So patches for it should be sent to Paul Mackerras <paulus@ozlabs.org>. > My workflow involves a lot of large rebases, and merge conflicts can occur > in the middle of them that affect dozens of files, that need editing > to resolve. That's where easily being able to start an editor from git-gui > in that situation would benefit my workflow. But, it's not a big deal. > > Now, to specific comments you made: > > > I don't > > think there is any way of finding out the default terminal emulator in > > Linux, and I don't think there is a standard way of making terminal > > emulator launch programs you want. > > I agree where you say there is no "standard way", because the > various GUI environments are not consistent (Gnome, LXDE, etc) and > neither are the command line arguments of various terminal emulators, > and sometimes those don't work as expected. > > > So your suggestion works only for GUI based editors. We would have to > > mention that only GUI based editors can open files. > > Here, I disagree. My suggestion was to provide a double-click facility > that would trigger a command that can be *configured by the user*. > > And it is wrong to say that only GUI editors can open files. > For example, my OS is Debian, my GUI is LXDE, and my terminal > emulator is lxterminal. (I don't recommend it, but that's another story). > If I have a terminal window open, I can type the command: > $ lxterminal -e vi foo Ah! I have used this many times (for gnome-terminal), but for some reason it didn't occur to me to have a customizable editor command. FWIW, I am in favor of something like this being used in git-gui. > and a new independent terminal window opens with the editor 'vi' > editing the file foo. Similar functionality can be achieved from a > .desktop file, or from a shell script. > > Here is a demo Tcl script (working here) that confirms one way > of spawning an editor from Tcl in a terminal window under LXDE: > > ##### begin script ##### > #!/usr/bin/tclsh > > package require Tk > > # name of this script > set scriptname [info script] > > # demo user command > set command "lxterminal -e vi -R $scriptname" > > # create text widget > pack [text .t] > > # add text to show that we are running > .t insert end "$scriptname: Running: $command\n" > > # run the demo command > set chan [open "| $command"] > > # (at this point, a new terminal window appears > # containing vi displaying this script file) > > # add text to show that we did not block on command > .t insert end "$scriptname: Reached end\n" > > ##### end script ##### If you would volunteer to send patches implementing something like that, I would be happy to review. As for me doing it myself, I can't really say if or when I can get to it. I have limited time available, and there are some other things I'd rather do first. -- Regards, Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 14:32 ` Pratyush Yadav 2019-09-13 20:27 ` Bert Wesarg @ 2019-09-13 21:53 ` Marc Branchaud 2019-09-14 15:57 ` David 2019-09-14 7:24 ` Johannes Sixt 2 siblings, 1 reply; 13+ messages in thread From: Marc Branchaud @ 2019-09-13 21:53 UTC (permalink / raw) To: Pratyush Yadav, Allan Ford; +Cc: git On 2019-09-13 10:32 a.m., Pratyush Yadav wrote: > On 13/09/19 12:24PM, Allan Ford wrote: >> Dear Git Authors, >> >> Not a bug, but a suggestion consideration for “Git Gui” >> >> Can a double click on the file name in the “unstaged” area move the >> item to “staged changes” .. (rather than having to click on the small >> icon to the left of the file name?) > > It has been something on my radar for some time. Shouldn't be something > too difficult to do. > > While I like the idea in general, I have a question that I'd like to ask > other git-gui users: > > If we implement something like this, what happens when you single-click > on the icon? Do we treat that as a stage/unstage command? If we keep the > legacy behaviour of single-click on the icon stages/unstages, then a > part of the row is single-click and the rest double-click. > > If we make an entire row of the stage/unstage widget double click, it > messes with people who are already used to it. > > Is partial single and partial double click behaviour acceptable? Or > should we make the entire row double click only? Or something else that > I missed? I've always felt this was a bit of user-experience failure on git-gui's part. Single-click should not behave differently just because you click the icon. I've seen many new git-gui users find this (mildly) confusing. I'd be happy if the click behavior was consistent across the entire row: single-click to select, double-click to stage/unstage, and there's nothing special about clicking the icon. I personally don't think it would be hard to adjust to that. I guarantee you that if double-click support is added while preserving the icon-single-click, users will get tripped up when they double-click the icon and accidentally stage two files. M. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 21:53 ` Marc Branchaud @ 2019-09-14 15:57 ` David 2019-09-14 21:23 ` Pratyush Yadav 0 siblings, 1 reply; 13+ messages in thread From: David @ 2019-09-14 15:57 UTC (permalink / raw) To: git list On Sat, 14 Sep 2019 at 08:07, Marc Branchaud <marcnarc@xiplink.com> wrote: > On 2019-09-13 10:32 a.m., Pratyush Yadav wrote: > > On 13/09/19 12:24PM, Allan Ford wrote: > >> Not a bug, but a suggestion consideration for “Git Gui” > >> Can a double click on the file name in the “unstaged” area move the > >> item to “staged changes” .. (rather than having to click on the small > >> icon to the left of the file name?) > > It has been something on my radar for some time. Shouldn't be something > > too difficult to do. > > While I like the idea in general, I have a question that I'd like to ask > > other git-gui users: Thank you for asking. > I've always felt this was a bit of user-experience failure on git-gui's > part. Single-click should not behave differently just because you click > the icon. > I've seen many new git-gui users find this (mildly) confusing. I acknowledge that consistency is an important aspect of GUI design. Particularly for new and/or low-competency users. But surely efficiency must also be valued too. Repetitive strain injury is not nice. I have some days where I have hundreds or possibly even thousands of such single clicksto stage and unstage items. Currently it is possible to review and accumulate them efficiently due to how that pane responds. And this seems a very small aspect to learn. if a person is so "confused" by such a small thing to learn, I wonder what hope they would have to comprehend git itself. > I'd be happy if the click behavior was consistent across the entire > row: single-click to select, > double-click to stage/unstage ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please, no. I can't say it strongly enough. Please do not change stage/unstage to require double-click. This would be most unwelcome here, unless it comes with a configuration option to preserve the old behaviour. Maybe the actual problem is that the present icon (perhaps surprisingly) has the behaviour of a blank check-box that relocates. I don't wish for any change, but if the desire for change is irresistable then the simplest solution is for the icon (that appears to the left of filenames in the unstaged pane) to be replaced with blank check box that behaves exactly as the current icon does. That is: When clicked, it becomes a checked-box alongside the filename in the staged area. And if that staged-checked-box is clicked, it reverts to an unchecked-box (instead of the icon) in the unstaged pane. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-14 15:57 ` David @ 2019-09-14 21:23 ` Pratyush Yadav 2019-09-15 3:42 ` David 0 siblings, 1 reply; 13+ messages in thread From: Pratyush Yadav @ 2019-09-14 21:23 UTC (permalink / raw) To: David; +Cc: git list On 15/09/19 01:57AM, David wrote: > On Sat, 14 Sep 2019 at 08:07, Marc Branchaud <marcnarc@xiplink.com> wrote: > > On 2019-09-13 10:32 a.m., Pratyush Yadav wrote: > > > On 13/09/19 12:24PM, Allan Ford wrote: > > > >> Not a bug, but a suggestion consideration for “Git Gui” > > > >> Can a double click on the file name in the “unstaged” area move the > > >> item to “staged changes” .. (rather than having to click on the small > > >> icon to the left of the file name?) > > > > It has been something on my radar for some time. Shouldn't be something > > > too difficult to do. > > > > While I like the idea in general, I have a question that I'd like to ask > > > other git-gui users: > > Thank you for asking. > > > I've always felt this was a bit of user-experience failure on git-gui's > > part. Single-click should not behave differently just because you click > > the icon. > > > I've seen many new git-gui users find this (mildly) confusing. > > I acknowledge that consistency is an important aspect of GUI design. > Particularly for new and/or low-competency users. But surely > efficiency must also be valued too. Repetitive strain injury is not > nice. I have some days where I have hundreds or possibly even > thousands of such single clicksto stage and unstage items. Currently > it is possible to review and accumulate them efficiently due to how > that pane responds. > > And this seems a very small aspect to learn. if a person is so > "confused" by such a small thing to learn, I wonder what hope they > would have to comprehend git itself. > > > I'd be happy if the click behavior was consistent across the entire > > row: single-click to select, > > double-click to stage/unstage > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please, no. > > I can't say it strongly enough. Please do not change stage/unstage > to require double-click. This would be most unwelcome here, unless it > comes with a configuration option to preserve the old behaviour. > > Maybe the actual problem is that the present icon (perhaps surprisingly) > has the behaviour of a blank check-box that relocates. I don't wish for > any change, but if the desire for change is irresistable then the > simplest solution is for the icon (that appears to the left of filenames > in the unstaged pane) to be replaced with blank check box that > behaves exactly as the current icon does. That is: > When clicked, it becomes a checked-box alongside the filename in > the staged area. And if that staged-checked-box is clicked, it reverts to > an unchecked-box (instead of the icon) in the unstaged pane. Hmm, I like this idea. But right now the icons also show the state of the file (modified, added, etc.), so if you switch them to a checkbox you lose that information. Are you and other people willing to lose that information. Though I've personally never been a huge fan of those icons. They never really managed to convey too much meaning to me. So I won't mind changing them to something like the single-letter git-status status flags. This also gives us a bit of consistency with git-status's flags, so people used to the command line will recognize them instantly. Thoughts? -- Regards, Pratyush Yadav ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-14 21:23 ` Pratyush Yadav @ 2019-09-15 3:42 ` David 0 siblings, 0 replies; 13+ messages in thread From: David @ 2019-09-15 3:42 UTC (permalink / raw) To: git list On Sun, 15 Sep 2019 at 07:24, Pratyush Yadav <me@yadavpratyush.com> wrote: > On 15/09/19 01:57AM, David wrote: > > I can't say it strongly enough. Please do not change stage/unstage > > to require double-click. This would be most unwelcome here, unless it > > comes with a configuration option to preserve the old behaviour. > > > > Maybe the actual problem is that the present icon (perhaps surprisingly) > > has the behaviour of a blank check-box that relocates. I don't wish for > > any change, but if the desire for change is irresistable then the > > simplest solution is for the icon (that appears to the left of filenames > > in the unstaged pane) to be replaced with blank check box that > > behaves exactly as the current icon does. That is: > > When clicked, it becomes a checked-box alongside the filename in > > the staged area. And if that staged-checked-box is clicked, it reverts to > > an unchecked-box (instead of the icon) in the unstaged pane. > > Hmm, I like this idea. But right now the icons also show the state of > the file (modified, added, etc.), so if you switch them to a checkbox > you lose that information. Are you and other people willing to lose that > information. > > Though I've personally never been a huge fan of those icons. They never > really managed to convey too much meaning to me. So I won't mind > changing them to something like the single-letter git-status status > flags. This also gives us a bit of consistency with git-status's flags, > so people used to the command line will recognize them instantly. > Thoughts? Ah, this is hilarious and embarassing. It confirms what I wrote in my other message: Some days I have good ideas, other days my ideas have flaws that I missed, so I like to discuss first. ie, Some days I'm an idiot! I completely forgot about those other icons! I like them! In particular, the one that indicates removed files, and the special one that indicates when a committed file has been replaced by a symlink, or vice versa, are very valuable to me. I don't really want any of this to change. I only suggested the change because I didn't want to appear totally negative. So I tried to come up with an alternative suggestion. But it was a dumb proposal. So dumb in fact that I'm now arguing against it :( Oh well :D Anyway, I'm a fan of those icons, please don't change them. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” 2019-09-13 14:32 ` Pratyush Yadav 2019-09-13 20:27 ` Bert Wesarg 2019-09-13 21:53 ` Marc Branchaud @ 2019-09-14 7:24 ` Johannes Sixt 2 siblings, 0 replies; 13+ messages in thread From: Johannes Sixt @ 2019-09-14 7:24 UTC (permalink / raw) To: Pratyush Yadav; +Cc: Allan Ford, git Am 13.09.19 um 16:32 schrieb Pratyush Yadav: > Is partial single and partial double click behaviour acceptable? Or > should we make the entire row double click only? Or something else that > I missed? I don't mind adding the suggested double-click action, but removing the single-click action would be a step backward IMO. -- Hannes ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-09-16 17:49 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-13 2:54 Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” Allan Ford 2019-09-13 14:32 ` Pratyush Yadav 2019-09-13 20:27 ` Bert Wesarg 2019-09-13 21:06 ` Pratyush Yadav 2019-09-14 16:07 ` David 2019-09-14 19:08 ` Pratyush Yadav 2019-09-15 3:41 ` David 2019-09-16 17:49 ` Pratyush Yadav 2019-09-13 21:53 ` Marc Branchaud 2019-09-14 15:57 ` David 2019-09-14 21:23 ` Pratyush Yadav 2019-09-15 3:42 ` David 2019-09-14 7:24 ` Johannes Sixt
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).