gitk with hyperspace support

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.

On Wed, 17 Aug 2005, Paul Mackerras wrote:

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

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

			Linus

Paul Mackerras <paulus@samba.org> writes:

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.

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

On Wed, August 17, 2005 2:58 am, Junio C Hamano said:

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

Hi, Sean wrote:

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.

Junio C Hamano 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?

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

Thanks, Paul.

Paul Mackerras <paulus@samba.org> writes:

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.

Junio C Hamano writes:

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.

Paul Mackerras <paulus@samba.org> writes:

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

On 8/30/05, Paul Mackerras <paulus@samba.org> wrote:

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.

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

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

On 9/1/05, Sean <seanlkml@sympatico.ca> wrote:

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.

Hi, Paul Mackerras wrote:

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.