Re: Improved git-gui blame viewer

["Shawn O. Pearce" <spearce@spearce.org>]

Martin Waitz <tali@admingilde.org> wrote:
> 
> 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.