Re: git-gui: automatically move focus to staged file before typing commit message?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/09/19 09:55AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
> 
> On Sat, Sep 14, 2019 at 11:15 PM Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> wrote:
> > Why should it only happen when the commit message widget is selected?
> > What's wrong with directly switching focus when all the files are
> > staged?
> >
> > What I have in mind is once there are no more files to stage, the focus
> > directly goes to the staged files section, and the first staged file
> > gets selected. Then if you want you can type in the commit message. And
> > conversely, when unstaging things, once all files are unstaged, the
> > focus goes directly to the unstaged files section.
> 
> Your questions are fair. My reasoning: I imagine it could be a bit
> frustrating that the focus automatically goes away from the "Unstaged
> Changes" widget, when the user actually isn't done doing changes.

I suppose a similar argument can be made against your suggestion though. 
When a user clicks on the commit message buffer, they did one thing: 
click on the buffer. They did not click on any diff. So, wouldn't it be 
disorienting for them if their action of clicking the commit message 
buffer also switches the diff view?

I'm not arguing in favour or against your suggestion, I just want to 
consider all angles/viewpoints before going forward.
 
> For instance (as a user);
> - Do some changes
> - Stage the changes (no more unstaged changes in the repo)
> - Realize that you forgot something, jump back to the IDE and make
> some more changes
> - Jump back again to git-gui, hit refresh
> In this scenario, I imagine the user would want to have focus kept on
> the "Unstaged Changes" widget. Even if it became empty with files
> before.
> 
> When the user focus the "Commit Message" widget, the user is kinda
> stating "I'm done staging stuff for now". And when that happens, it
> really doesn't make sense to show a blank diff any more.

Makes sense. But I'm not sure if this would be beneficial to other 
git-gui users. I'd like to hear about what other people think about this 
change.

-- 
Regards,
Pratyush Yadav



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux