[RFC] branchview-NG

Matt Mackall mpm at selenic.com
Tue Jun 17 13:15:47 CDT 2008


On Tue, 2008-06-17 at 19:15 +0200, Dirkjan Ochtman wrote:
> Matt Mackall wrote:
> > The json filter ought to be more generic, and in templatefilters, I
> > think.
> 
> Right. I think Python 2.6 gets a json package in the standard library. 
> Maybe we can import their JSON encoder as a compatibility wrapper? I 
> used a very specific JSON encoder because it needed the least amount of 
> code and I wanted to cut down on the bzr crap. I guess I could also try 
> to write a very simple generic JSON encoder, but I'm not sure we want to 
> maintain our own encoder apart from any other encoders out there.

I think a reasonable JSON encoder can be something like 20-30 lines.

> > The scroll/more/less buttons aren't in keeping with how other log pages
> > work.
> 
> Well, I wanted more/less buttons because it can often be instructive to 
> view larger parts of the graph at once (because you can only see 
> branches for which there is an actual changeset in the given window). 
> I've removed the scroll buttons in favor of shortlog's nav buttons.

The answer may be to add more/less to the other log pages.

> > How does graphmod relate to glog?
> 
> It's offspring. I started off of graphlog.py, but it currently only 
> outputs sparse edges (only those edges directly coming out of a vertex, 
> I think). So I had to change it around a bit to make the edge list 
> complete (graphlog uses separate functions to fix up the graph later), 
> and I changed it to returning changectx's in the items, where graphlog 
> has some incomplete node information (just the rev and short, I think).

Ok, you should probably update glog to use graphmod then.

> > There seems to be an off-by one with diagonal line positioning. They
> > appear to come out of the top of nodes rather than the center.
> 
> I think I managed to fix this. Can you check it again?

Looks good to my eyes.

> > At least with coal, the changeset text and style is not in keeping with
> > the style of the shortlog. Tags are missing.
> 
> I really think the revision graph benefits from having a little more 
> space than the shortlog provides. Also, since the lines don't match up 
> horizontally (which I consider a feature, because you can infer some of 
> the structure from how the text is layed out), having date/user/message 
> on the same line isn't as nice (and the larger fonts would make the 
> horizontal distance longer, making it harder to read). So I think the 
> current looks are alright, but I also think we can change whatever after 
> we get it into crew; I'm aware that my design skills are fairly limited.

It's still inconsistent in that:

- it should probably say "graph" rather than "revision graph"
- it shows the hash (which would probably be better as a tooltip here
and in shortlog)
- it uses a really long date
- it uses the full username
- it's missing the thin ruling lines
- it doesn't have the row coloring (maybe with good reason, but I'd
like to see them)

> > We'll probably eventually want to color by branch name rather than
> > randomly.
> 
> I think this graph helps out most in messiest situations, and those 
> situations occur when you have several heads on the same branch. I also 
> think that many projects still use unnamed branches, and the coloring 
> wouldn't help for them. The current approach has its limits (only 5 
> different colors, I think), but makes the graph a lot clearer 
> (especially where branches cross over other branches).

All true. We could probably expand things so that color was a function
of branch as well though. For instance, everything on branch a would be
blueish, while everything on branch b would be redish.

> > It should also be possible to stylize the drawing per style. For
> > instance, I might want a style that does only gray lines with black
> > squares or diamonds. Or maybe draw it like subway map. Etc. That should
> > be as simple as putting a pair of node/edge javascript callback
> > functions in the page template, no?
> 
> I've done this. graph.html now defines both edge and vertex functions, 
> which accept a couple of relevant arguments and do the actual drawing on 
> the canvas and setting the color and so forth.

Great.

> > Ok, now on to wishful thinking: I can imagine a button on the shortlog
> > page that toggles on a new column with the graph so that a separate page
> > isn't required.
> 
> I've thought about this, but didn't go through with it. If you just have 
> the graph on the left/right and keep the table as is, graph vertices 
> will in some cases be too far away from the changeset message to be able 
> to easily visually connect them. If, on the other hand, you make the 
> text indenting, as it is in my version, which keeps the text closer to 
> the vertices, the table doesn't work too well because it's not really a 
> table layout anymore. Then the HTML would become messy, I think...

Maybe. But at any rate, it should be seen as an alternate view of the
shortlog. In particular, it should have changeset and browse buttons.
Toggling between log and graph should change as little as possible,
visually, at least in the coal and paper styles. That may even mean
dropping the author and date in this view (or moving them to tool tips)
so that everything is one line high.

Gitweb, of course, can be as gaudy as it likes.

Also, FYI, I'm intending to make paper the default theme.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list