Adrian Buehlmann wrote: > Horizontal layout of radio buttons is not recommended: > http://msdn.microsoft.com/en-us/library/aa511488.aspx > As such I would lean towards keeping it as is (checkbox) in this particular > case we have here. The single checkbox also uses lesser space, compared > to two horizontal radio buttons.
It does, but I don't agree that it's better in this case. Recommendations and guidelines *are* just that, and there can be exceptional cases where it makes sense to not follow them strictly. Also, what else do we need the horizontal space for? Two radio buttons would presumably still fit. > If it were in a dialog box with enough vertical space, then I would prefer > using radio buttons. But then, the radio buttons would have to be laid out > vertically. Aren't we talking about the repository explorer, or are we talking about a dialog box that opens on performing some action? In the latter case, I have missed that. I am arguing the former case, at any rate. I would be fine with a vertical layout of radio buttons, but since there are only two, I think a horizontal would be cleaner in this case. > As such the filter bar is setting a somewhat bad precedent here > (although it is not directly comparable, given the more than > two choices the user has there). Yeah, that actually makes it even worse in my book. Having radio buttons with several (>3) options laid out horizontally is not optimal IMHO. But then I don't have a good idea for a viable alternative. > The single checkbox is also acceptable, because the two parents > are not strictly on a par, since normal changesets have only a > first parent and no second parent. The second parent *is* special. > > The second parent can also be seen as the one that is "merged-in", > whereas the first parent usually forms the link back on the current > branch. Well, I only partially agree here. I don't tend to think of normal changesets as having a "first parent", but just a parent. As such, I don't think the radio buttons/check box should be shown at all (not even grayed out) for non-merge changesets. Also, for named branches at least it's true that there is an asymmetry between the two parents, but that's no argument for showing the diff against the first one by default. Also, for merges on the same branch, unless people are using the fetch extension, they tend to merge the other branch into their own, as it makes no difference for the result (apart from the order of the parents, which I bet not many think about). /Sune ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
