[was: question in Rev 5f2e71ec6bc8] On 01.10.2009 20:08, Steve Borho wrote: > On Thu, Oct 1, 2009 at 12:32 PM, Adrian Buehlmann <adr...@cadifra.com>wrote: >> On 01.10.2009 17:57, Steve Borho wrote: >>> I'm wondering whether the 'new' filter is now redundant. It should be >>> perfectly obvious which changesets are new. >> +1 >> >> I'm contemplating doing something like: >> >> diff --git a/tortoisehg/hgtk/logview/treemodel.py >> b/tortoisehg/hgtk/logview/treemodel.py >> --- a/tortoisehg/hgtk/logview/treemodel.py >> +++ b/tortoisehg/hgtk/logview/treemodel.py >> @@ -168,6 +168,8 @@ class TreeModel(gtk.GenericTreeModel): >> color = self.color_func(ctx.parents(), revid, author) >> if revid in self.wcparents: >> sumstr = bstr + tstr + '<b><u>' + summary + '</u></b>' >> + elif revid >= self.origtip: >> + sumstr = '<b>*</b> ' + bstr + tstr + summary >> else: >> sumstr = bstr + tstr + summary >> >> though. >> >> I often have the graph turned off. >> >> For example, "hide merges" is only available if the graph is turned off. >> Not wanting to see merge csets is common for branchy repos. >> >> The green color alone as an indication for new csets might be a bit weak >> then. Often, ui gurus recommend not to code information into color alone, >> because there are people who have problems to discern colors. >> > > It would be great to encode the three status values (in, out, new) in the > summary if the graph is disabled.
Sounds interesting. We could make up some pseudo tags. But the sheer amount of tags might start to get annoying/confusing sooner or later (but maybe its probably mostly all those mq tags that start to annoy me). Another variant would be to create a new column, explicitly showing the status for each cset, using plain plain texts "incoming", "outgoing" or "new". Or just the shorter "in", "out" and "new". Then that column could be hidden by the user if he doesn't want to see it. And inserted where he wants it. > We would just need to pass the graph > column status to the treemodel. > The treemodel initializer is getting too large. It's probably time to give > the class keyword options. Another question is why was that info put in the graph in the first place. It might have looked sexy seeing it for the first time, but: The graph should be about ancestry info. Adding "in, out, new" info there might be the wrong place anyway. Specifically, since the graph is an optional element. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop