gitk with hyperspace support

gitk with hyperspace support

[Paul Mackerras]

I have been trying a new approach to drawing the commit graph in gitk.
This involves sending a lot of the really long lines into
"hyperspace", by terminating them with an arrow pointing down when the
graph gets too wide, and then reintroducing them later with an arrow
pointing up, as though they had used a warp drive to dive beneath the
screen (into the mysterious 3rd dimension :) and then reappear later.
The result is that the graph stays at a reasonable width and doesn't
need to be compressed.

My reasoning is that it is the local short-range connections which are
interesting and informative.  The long-range connections aren't really
visually informative; if you want to know about the long-range
connections, the parent and child lists in the details pane are much
more useful.

I would like to get some feedback about what people think of the
visual effect of this new approach, and in particular whether having
the lines jump into hyperspace loses information that people find
useful.  The new version is at:

http://ozlabs.org/~paulus/gitk/gitk.hs

If the reaction is positive I'll check this into my gitk.git
repository.

Thanks,
Paul.

Re: gitk with hyperspace support

[Linus Torvalds]

On Wed, 17 Aug 2005, Paul Mackerras wrote:
> 
> I would like to get some feedback about what people think of the
> visual effect of this new approach, and in particular whether having
> the lines jump into hyperspace loses information that people find
> useful.

Me likee. Maybe some knob to tune how eagerly this happens?

> The new version is at:
> 
> http://ozlabs.org/~paulus/gitk/gitk.hs

".hs" made firefox think it was haskell. Confusing ;)

			Linus

Re: gitk with hyperspace support

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> My reasoning is that it is the local short-range connections which are
> interesting and informative.  The long-range connections aren't really
> visually informative; if you want to know about the long-range
> connections, the parent and child lists in the details pane are much
> more useful.

Correct.

The new output looks a lot less cluttering and I like it very
much, but it is confusing to me on one count.  I clicked one
arrowhead pointing downward, expecting that the pane would jump
scroll to show the counterpart arrowhead, and was dissapointed
that it did not happen.  I could click the "Parent" link at that
point, but then the upward arrow was above and outside the
visible portion of that pane, which broke visual continuity and
I lost track at that point.  I think my being color challenged
exacerbated the resulting confusion; otherwise I could have
probably found the line with the same color as the color of the
downarrow I clicked.

> http://ozlabs.org/~paulus/gitk/gitk.hs

I first thought you rewrote it in Haskell ;-).

Re: gitk with hyperspace support

[Sean]

On Wed, August 17, 2005 2:58 am, Junio C Hamano said:
> Paul Mackerras <paulus@samba.org> writes:
>
>> My reasoning is that it is the local short-range connections which are
>> interesting and informative.  The long-range connections aren't really
>> visually informative; if you want to know about the long-range
>> connections, the parent and child lists in the details pane are much
>> more useful.
>
> Correct.
>
> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count.  I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed
> that it did not happen.  I could click the "Parent" link at that
> point, but then the upward arrow was above and outside the
> visible portion of that pane, which broke visual continuity and
> I lost track at that point.  I think my being color challenged
> exacerbated the resulting confusion; otherwise I could have
> probably found the line with the same color as the color of the
> downarrow I clicked.

This change looks really good in gitk and clicking on an arrowhead to hop
to the corresponding arrowhead would sure be great too.  There's may be a
way to further reduce the line clutter too; once a line is terminated with
an arrowhead, it could often be trimmed back much further.

For instance looking at Linus' tree:

  03938c3f1062b0f279a0ef937a471d4db83702ed
  powernow-k8 requires that a data structure for

The line flowing from this commit extends ~200 more commits downward
before it is finally terminated with an arrowhead.   It would be nice if
this line could be made shorter, such that the arrowhead was drawn much
closer to commit in question.

Cheers,
Sean

Re: gitk with hyperspace support

[Matthias Urlichs]

Hi, Sean wrote:

> The line flowing from this commit extends ~200 more commits downward
> before it is finally terminated with an arrowhead.   It would be nice if
> this line could be made shorter, such that the arrowhead was drawn much
> closer to commit in question.

Good point. The arrowheads tend to get lost otherwise; in my tree, the
problem is even worse since the downward-pointing arrow (drawn in grey) is
directly below a horizontal line connecting two unrelated changes -- which
is *also* grey.  That makes the actual arrowhead perceptually invisible.

If the arrow appears directly below a node, you don't get that problem.

Another point I just noticed: The arrows should be directly below
each other, if at all possible; i.e. the one pointing up should be in the
same column as the corresponding arrow pointing down.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Money is the root of all evil, and man needs roots.

Re: gitk with hyperspace support

[Paul Mackerras]

Junio C Hamano writes:

> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count.  I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed

OK, you're the second person to ask for that, so I'll see what I can
do about it.  I can think of 3 possible behaviors when you click on
the arrowhead:

1. scroll to bring the other arrowhead on-screen and briefly make it
   larger or something similar to draw attention to it

2. scroll to bring the other arrowhead on-screen and warp the pointer
   to it

3. select the next commit in the indicated direction which is a child
   or parent that the line connects (scroll to make it visible,
   highlight it, show its diff).

Which do you think would be best?

> > http://ozlabs.org/~paulus/gitk/gitk.hs
> 
> I first thought you rewrote it in Haskell ;-).

