GNOME Bugzilla – Bug 755925
unable to edit gnome-terminal settings
Last modified: 2017-12-06 23:05:45 UTC
With the recent change to use gsettings_schema_list_keys, dconf-editor is now unable to edit the gnome-terminal profile settings. Steps: Navigate to /org/gnome/terminal/legacy/profiles:/:$UUID Actual results: Cannot edit any value in the directory; clicking just brings up a 'No Schema, cannot edit value.' dialogue. The reason is because due to deficiencies in gsettings (bug 622126), gnome-terminal's profile settings have an unusual setup with the profile itself having a relocatable schema (org.gnome.Terminal.Legacy.Profile) but without those profiles (the paths ofwhich cannot be enumerated at schema installation time) being in the global schema as child schemas.
Dconf Editor (in its development “master” branch) doesn’t use GSettings to list/access keys, but as previously the Dconf client. It uses GSettingsSchema to get schemas infos instead of its own parser as before, and doesn’t get relocatable schemas infos for now (and looks like it will be hard, but I’ll try), but that wasn’t the case also in 3.18 and previous releases. I may have missed something, but I’m quite sure this bug is “just” about adding back a way to edit keys even if there’s no understood schema for it. I’ll have a look, It shouldn’t take much time.
If I correctly understood the problem, it’s solved. Thanks for reporting the bug, and don’t hesitate to reopen if I missed something. The current UI, with probably some more change, will be available for the 3.20 release in six monthes.
Yes, that works now, thanks!
Actually, it needs more work: while now you can edit the keys that already have dconf values, it's impossible to edit a value that's in the schema but has not yet been set to dconf, since there's no way to *add* a new key in the directory. To test this, use gnome-terminal's Preferences->Profiles->New to add a new profile, then navigate in dconf-editor to this profile; most keys of the schema won't be set in dconf and thus can't be edited.
That’s basically a limitation of relocatable schemas, from both dconf and glib: you cannot know from a given path what’s the schema that applied to it. And as all the informations are known either from the schemas, or from the modified keys… I’ll let the bug open, but that needs work in the libraries before.
If you could join us here and help sort out this mess: https://github.com/mate-desktop/mate-panel/issues/675 We need someone to explain things. What if you had a key 'schemaid' under the path? Could you then open a schema file for relocatable schemas in dconf-editor? For me - although I'm new to this - this would be the fastest solution. The better solution would be to rewrite stuff in glib/gsettings to save a 'schemaid' key automatically for r.s., so that dconf-editor could check for that and load the schema.
(In reply to info-cppsp from comment #6) > If you could join us here and help sort out this mess: > https://github.com/mate-desktop/mate-panel/issues/675 > > We need someone to explain things. I commented there. But there’s no magic. > What if you had a key 'schemaid' under the path? > Could you then open a schema file for relocatable schemas in dconf-editor? > For me - although I'm new to this - this would be the fastest solution. I don’t do things fast, I always take the time to do things correctly. :·) Anyway, I don’t plan to rely on a convention that applications should implement, more probably to have a mapping of relocatable schemas to various paths (I would have to maintain a default value that covers the usual cases, but there’s not so many things to cover outside the Gnome, Mate, etc. internals, as most applications don’t use so complex things). > The better solution would be to rewrite stuff in glib/gsettings to save a > 'schemaid' key automatically for r.s., so that dconf-editor could check for > that and load the schema. I don’t see for now how it would work for applications (like gnome-terminal) that store profiles to a new place that depends on a “profile-id”. But I plan to offer the solution already described, before starting to think how I should provide a solution in GLib (or dconf). And it’s highly possible that the new GSettings backend promised for managing Flatpaks (replacing dconf, so) will be published (and maybe used) before all that. :·)
'I don’t do things fast, I always take the time to do things correctly.' 'I plan to offer the solution already described, before starting to think how I should provide a solution in GLib' you kinda contradicted yourself there, didn't you? LOL But I see what you mean. Still, it is a solution. Even if you would have your options under a profile-id, in that folder, you would also have a schema-id, that you could use. Well, it seems, as the problem stems from Glib, it should be corrected there. Backends don't matter, as GSettings is above dconf anyway. If there will be the same gchar *key + GVariant *value pairs stored, you will still be able to save the schemaid stuff.
(In reply to info-cppsp from comment #8) > 'I don’t do things fast, I always take the time to do things correctly.' > 'I plan to offer the solution already described, before starting to think > how I should provide a solution in GLib' > you kinda contradicted yourself there, didn't you? LOL Oh no, I didn’t. Patching GLib to register and provide some meta-informations about which application installed which schema doesn’t look really easy, but would be a relatively fast way to correct this bug. But adding meta-information would open other kind of uses, abuses, and related bugs. (And I hate bugs.) Developing first of all a frontend application like dconf-editor allows to define the exact needs, and to see what’s missing for real in the current APIs. It is clearly a slow path for making things move globally, but it’s the only way to allow just enough functions and not too many, to design for what is necessary and not for what is possible (all is, that’s software). > Even if you would have your options under a profile-id, in that folder, you > would also have a schema-id, that you could use. But who will tell me that there’s such a key to lookup at this path, if GLib doesn’t tell me there’s something installed there? Should I use dconf to lookup for all existing keys, searching for “schema-id” ones, when dconf doesn’t even know what a schema is? And what if I’m using a different GLib backend, like the keyfiles one? > Well, it seems, as the problem stems from Glib, it should be corrected there. > Backends don't matter, as GSettings is above dconf anyway. In fact, for what I think now, it’s mainly the opposite. The hard work has to be done in the backend; just because, else, GLib becomes a database of which application uses what, and that would be bad. So, GLib has to tell the backend an id of the application that writes a value, and the backend has to store that information, so that GLib could then only allow the same application to edit this key (or whatever the good policy is there). That’s many lines of code in GLib, but the hard part is designing the backend so that it remains fast. > If there will be the same gchar *key + GVariant *value pairs stored, you > will still be able to save the schemaid stuff. The problem is not for storing, but for finding it back after.
DConf Editor now supports mapping some relocatable schemas to some paths –it has an internal list for usual ones (that is hardly complete for now… but that contains Terminal profiles), and some can be manually added. Work is being done on bug 762803; some things need improvements, but looks like it will improve to a good level before next stable release. So I’m closing (again) this bug, as that’s roughly fixed, and it doesn’t help to have two bugs opened. Thanks for bug reporting!