[PATCH] paper: use monospace font for parents and children cset id's

Adrian Buehlmann adrian at cadifra.com
Sat Apr 30 01:12:41 CDT 2011


On 2011-04-26 22:04, Adrian Buehlmann wrote:
> On 2011-04-26 21:48, Matt Mackall wrote:
>> On Tue, 2011-04-26 at 21:11 +0200, Adrian Buehlmann wrote:
>>> On 2011-04-26 21:03, Kevin Bullock wrote:
>>>> On Apr 25, 2011, at 5:25 PM, Adrian Buehlmann wrote:
>>>>
>>>>> On 2011-04-25 23:52, Matt Mackall wrote:
>>>>>> On Mon, 2011-04-25 at 23:33 +0200, Adrian Buehlmann wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Adrian Buehlmann <adrian at cadifra.com <mailto:adrian at cadifra.com>>
>>>>>>> # Date 1303760080 -7200
>>>>>>> # Node ID 399c59a799585be1fbbef12759c062ebe0c52193
>>>>>>> # Parent  da65edcac72af707922917d912ae1969495206d0
>>>>>>> paper: use monospace font for parents and children cset id's
>>>>>>
>>>>>> The rationale for this isn't obvious to me.
>>>>>>
>>>>>
>>>>> It's a matter of taste (as ususal with these things).
>>>>>
>>>>> https://bitbucket.org/abuehl/downloads/downloads/paper-parents-pre.PNG
>>>>> https://bitbucket.org/abuehl/downloads/downloads/paper-parents-post.PNG
>>>>>
>>>>> IMHO, it looks confusing if the changeset hashes don't end at the same x
>>>>> coordinate. It almost looks like they are not the same number of
>>>>> characters.
>>>>
>>>> If you're going to show the cset ids in monospace, I'd expect e.g. the
>>>> changed filenames to also be in monospace (they're computer
>>>> identifiers). ..
>>>
>>> I think the filenames are fine as they are.
>>>
>>>>> Bitbucket shows all cset ids as monospace as well.
>>>>
>>>> ...right next to the commit message, where it makes some stylistic sense
>>>> (to me anyway). But _all_ the metadata in the commit summary box is
>>>> shown in monospace. And this may well have been done simply because
>>>> GitHub did it that way first, rather than any solid design or usability
>>>> reason.
>>>>
>>>> I'm -1 on the change, but it wouldn't break my heart. :)
>>>
>>> The status quo breaks my eyes. Each time I see the child cset much
>>> shorter or longer it feels like there's bug because it looks like short
>>> csets suddenly start having random lengths.
>>>
>>> But well. It might be just me.
>>
>> Well I definitely see what you're talking about. It mostly seems to be
>> an issue with kerning on fs and 1s and it looks like it takes a couple
>> of them to make a column's difference, and it seems to pop up noticeably
>> every 5-10 csets. In the extreme, "ffffffffffff" is about half as long
>> as "666666666666" when I experiment with Firebug, though "111111111111"
>> is the same length in my default font. Apparently Vera is designed so
>> that numbers come out evenly-spaced, but not hex.
>>
>> So we could make these monospaced for consistency. But then the design
>> consistency hobgoblins would pressure us to make author, date, and files
>> monospaced. And let's face it: monospaced is not as nice to read,
>> generally speaking. So given a choice between the way it is currently,
>> mixed fonts, and all monospaced, I think I favor the status quo.
> 
> Fair enough.
> 
> For completeness sake, I just uploaded a screenshot of veracity's [1]
> "vv serve" [1] (I just happened to have recently compiled it on Windows,
> since they don't yet offer binaries).
> 
> https://bitbucket.org/abuehl/downloads/downloads/veracity-serve1.PNG
> 
> They use non-monospaced font for the hashes *but* they don't use
> column-like layout for hashes.
> 
> (FWIW, they use a truckload of JavaScript. <unrelated>And they tag in a
> separate DAG)
> 
> [1] http://www.sourcegear.com/veracity/ (warning: not GPL! :-)

Two more examples just for the archives (as this change has already been
turned down):

== RhodeCode ==
https://hg.rhodecode.org/moin-remote/changeset/d3b415b655
changeset ids in monospace

== Kiln ==
Kiln shows the changeset id's in monospace as well, with the labels in
*non-monospace* font.

https://bqb.kilnhg.com/Repo/Public/Mercurial/dirstate/History/6f548f28defe

My personal opinion: The fogcreek guys definitely know (among many other
things) how to make nice looking web pages. FWIW, they seem to be quite
successful at attracting Mercurial related web traffic to *their*
gardens (Disclosure: I'm completely unrelated to that company.)




More information about the Mercurial-devel mailing list