2009/12/17 Jakub Narebski <jnareb@xxxxxxxxx>: > On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote: >> This is something I've been wanting for a while. There are a number of >> things that don't 'click' with this proof of concept, and I'm coming to >> the list to hear the opinion of users and developers on how to improve >> the thing. >> >> The patch is live at http://git.oblomov.eu/, an example affected page is >> http://git.oblomov.eu/git/shortlog > > You should tell here that one must put mouse over main header (the one > with 'projects / project / action' breadcrumbs) for the new link to be > visible... because I was wondering where is this new link. I mentioned it right below, but I do realize that people might have gone looking for it before reading further down ;-) >> Things that are sure to change: >> >> * the aesthetics and location of the toggle link (it shows on mousehover >> in the title). > > It is not only the question where to put link, but also where to put > the *code* (where the code should belong to). > > At first I thought: WTF? Why the feature that deals with log-like views > is put in very generic and common for all actions/views git_header_html > subroutine? Especially after change that made all loglike views use > common infrastructure of git_log_generic. > > But then I realized that it is specific example of *generic* feature > that deals with extra_options... which admittedly is currently limited > to '--no-merges' only. So if it is put in git_header_html, then all > views with HTML output (which does not include 'atom' and 'rss' actions, > but which actions IIRC have their own handling of '--no-merges') > which have support for extra_options would have ability to turn them > on and off. Exactly. Although the code as it is now is not really flexible enough to handle other cases. I see further down a couple of your ideas would make this kind of thing more extensible. > What you need to add (if this link is to be in git_header_html) is > to create links only when $status == 200, because otherwise the link > would be present also for error pages, which I think is wrong. Good point. That's an easy fix too 8-) >> Other options I've considered are: >> + next to pagination (first | prev | next), either before or after >> the existing entries > > This would fit with the fact that sometimes present "patches" link is on > the line with pagination links, after pagination links. > > But this secondary navigation bar is about other views, and extra_options > is about modifying current view, and functions more like toggles. OTOH > we have such toggle for 'blame' <-> 'blame_incremental' switch in > secondary navigation bar. Well, at least for this particular option the toggle is closer in concept to pagination (which also modifies the 'current' view, in a way). > Also this would mean that each view type would have to handle extra_options > itself, as secondary navigation bar is very much action-specific. Not > that it matters now, with only single '--no-merges' option supported. Even with more options, I have half an idea on how to refactor this handling in a way that should make it easy for views to handle the extra options. >> + on mouseover for the table section that refers to the (short)log; >> this would make it possible to put it summary view too, for example > > This would mean having link inside link, as those headers in summary view > functions as link to 'shortlog' view (quite useful I think), and to the > project summary in the 'shortlog' view itself (I'm not sure how useful > that is). We already have problems with ref markers being links inside > links and having broken layout in some strict XHTML conformance browsers. (I still think that prohibiting link-in-link is idiotic, but this is not the place where this should be discussed) > In short: I am not sure what would be the best solution. Nevertheless > I think that link should be more visible, and perhaps more toggle-like. I'll see if I can cook something up. >> * if you toggle merge view when not on the first page, the reference >> (first) commit in the view is likely to change drastically, which >> causes confusion. I have not found a satisfactory solution for this, >> since the obvious way to 'lock' the view (start paginating from the >> current top commit) prevents prev/next navigation > > Alternate solution would be to clean page (start from 0th page) when > changing to '--no-merges'. > > You would probably need something like 'skip' option, with number of > commits, not number of pages to skip, and/or 'skip_to' which takes > commit-id. But i have not thought about this much... IIRC the log code uses pagination the way it is now because that reflects the git log works. This would make a different approach more time consuming on the script part. >> + >> +*:hover > span.merge_toggle a { visibility:visible } > > I'd rather not have this rule to have different style, i.e. not all > in single line. Unless it is for RFC only... I can make it more like the others. >> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}}); >> + my $has_merges = !grep(/^--no-merges$/, @extra_options); >> + > > Wouldn't it be better to use straight > > + my $no_merges = grep(/^--no-merges$/, @extra_options); > > Because $has_merges is true also for example for 'tree' view... which > absolutely doesn't make any sense whatsoever. The reason why I have two vars is that one checks if we care about the option, and the other is to see if it's enabled or not. We don't want the 'show merges' toggle to appear in view which don't handle the --no-merge option. > In more generic solution (which could be perhaps put in a separate commit) > it could be: > > + my %extra_options = map { $_ => 0 } keys %$allowed_options; > + $extra_options{$_} = 1 foreach @extra_options; > > which means that %extra_options is hash which keys are allowed options, > and which has true value for allowed option which is actually used. I like this approach. It's also easier to extend to other options, if and when we'll have them. I'll try to roll out a new patch with a cleaner design and taking your suggestions into considerations -- Giuseppe "Oblomov" Bilotta -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html