gitk lower pane (commit and files view) scrollbar extends past gitk window

In gitk from the current 'next' branch, post git version 1.4.0 (blob ba4644f) scrollbar for lower pane, i.e. for commitdiff and files (Comments) views extends past the bottom of the gitk window. Therefore I cannnot see lower part of commit diff if it is larger than window height.

gitk window has height lower than 700.

The upper pane, i.e. history graph scrollbar is correct, and works as it should.

This is regression from git 1.3.0, where gitk works correctly.

Below ascii art trying to describe situation.

  _                                _                                  _
  ^  .. upper scrollbar arrow .... ^                                  ^
  #                                #                                  |
  #  .... position indicator ..... #                                  |
  |                                |                                  |
  |                                |    scrolling past window edge -> #
  |      bottom of gitk window --> =                                  =
  v                                  <-- no lower scrollbar arrow
  =  <-- bottom of gitk window

Jakub Narebski wrote:

Yes, and the search field at the bottom is invisible too. Removing line 431:

        .ctop conf -width $geometry(width) -height $geometry(height)

seems to fix it and the window still gets the right size.

Ciao, ET.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>

---

 gitweb/gitweb.cgi |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

82c8812870e9c40fd495e9c3e2eae0eb78ac2759

I'm sorry, wrong In-Reply-To given to git-send-email. It should be reply to <7vu06exfym.fsf@assigned-by-dhcp.cox.net>

Jakub Narebski <jnareb@gmail.com> writes:

My copy from "next" has this part like the following:

		if (!defined $searchtext) {
			$searchtext = "";
		}
		my $search_hash;
		if (defined $hash) {
			$search_hash = $hash;
		} else {
			$search_hash  = "HEAD";
		}

I thought we were both reasonably sure that we are now in sync... I could apply it by hand but once I start doing that I'm afraid we will never converge.

It's quite frustrating.

Are you sure you want to do "my $rss two-spaces equal space"?

I've fixed up the whitespace you missed and will be applying the following on top of what is in "next" tonight.

-- >8 -- gitweb: do not align assignment = with extra whitespaces

---

Junio C Hamano wrote:

I'm very sorry, I forgot that I applied Timo Hirvonen patch

  "[PATCH] gitweb: Start search from HEAD"
  (<20060620152515.23e59396.tihirvon@gmail.com>)
  http://permalink.gmane.org/gmane.comp.version-control.git/22197>

on top of 'next'.

This patch fixes search quite nicely, reducing significantly number of error messages during search (e.g. starting search from blob or file view).

Any reason not to apply it?

My idea for coding style is to align assignment = with extra whitespaces, but only where aligned assignments statements are one after another.

The above "my $rss" example was mistyped as " = " instead of " = ", but I think it was meant to be aligned at '='. IMHO aligning at assign makes code more readable.

But that is just my opinion.

Jakub Narebski <jnareb@gmail.com> writes:

I remember discussing things with Timo and was putting it on hold since I knew you were also actively futzing on gitweb.

But I think what you have is this one instead:

Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>

I applied it in jn/gitweb topic and then applied your whitespace fixes on top of the result, after discarding the whitespace cleanup I sent out earlier. So let's make sure we are resync'ed and continue from here. I'll push out the updated "next" soonish.

Junio C Hamano wrote:

So when I apply someone else patches should I reply to the post with patch I have applied with

  Acked-by: Jakub Narebski <jnareb@gmial.com>

to notify of that fact?

Jakub Narebski <jnareb@gmail.com> writes:

Acked-by does not mean you've applied it to your tree, and even if it did, it is unfair to expect me to remember that fact when I review your patch later. In this particular case, a note in the patch to say it depends on such and such that _I_ do not seem to have yet would have been more appropriate.

Acked-by would also be helpful when a de-facto owner of the code wants to push acceptance of others' patches, but that is independent from stating what a patch's prerequisites are.

Anyhow, I've reviewed Timo's patch (which made sense to me too), and your whitespace fixes and pushed out the result, which hopefully will be propagating to the mirrors soon. Overall, I would say that the clean-up on gitweb so far is reasonably straightforward. I have been running "next" version of gitweb on my private machine and haven't found regression.

I'll go to bed now.  Thanks for the patches.

Junio C Hamano wrote:

Is the 'note' extension to commit header implemented yet? It it is,then it would be nice if git-am recorded original email message-ids in the note header. Usually it is of no interest to user, so it should be hidden by default.

Jakub Narebski <jnareb@gmail.com> writes:

I put it at the end of the commit message, like the Signed-of-by lines. And, yes, it would be nice if git-am would add it (--message-id flag?). If more people is interested I'll try to send a patch.

        Santi

On 6/22/06, Edgar Toernig <froese@gmx.de> wrote:

No, it does not. It gets the default geometry, not the one it had last time.

Alex Riesen wrote:

Now I see. It is the case when I used gitk from a computer with a desktop with larger screen height, then on computer with screen height smaller than gitk height was I had mentioned problem.

Workaround for now is to delete old geometry info from ~/.gitk file (or just delete whole file).

I don't know Tcl/Tk to make proper fix, i.e. check if restored size is not larger than available screen size, and use min(saved size, screen size). Another improvement would be to save the fact that gitk window is maximized as a symbol, e.g. as equivalent of

  set geometry(height) screen(height)

in ~/.gitk

It looks like gitk incorrectly saves the geometry in ~/.gitk I have to remove it before running gitk (well, it would be enough to remove geometry section).