git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <me@yadavpratyush.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Allan Ford <allan.ford17@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes”
Date: Sat, 14 Sep 2019 02:36:21 +0530	[thread overview]
Message-ID: <20190913210621.tzeq73vpi7iaapd3@yadavpratyush.com> (raw)
In-Reply-To: <CAKPyHN0=AHzr1V35PDzsq02aeGK1e54CxTeunED_u6GRUygkuA@mail.gmail.com>

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

  reply	other threads:[~2019-09-13 21:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190913210621.tzeq73vpi7iaapd3@yadavpratyush.com \
    --to=me@yadavpratyush.com \
    --cc=allan.ford17@gmail.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).