After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 83935 - GtkEntry's default invisible char should be U+25CF
GtkEntry's default invisible char should be U+25CF
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.0.x
Other All
: Normal enhancement
: Small feature
Assigned To: gtk-bugs
gtk-bugs
Depends on: 63633
Blocks:
 
 
Reported: 2002-06-03 05:16 UTC by Nicholas Miell
Modified: 2008-09-19 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Demonstration of U+25CF as the invisible character (1.92 KB, image/png)
2002-06-03 05:18 UTC, Nicholas Miell
  Details
[PATCH] Find an appropriate invisible char through pango_layout_get_unknown_glyphs_count(). Fallback to '*' as always if nothing is found. (1.29 KB, patch)
2008-02-28 01:12 UTC, Carlos Garnacho
none Details | Review
updated patch (2.18 KB, patch)
2008-03-06 13:21 UTC, Carlos Garnacho
none Details | Review
updated patch, disables font fallback as suggested by Behdad (2.18 KB, patch)
2008-05-27 12:26 UTC, Carlos Garnacho
needs-work Details | Review
updated patch (7.07 KB, patch)
2008-08-09 16:08 UTC, Carlos Garnacho
committed Details | Review

Description Nicholas Miell 2002-06-03 05:16:50 UTC
The current default invisible character for GtkEntry is '*', which works
fine. However, I think U+25CF BLACK CIRCLE is more asthetically pleasing
and should be the default.

Unfortunately, not all fonts provide a glyph for this character, so you'll
probably need to determine whether the theme's font provides it, and fall
back to the asterisk if U+25CF is not available.
Comment 1 Nicholas Miell 2002-06-03 05:18:00 UTC
Created attachment 8953 [details]
Demonstration of U+25CF as the invisible character
Comment 2 Owen Taylor 2002-06-12 18:38:27 UTC
Related to bug 63633.

The problem is that a lot of fonts don't have this character,
and then you will either get:

 - A box with the unicode code point.
 - A bullet selected from some other font, which might not work
   well.
Comment 3 Owen Taylor 2005-06-11 17:12:36 UTC
*** Bug 307304 has been marked as a duplicate of this bug. ***
Comment 4 Alexander “weej” Jones 2005-11-26 21:13:17 UTC
I think 2022 bullet is nicer.

2022: • vs. 25CF: ●

Windows XP and Mac OS X use a bullet. Black circle looks far too big IMO.

Also, bullet is available in every font. Black circle is not - so there goes
that problem.
Comment 5 Owen Taylor 2005-11-26 22:56:47 UTC
I think you'll find that bullet is not, by any stretch of the imagination,
available in every font; more common than U+25CF perhaps...

My experience is that many fonts have 2022 too small to look good in the
usage; I dont' think XP and OS X actually use a bullet character; or if
they do then they are using particular font choices that have unusually
large bullets.

(But I'd agree that U+25CF is too large.)
Comment 6 Alexander “weej” Jones 2005-11-27 03:40:07 UTC
After playing with some font settings I can see your point.

A patch to add configurability in rc files is on Bug 307304.
Comment 7 Matthias Clasen 2005-11-28 13:55:16 UTC
Maybe we should just draw a suitable bulled ourselves ?
Comment 8 Behdad Esfahbod 2007-09-17 19:36:01 UTC
Or use pango_layout_get_missing_glyph_count() to choose what to use.
Comment 9 Carlos Garnacho 2008-02-28 01:12:00 UTC
Created attachment 106126 [details] [review]
[PATCH] Find an appropriate invisible char through pango_layout_get_unknown_glyphs_count(). Fallback to '*' as always if nothing is found.

 gtk/gtkentry.c |   33 ++++++++++++++++++++++++++++++++-
 1 files changed, 32 insertions(+), 1 deletions(-)
Comment 10 Alexander “weej” Jones 2008-03-03 16:09:35 UTC
Hi Carlos

This patch should handle font changes, too.
Comment 11 Carlos Garnacho 2008-03-06 13:21:48 UTC
Created attachment 106679 [details] [review]
updated patch

Ah, right, added this and some control to avoid setting the char if it has been explicitly set by the user.
Comment 12 Alexander “weej” Jones 2008-03-06 22:00:45 UTC
Seems to do the job, though I am wondering if it would be a better approach to maintain and use an "actual_invisible_char" private variable instead, which can be updated on every style change based upon the "invisible_char" public variable that is set.

That way, even programmer-set invisible characters are checked for their existence in the current typeface, though as a drawback it means you can't have a whole list of preferred characters.

What do you think?
Comment 13 Christian Dywan 2008-05-25 14:13:08 UTC
I tested the patch, it works nicely here.

I don't think there is a need to check characters provided by programmers. If the author of a particular program uses *any* fonts or characters that diverge from defaults he should check that they are actually available and provide fallbacks himself, including the password character, imho.
Comment 14 Behdad Esfahbod 2008-05-25 15:27:11 UTC
The patch should disable font fallback IMO.
Comment 15 Carlos Garnacho 2008-05-27 12:26:24 UTC
Created attachment 111600 [details] [review]
updated patch, disables font fallback as suggested by Behdad

Too bad that with this patch it resorts to BULLET instead of BLACK CIRCLE with bitstream vera sans :), but disabling font fallback makes sense.
Comment 16 Guillaume Cottenceau 2008-07-29 11:14:25 UTC
comment on the latest patch: sorry for nitpicking, but shouldn't 0x002a be removed from invisible_chars, as there is a « return '*' » at the end of find_invisible_char?
Comment 17 Matthias Clasen 2008-08-02 02:52:11 UTC
Patch looks fine to me. 
You may want to fix the nit that Guillaume found.
Also, we need to update the docs in several places: gtk_entry_set_visibility and
gtk_entry_set_invisible_char both mention '*' as default invisible char. They should say that GTK+ picks the best available invisible character from the current font, unless one is explicitly set.
Comment 18 Matthias Clasen 2008-08-02 03:04:54 UTC
Oh, one more little issue: with the patch as is, there is no way to go back to the unset state once you've called gtk_entry_set_invisible_char(). 

I propose to add a boolean property invisible-char-set (you already have that field, anyway). 
Comment 19 Alexander “weej” Jones 2008-08-02 04:09:59 UTC
Go go gadget commit. A seven year old bug yesterday and a six year old one today... on a roll...
Comment 20 Mark Doliner 2008-08-05 08:11:08 UTC
Fantastic!
Comment 21 Carlos Garnacho 2008-08-09 16:08:20 UTC
Created attachment 116236 [details] [review]
updated patch

This patch fixes all the mentioned issues, adds gtk_entry_unset_invisible_char() and the "invisible-char-set" boolean property, and actually disables font fallback, sorry about that
Comment 22 Matthias Clasen 2008-09-18 15:51:49 UTC
The Since tags need updating to 2.16 now, and please add the new functions to gtk-sections.txt too when you are comitting.
Comment 23 Carlos Garnacho 2008-09-19 13:46:08 UTC
Just committed the patch with these changes, thanks!