Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Oct 1, 2006, 18:41 UTC
- Message-ID
- <200610012041.15296.jnareb@gmail.com>
- In-Reply-To
- <7v64f9hku2.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Sep 2006, Junio C Hamano wrote:
> If the only objection is that it is harder to realize that the > remaining one (the other one that did not get removed by this > redundancy elimination) is clickable, maybe that is what needs > to be fixed.
But that is plain impossible without compromising interface usability. Let me explain.
In the case of tree view (directory listing) we have blobs (files and symlinks) and trees (directories). To mark item unequivocably as link it has to have default link color (blue) and default link decoration (underline). That means that we cannot distinguish really well (at least color) between tree and blob entries. I'd rather have redundant "blob"/"tree" (self)links, clearly marked as links, and tree entries using link decoration (blue, underlined) while blob entries have default text decoration (black, no underline).
In the case of shortlog/log/history/heads/tags view, to clearly mark subject/title of a commit or tag as link, we would have to use default link decoration. Let's for a while abandon link-within-link, i.e. using some of committags also in commit title (in shortlog/history view)... But underlined text is harder to read, and blue underlined text even more so (as for example it is hard to read italics, commonly used for emphasis). I'd rather have additional "commit" link, clearly marked as link, and leave subject as is, as hidden link, as a shortcut.
I think that redundancy in a visual interface (and not only visual, as seen in the example of Perl programming language) is a good idea, contrary to the redundancy in code or data (database).
-- Jakub Narebski Poland