GNOME Bugzilla – Bug 96744
Escaped keys are not unescaped
Last modified: 2018-07-01 08:39:35 UTC
gnome-terminal or gconf, I'm not sure, but filing gnome-terminal as it's the module the problem can be produced from. Run a gnome-terminal in ja_JP.eucJP locale, and create a new profile with a Japanese name, and save. cd to $(HOME)/.gconf/apps/gnome-terminal/profiles, a directory like @4294967267@@4294967169@@4294967170@ has been created. Run a gconf-editor, and go to apps->gnome-terminal->profile, this @4294.. appears.
The profile name still appears correctly in the GUI, right? The user-displayed profile name is stored separately. gconf keys can't be UTF-8, they are just an ASCII subset. The profile name there is what happens if you feed UTF-8 to gconf_escape_key(). I think if we changed the gconf_escape_key() format it would probably be an incompatible change, so though the format is a little bit silly, I don't think we really want to change it.
Yes, the profile name appears properly in gnome-terminal GUI. But in gconf-editor, it shows a garbled folder name, which does not look quite nice. Attaching a snapshot...
Created attachment 11813 [details] garbled gnome-terminal profile
Can gconf-editor restore a UTF-8 name back from the gconf_escape_key() format, then?
Hmm, interesting question. gconf-editor could maybe take a guess. There's no way to know whether a key is escaped or not though.
mmm... Then, can gconf-editor replace a holder name with any likely-visible gconf key entry when one can be found? But, I'm asking this without knowing if - gtk treeview has such handler or not - such gconf key entry is always possible or not [if only gnome-terminal, "visible_name" could be used, but wishing if any generic one...] Please advise...
Havoc, Using gconf_unescape_key() when putting a new node into gtk_tree and gconf_escape_key() when calling gconf_client seems to fix the problem. A patch will be attached shortly. Will you please review the patch?
Created attachment 12110 [details] [review] unescape gconf key for GUI and escape it again for gconf_client
And changing product to gconf-editor.
Anders is really the right person to review, this is his code.
Anders, okay to commit to the HEAD?
anders, wake up ;)
Could someone please look at this patch?
Someone should really CC Anders on this one. The patch still applies cleanly.
Committed
This patch breaks tow things: * keys with "@" inside (bug #135807) * keys with "." inside (bug #136400) So I'm going to revert it and maybe we should try another patch for unescaping keys with only "@" and numbers.
Rverted now. I'll let the bug opened until we have a sane way to unescape keys (gconf_client_key_is_escaped new gconf function?)
Comment on attachment 12110 [details] [review] unescape gconf key for GUI and escape it again for gconf_client This patch will need more work, like doing some heuristics to guess if the key should be tried to escape
gconf-editor is not under active development anymore and has not seen code changes for six years. Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf-editor/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.