Re: Improved git-gui blame viewer

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 4, 2007, 08:21 UTC
Message-ID: <20070604082156.GI4507@spearce.org>
In-Reply-To: <20070604073827.GF16637@admingilde.org>

Martin Waitz <tali@admingilde.org> wrote:

Show 9 quoted lines

> 
> On Mon, Jun 04, 2007 at 02:07:20AM -0400, Shawn O. Pearce wrote:
> > >   When clicking on a light gray line to become a green line, then
> > >   adjacent areas are not correctly colored.  A few adjacent entries
> > >   become all same gray... [Look around git-gui.sh:340]
> 
> If you use three colors you can always select one which is different
> to the hunk above and below.  But I don't know if that would be
> visually appealing...

That's actually not a bad idea.  But to make that work I have to
do the coloring by line chunks, not commits.  Given how bad the
current by-commit coloring is, the 3 coloring by line chunks is
probably the best bet.  It would resemble what gitweb does, but
we'd be using 3 colors in git-gui vs. the 2 in gitweb.  We could
do worse.

> Another nice thing would be a smooth gradient for each hunk.
> Then we could use the same colors for every hunk, but the top of each
> hunk would be a little bit lighter/darker than the bottom so that
> it is easy to see the border.  Is that doable in Tk?

I think so, but its ugly. The viewer is actually 4 text widgets crammed next to each other. I can set the background color of a line by giving it a tag, so to do a gradient I have to assign a different background color to each line by giving each line its own tag (ick). Worse, in a 3 line chunk I can only do 3 colors. That fails your "smooth" concept. ;-)

> Perhaps a simple small line between hunks is enough, too?

That would be messy. I can certainly cause a few pixels of spacing to show up between chunks, but I'm reading the data "live" from the blame engine and putting it on screen. Adding space betwen chunks as I get it will cause the data to "reflow" while you are trying to read it. I can probably account for it with the scrollbar and adjust it accordingly, but at some point you will wind up seeing the text in the viewer pane moving around and expanding as the padding gets tossed in.

BTW, I just got the jump-to-original line and restore-view-on-back features that Matthijs was asking about working properly. Apparently a call to Tk's "update" (basically just let Tk pump its event loop) is needed after I've finished reading the file content, but before I adjust the view. Its in my pu branch now (gitgui-0.7.2-58-gf9e96fd).

-- 
Shawn.