git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "GitList" <git@vger.kernel.org>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Pat Thoyts" <patthoyts@users.sourceforge.net>,
	"Alexey Astakhov" <asstv7@gmail.com>
Subject: Re: [PATCH v2 4/4] git gui: allow for a long recentrepo list
Date: Thu, 17 Dec 2015 20:09:25 -0000	[thread overview]
Message-ID: <1CAD7B4439DF4AE19EE8CD56CB47F399@PhilipOakley> (raw)
In-Reply-To: xmqqsi30c1lk.fsf@gitster.mtv.corp.google.com

From: "Junio C Hamano" <gitster@pobox.com>, December 17, 2015 7:32 PM
> Philip Oakley <philipoakley@iee.org> writes:
>
>> The gui.recentrepo list may be longer than the maxrecent setting.
>> Allow extra space to show any extra entries.
>>
>> In an ideal world, the git gui would limit the number of entries
>> to the maxrecent setting, however the recentrepo config list may
>> have been extended outside of the gui, or the maxrecent setting changed
>> to a reduced value. Further, when testing the gui's recentrepo
>> logic it is useful to show these extra, but valid, entries.
>
> I do not have a strong objection either way, but the magic number 5
> smells like an indication that this is solving a wrong problem or
> solving a problem in a wrong approach.  What happens to the entries
> beyond $maxrecent-th in the recent list with the current code?  The
> list effectively truncated and not shown?  Wouldn't the same thing
> happen to the entries beyond ($maxrecent+5)-th in the recent list
> with your patch?

True, it was a magic number selected as being a moderate overspill 
allowance.
I tried 3 and 5 as possible values, and 5 didn't look ungainly, even on my 
small netbook, and covered all my test hacking cases.

The issue was that the prior code assumed that the fault could never happen 
and limited the display, which is sorted, to the max value, so in a fault 
condition the most recent repo could fall off the bottom.

As a bit of 'monkey patching' I wasn't sure how the dialog creation could 
know in advance how long the list would be, so I simply added on a small 
margin.

>
> Truncating the list at $maxrecent-th to match the display
> (i.e. declare that "$maxrecent" is really the max number of entries
> we would keep track of), or allowing the UI to scroll so that
> entries beyond $maxrecent-th one can be shown, perhaps?

This would certainly be a reasonable approach, but I don't know enough of 
the tcl to know how to make it happen. If anyone has suggestions...

>
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> word usage corrected.
>> Eric's comments $gmane/282432
>> ---
>>  git-gui/lib/choose_repository.tcl | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-gui/lib/choose_repository.tcl 
>> b/git-gui/lib/choose_repository.tcl
>> index ad7a888..a08ed4f 100644
>> --- a/git-gui/lib/choose_repository.tcl
>> +++ b/git-gui/lib/choose_repository.tcl
>> @@ -153,7 +153,7 @@ constructor pick {} {
>>  -background [get_bg_color $w_body.recentlabel] \
>>  -wrap none \
>>  -width 50 \
>> - -height $maxrecent
>> + -height [expr {$maxrecent + 5}]
>>  $w_recentlist tag conf link \
>>  -foreground blue \
>>  -underline 1
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2015-12-17 20:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 23:58 [PATCH v2 0/4] Fix git-gui when recentrepo list has duplicates Philip Oakley
2015-12-16 23:58 ` [PATCH v2 1/4] git-gui: de-dup entries from gui.recentrepo Philip Oakley
2015-12-16 23:58 ` [PATCH v2 2/4] git gui: cope with duplicates in _get_recentrepo Philip Oakley
2015-12-16 23:58 ` [PATCH v2 3/4] git gui: de-dup selected repo from recentrepo history Philip Oakley
2015-12-16 23:58 ` [PATCH v2 4/4] git gui: allow for a long recentrepo list Philip Oakley
2015-12-17 19:32   ` Junio C Hamano
2015-12-17 20:09     ` Philip Oakley [this message]
2015-12-17 22:11       ` Philip Oakley
2015-12-17 22:40         ` [PATCH v3 " Philip Oakley
2015-12-17 23:29           ` Junio C Hamano
2015-12-18  0:26             ` Philip Oakley

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=1CAD7B4439DF4AE19EE8CD56CB47F399@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=asstv7@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=patthoyts@users.sourceforge.net \
    --cc=sunshine@sunshineco.com \
    /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).