Hmmm, maybe it's apache on ozlabs.org that is under that
misapprehension?

Thanks,
Paul.

Re: gitk with hyperspace support

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> OK, you're the second person to ask for that, so I'll see what I can
> do about it.  I can think of 3 possible behaviors when you click on
> the arrowhead:
>
> 1. scroll to bring the other arrowhead on-screen and briefly make it
>    larger or something similar to draw attention to it
>
> 2. scroll to bring the other arrowhead on-screen and warp the pointer
>    to it
>
> 3. select the next commit in the indicated direction which is a child
>    or parent that the line connects (scroll to make it visible,
>    highlight it, show its diff).
>
> Which do you think would be best?

Hmph.  I think, aside from being color challenged, the primary
source of confusion for me was that the lines with arrowheads
were too long, and the node and the arrowhead did not fit within
the height of the graphical pane, at least with my window
configuration.

I wonder if not having downward or upward arrows for a long
stretch would work better.  Lose the vertical line for such
hyperspace links, and instead have a horizonal short line with
arrowheads to denote that there are also hyperspace lines coming
into or out of that node.  That way you can save one column for
a vertical line, and my preference for clicking on such an
arrowhead would be #3 from the above.

Re: gitk with hyperspace support

[Paul Mackerras]

Junio C Hamano writes:

> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count.  I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed
> that it did not happen.

Try now... :)

It also makes the current graph line thicker now, so it's easier to
pick out where the line you clicked on goes.

Paul.

Re: gitk with hyperspace support

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> It also makes the current graph line thicker now, so it's easier to
> pick out where the line you clicked on goes.

Very nice, and quite helpful for colour challenged ones.
Thanks.

Re: gitk with hyperspace support

[Alex Riesen]

On 8/30/05, Paul Mackerras <paulus@samba.org> wrote:
> 
> Try now... :)
> 
> It also makes the current graph line thicker now, so it's easier to
> pick out where the line you clicked on goes.
> 

That's a fine feature :)

BTW, did you sometimes notice lines you can't click at all?
An example is the red line on the most left side of the graph
by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
It goes from blue up-arrow  through green left bump to the grey
down-arrow (on my system in the kernel tree). Clicking on the blue
arrow (on the line, not the arrow itself) will turn the blue line stricken-
through with the red line (a bold blue line with a red streak inside),
the next click leaves me with with just bold blue line and broken
red line above it.

It's on Gentoo's Tcl/Tk 8.4.9.

Re: gitk with hyperspace support

[Sean]

On Thu, September 1, 2005 4:10 pm, Alex Riesen said:

> That's a fine feature :)
>
> BTW, did you sometimes notice lines you can't click at all?
> An example is the red line on the most left side of the graph
> by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
> It goes from blue up-arrow  through green left bump to the grey
> down-arrow (on my system in the kernel tree). Clicking on the blue
> arrow (on the line, not the arrow itself) will turn the blue line
> stricken-
> through with the red line (a bold blue line with a red streak inside),
> the next click leaves me with with just bold blue line and broken
> red line above it.

For what it's worth, everything near that SHA1 works here as expected.  
Although I wasn't able to follow what you meant by "blue up-arrow through
green left bump..." etc.   But all the lines respond to being clicked and
all the arrow heads in that area properly jump to their corresponding
commit.

That's with the latest checked out version of git and tcl/tk 8.4.9 as well.

Sean

Re: gitk with hyperspace support

[Alex Riesen]

On 9/1/05, Sean <seanlkml@sympatico.ca> wrote:
> > BTW, did you sometimes notice lines you can't click at all?
> > An example is the red line on the most left side of the graph
> > by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a.
> For what it's worth, everything near that SHA1 works here as expected.
> Although I wasn't able to follow what you meant by "blue up-arrow through
> green left bump..." etc.   But all the lines respond to being clicked and
> all the arrow heads in that area properly jump to their corresponding
> commit.
> 
> That's with the latest checked out version of git and tcl/tk 8.4.9 as well.

I just tested it on another system (8.4.6, Slackware 10+), and it works
correctly too. Probably it is Gentoo's (or mine, you never know in Gentoo)
Tcl/Tk, which is broken somewhere.

Re: gitk with hyperspace support

[Matthias Urlichs]

Hi, Paul Mackerras wrote:

> http://ozlabs.org/~paulus/gitk/gitk.hs
> 
Unfortunately, this fails on my git-plus-assorted-crap archive:

can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such element in array
can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such element in array
    while executing
"if {$mainlinearrow($id) ne "none"} {
	    set mainline($id) [trimdiagstart $mainline($id)]
	}"
    (procedure "drawcommitline" line 44)
    invoked from within
"drawcommitline $dlevel"
    (procedure "drawmore" line 65)
    invoked from within
"drawmore 1"
    (procedure "drawcommit" line 33)
    invoked from within
"drawcommit $id"
    (procedure "getcommitlines" line 50)
    invoked from within
"getcommitlines file23"


Another problem: when I click on a line, I get the parent and *all* its
children, not just the child(ren) on the other end of the segment I was
clicking on.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
There are some micro-organisms that exhibit characteristics of both plants
and animals.  When exposed to light they undergo photosynthesis; and when
the lights go out, they turn into animals.  But then again, don't we all?