Re: Bikeshedding the invisible-char
On Mon, 19 Jan 2009 20:07:09 -0600 Federico Mena Quintero feder...@novell.com wrote: I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: Do you have any numbers on the glyph coverage of these two characters in a variety of common fonts? Are either of them glaringly missing anywhere? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Dienstag, den 20.01.2009, 11:59 +0100 schrieb Christian Dywan: Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. I wonder if the default password character shouldn't be a style property. In that case you could use big circles for the default theme, small circles for monospaced themes and pumpkins or skulls for Halloween themes. Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Regards, Yu On Mon, 2009-01-19 at 20:07 -0600, Federico Mena Quintero wrote: Fedora has a (currently unapplied?) patch in its gtk2 package which changes GtkEntry's invisible-char defualt from * to • (Unicode 0x2022 BULLET). openSUSE has a patch that changes the invisible-char to ● (Unicode 0x25CF BLACK CIRCLE). I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: * The circle is bigger. This goes hand in hand with Christopher Alexander's Nature of Order principles of Strong Centers, Good Shape, and Contrast. * The circle is fatter. We should have a no-discrimination policy against Unicode glyphs with an above-average body mass index, I mean, the ink-to-area ratio. * The circle is BIGGER. Size does matter, you know. * I started the bikeshed. Really, it doesn't make sense to carry around patches like these :) OK to commit? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Federico Mena Quintero wrote: openSUSE has a patch that changes the invisible-char to ● (Unicode 0x25CF BLACK CIRCLE). What happens when the current font is missing that character? Will it try to find another font that has it, or will there be a manual fallback that uses '*' instead? The square-with-hex-numbers isn't a great fallback :-/ . * The circle is fatter. We should have a no-discrimination policy against Unicode glyphs with an above-average body mass index, I mean, the ink-to-area ratio. However, there are some who believe (as a result of meticulous research) that a larger ink-to-area ratio increases the risk of certain health problems. I don't think we want our users to suddenly start dropping from their chairs due to heart attacks. * The circle is BIGGER. Size does matter, you know. [insert self-deprecation here], you insensitive clod! -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
On Tue, 2009-01-20 at 04:14 +0200, Xan Lopez wrote: How is this different from bug http://bugzilla.gnome.org/show_bug.cgi?id=83935 that was committed some months ago? It even uses your favorite character! Argh, I'm an idiot. As usual, Garnacho created the perfect patch. What happened is that someone asked me, why is openSUSE's patch not upstream yet?, and I looked... the patch is basically invisible_char = g_object_create_property (invisible-char, - *, + ●, but I didn't RTFS to see the new find_invisible_char() magic :) Sorry about the noise, Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
