GNOME Bugzilla – Bug 307304
Ability to modify GtkEntry invisible char in gtkrc
Last modified: 2008-10-02 18:33:04 UTC
I propose the ability to set GtkEntry::invisible_char = 0x2022 for • in password entry boxes. It makes sense to be able to set this in a theme as opposed to per application. Ta
I think it makes sense, I can cook a patch to add a style property for it in GtkEntry if the Gtk+ developers agree :)
I don't see how a theme author would know what fonts you have installed on your system. *** This bug has been marked as a duplicate of 83935 ***
So basically Owen you are marking my suggestion as a duplicate of a bug that has been open and inactive 3 years because you don't see how a theme author would know what fonts you have installed? That bug suggests a default. I am suggesting a configurable option. If a theme breaks your password boxes because you have 30 year old fonts, then I think there are issues you need to resolve elsewhere.
What I'm saying is that I think the way forward here is to make it automatically detected when appropriate and possibly emulated when appropriate. Many fonts don't have that bullet take a look around. If it *was* generally available everywhere, then the right thing to do is even simpler: just change the default. You actually probably meant a GtkSetting rather than a style property (GtkSettings are global config options) but I can't see why the user should worry about configuring this either. Let's try WONTFIX this time ...
How am I supposed to turn on bullets then? A theme is the *obvious* place.
OK here is a checklist of fonts installed on my system with a working bullet: Andale Mono Arial Arial Black AR PL KaitiM Big5 AR PL KaitiM GB AR PL Mingti2L Big5 AR PL SungtiL GB Baekmuk Batang Baekmuk Dotum Baekmuk Gulim Baekmuk Headline Batang Bitstream Charter Bitstream Vera Sans Bitstream Vera Sans Mono Bitstream Vera Serif Century Schoolbook L Clean ClearlyU ClearlyU Alternate Glyphs ClearlyU PUA Comic Sans MS Courier Courier 10 Pitch Courier New Cursor Dingbats Fixed Georgia Gulim Impact Kochi Gothic Kochi Mincho Luxi Mono Luxi Sans Luxi Serif MelbourneSerial MelbourneSerial-Light MelbourneShadow Monospace Newspaper Nimbus Mono L Nimbus Roman No9 L Nimbus Sans L Standard Symbols L Tahoma Times New Roman Trebuchet MS URW Bookman L URW Chancery L URW Gothic L URW Palladio L Utopia Verdana And those without: Webdings
U+2022 doesn't actually look very good for a password bullet, systems that I'm aware of that use a bullet use a larger one such as the U+25FC suggested in bug 83935. A theme is certainly not the appropriate place for configuration of something like this ... you apparently have a strong preference for password bullets ... do you want to be restricted to only having that in *your own theme* and be restricted from using any other theme?
Yes. A theme describes the way all the other controls look, why not GtkEntry, too? I possibly agree with using the black circle, but it wouldn't bloody matter if I could set it in my theme, anyway!
Owen, you are right about U+25FC not being in all fonts, but 2022 is, IMO, much nicer anyway - and as far as I can tell it is in every font anyway 'cause it's part of ASCII. I can't get my head around why you think a "theme" shouldn't allow you to "theme" password box behaviour. Perhaps it is the DIY culture that UNIX has traditionally been associated with... maybe you /like/ putting every last thing together yourself, but I'd wager most people just want an out of the box theming system much like Windows. Windows theming has one up on the GNOME metatheming system by allowing you to set backgrounds and fonts, too. If you see someone's desktop that you like, you generally need to do like 5 different things to emulate it. Doesn't have to be like that! :@ I'd like to distribute my theme in a single file but when I have to say, "oh, and to get password bullets you need to patch GTK and recompile it" it's just another kick in the teeth. Sorry if this seems hostile, I am just getting annoyed that we are still using * in GTK 2.8. It looks so f***ing 1998! :P
Mac OS X actually uses U+2022 "•" for it's password masking character - for the record.
If the theme sets a character that I don't have, then I can not use that theme, change my font, or file it as a bug against the theme. In any case, this isn't GTK+'s problem. Allowing me to set it in my personal .gtkrc file *is* valuable. It also provides a good reason for application developers to NOT change their default. We're already starting to see some applications default to BULLET, others to BLACK CIRCLE... That's not a good path to head down.
You could also alter the theme's gtkrc file to change the password character if you still wanted to use it.
OK, patch coming up. • Added invisible_char_explicit to the bitfield in "gtk/gtkentry.h". • Defaults to FALSE, any calls to set_invisible_char set this to TRUE. • Install "invisible-char" style property. • Procedure in style_set checks the flag, and determines whether or not to apply the style property. Applications that explicitly set the invisible character on a GtkEntry widget will not be overridden by the style property. Example gtkrc line for BLACK CIRCLE: GtkEntry::invisible_char = 0x25CF Enjoy!
Created attachment 55264 [details] [review] Patch against gtk+-2.8.7 Patch against gtk+-2.8.7 to add support for a GtkEntry::invisible_char gunichar style property. This allows you to choose a password field masker with gtkrc.
The code in gtkentry.c that draws the widget's text contents when in invisible mode could be hacked to check if the current invisible_char has a glyph in the current font, and resort to * if not. That's beyond my ability though.
Created attachment 55383 [details] [review] Patch against gtk+-2.8.8 Brought patch up to date. Cheers.
Reopening. I've done the work - if you don't appreciate it, WONTFIX it.
Personally, I don't think it's the applications business to set a masking character. I believe gtk_entry_set_invisible_char() should be deprecated. Either GTK+ should handle this automatically, or (even better) it should use * and themes should be able to override it. If the theme has set one, I don't think the application's call to gtk_entry_set_invisible_char() should be honored (because once that's deprecated, we can safely assume it's only being called because the application predates the theme customization option). I like the idea of themes being able to set U+2022 (my personal favorite), U+25FC (which a lot of others seem to like), U+0000 (which would probably need to be special-cased, but the idea being that no echoing should be done), or any other character they choose. I think it's very bad for user-interface consistency to have each application able to set its own masking character. Given that we can't even agree on U+2022 vs U+25FC (and applications are using both), this doesn't seem like a case where GTK+ can pick the Right Answer. That means we should defer to the themes.
One more thing... If the concern is that users can set a character that's not available in their font, I would say, "Who cares?" They set it, they can change the setting. If the problem results from their theme setting a character that's not in the font the user chose, the user can choose a new font, harass the theme maker into changing it, or simply override the theme in their own ~/.gtkrc-2.0. I don't think theme makers are going to set anything super crazy, but if they do, that's their fault. Given that the user can override, it seems like a non-issue. If it's necessary to get this concept accepted, we could check the character set against the font. If it doesn't exist, we simply don't honor it (falling back to the default of *).
More and more apps are starting to set this explicitly... we need to nip this in the bud ASAP. After all - what's worse, themes instructing Gtk to use ● or applicatons hard coding it?
FYI we've set the invisible character to 0x25cf in Gaim. I think I chose 0x25cf over U+2022 because 0x25cf seemed bigger and fluffier, and who doesn't like things that are fluffy? The change is only in the 2.0.0 betas and not Gaim 1.5.0, but that's still a pretty wide audience--maybe around 40,000 people? So far I do not believe we've had ANY complaints from people about the invisible character. I feel sometimes you have to be willing to break things to make progress. I'm in favor of changing the invisible character to something other than an asterisk. I think the change would help make the Linux desktop just a tiny bit friendlier, and I think that's worth possibly breaking people using old/incomplete fonts.
*** Bug 335677 has been marked as a duplicate of this bug. ***
I actually don't know how to patch this in to the newer versions of Gtk... sorry...
So it seems distro maintainers are now just doing their own thing. Fedora Core 5 includes a Gtk patched for 2022 "bullet" and Ubuntu with 25CF "black circle"... GDM is hardcoded to set it to 25CF via a configuration option, and Gaim is unconditionally hardcoded for 25CF.
This bug is dangling. Can we review the situation and agree on what to do, now?
Can a maintainer please put this bug out of its misery. I'm starting to care less and less, as pretty much all GTK distributions are hardcoding a patch for proper bullets in anyway. Quite a bad situation, but we don't want it in a style property then it would seem that this is the way it's going to be! I'll hack the patch up again if we accept this bug, otherwise let's just kill it. Thanks! Merry Christmas! :D
I think that a lot of distro builder will apply your patch, if you review it. Few Points for this patch. Linux: In debian gtk depends on pango pango depends on libfontconfig1 libfontconfig1 depends on fontconfig-config and fontconfig-config depends on ttf-dejavu | ttf-bitstream-vera | ttf-freefont | gsfonts-x11 | msttcorefonts And all of them seems to have 0x2022, 0x25cf and even 0x26ab (which I, personally, prefer) And IMO all linux distros recommend simillar fonts Windows: users allways has msttcorefonts with this chars MacOSX: the same story So what is the problem? gtk-devs agreed to change ABI (2.10), which caused far more problems than this patch will cause (even Custom Widgets, which inherited style from gtk entry (SeahorseSecureEntry) can be themed, so developers won't need to override default)
The patch breaks ABI by introducing a "guint invisible_char_explicit : 1;" to the GtkEntry struct, which is a non-starter. I'll see if I can come up with another way to solve this (maybe using GtkSettings or GObject private data), as I'd like to be able to set the invisible character from my MS-Windows theme, to match what MSFT uses.
There's already a GtkEntryPrivate struct in gtkentry.c
Created attachment 79505 [details] [review] Patch to add gtk-invisible-char as a GtkSetting and use it in GtkEntry Matthias suggested using a GtkSetting instead, so I've attempted to hack this up. I've added an invisible_char_set_explicitly flag to GtkEntryPrivate, which defaults to FALSE and is set TRUE when set_invisible_char is called. gtk_entry_get_invisible_char has been modified to check this flag and return the invisible_char set in GtkEntry or look up the GtkSetting for "gtk-invisible-char" whenever appropriate. All references to GtkEntry->invisible_char have been replaced with calls to get_invisible_char. Some comments maybe need updating to reflect the new behaviour. Review, please!
The new setting should have a doc comment essentially duplicating the blurb, maybe adding some more verbosity regarding the relation to the entry property of the same name, and adding a "Since: 2.12" tag. It might be clearer to untangle the relationship between the property and the setting, by turning the explicit flag into a regular boolean property "invisible-char-set". You can look at GtkCellRendererText for examples of such boolean -set properties and how they relate to the actual property. Doing that would also solve the "can't go back to the setting" problem, by allowing you to set the -set property back to FALSE.
I had considered this, but wanted to avoid an API change so that this could be put into the next 2.10 release. Is that an unreasonable request?
I don't think this will go into 2.10
Can't we just change the default to bullet?
There have been a discussion in old bug 83935 It seems that this symbols (0x2022, 0x25cf, 0x26ab) look very different with ifferent fonts (at least for me 0x25cf looks too small and I'm using 0x26ab). I'm not a gentoo user, and don't want to recompile gtk every time when new version appears (I have rather old PC) The biggest problem is not here :) A lot of programs hardcode symbol in their code. IMO gnome-screensaver behaves better than others: if ('*' == gtk_entry_get_invisible_char(GTK_ENTRY(entry))) /* change default invisible char here */ And second problem: a lot of glade files has hardcoded values for invisible char (in most cases it is simply '*') bug 393173
Created attachment 111516 [details] [review] Added docs and invisible-char-set I updated the patch and added documentation as well as an invisible-char-set property for GtkEntry as suggested by Matthias.
I think once we can agree on the new setting, I would even like to deprecate the current _set_invisible_char because I don't see why one would need it if the invisible character can be modified globally. However I may overlook a valid usecase so I would leave that question as a follow-up.
I like the idea of deprecating the current _set_invisible_char. Consistency between applications is a good thing, and I can't think of a good reason for an application to change the invisible character.
Let's not get carried away. Some people need to be able to turn off echoing altogether (i.e. set it to 0x00) for their security confidence. I still think this would have been better as a GtkRc setting. :(
> Some people need to be able to turn off echoing > altogether (i.e. set it to 0x00) for their security confidence. If this is true (and I don't have a position on that), you still said "people" not applications. If someone needs this, then they need it system-wide, not per-application. That's not a reason to keep _set_invisible_char.
It's a trade-off between convenience and confidence. Some GtkEntry's are more important than others, and deprecating set_invisible_char removes the ability for an application to implement a policy. Again, this wouldn't be a problem with GtkRc.
I don't think we should stablish differences in password importance, whatever it is for, and IMHO leaving such difference in application developers' hands is an error. If a user is security sensitive enough to want to disable any feedback, maybe the best way would be adding an Xsetting. Adding a style property would be less evident to modify, besides the problem of theme developers not knowing at all which fonts will be available.
They don't need to know what fonts are available. This is what Deja Vu is for.
I second the password importance not being anything that a particular developer is supposed to decide. If a system is running in a security sensitive place it makes sense to hide the password character, but that is not something that is relevant only to specific programs. Incidentally I don't think Deja Vu can be assumed to be available on all platforms.
Deja Vu is *supposed* to be the Unicode fallback for Freetype. If it's not on your platform... well get it on your platform.
Created attachment 112871 [details] [review] Implement gtk-invisible-char, deprecate entry accessors This patch implementes gtk-invisible-char and gtk-invisible-char-set. gtk_entry_{set,get}_invisible_char is deprectated. If the settings values change notify callbacks adapt the changes accordingly. Feedback is welcome, I'd like to solve this bug within this year. :)
I believe this was more or less obsoleted by 2008-09-19 Carlos Garnacho <carlos@imendio.com> Bug 83935 – GtkEntry's default invisible char should be U+25CF * gtk/gtkentry.c (find_invisible_char) (gtk_entry_init): Find a more suitable invisible char than '*' based on the used font. (gtk_entry_class_init) (gtk_entry_set_property) (gtk_entry_get_property): Add a "invisible-char-set" property. (gtk_entry_unset_invisible_char): New function, needed now that the default invisible char isn't fixed. * gtk/gtkentry.h: * gtk/gtk.symbols: * docs/reference/gtk/gtk-sections.txt: Add the new function. Reopen if you disagree
Should gtk_entry_set_invisible_char() be deprecated? If so, should it be made a no-op function?