GNOME Bugzilla – Bug 791387
Weird uses of GSettings
Last modified: 2017-12-09 09:15:27 UTC
Created attachment 365238 [details] [review] Current weird Dconf Editor patch for supporting Builder. Dconf Editor maintainer here. The work is not finished, but Dconf Editor now supports (even in the “master” branch) relocatable GSettings schemas (thanks to Davi da Silva Böger). Note that flatpaks are not handled correctly, so I’ll talk here for people who install Builder from their distribution. These relocatable schemas are schemas that do not have a given path, it’s the application which decide when running “where” in the settings tree it wants the schema to apply. That means that it is impossible for another application to know exactly how to map these schemas, but we’ve done it by having an internal set of rules for known common schemas, offering also a key for the user to map schemas we don’t know about. And so, I had a look to Builder relocatable schemas. And there are things bugging me, so questions: – Do I correctly map “org.gnome.builder.extension-type” to all folders named “IdeDiagnosticProvider” that are in a subfolder of “/org/gnome/builder/extension-types/”? Why this organisation? – In your “/org/gnome/builder/plugins/”, you have some GSettings with a path mapped, and you also need to map some relocatable schemas, but that only contain a “enabled” key. Why not using an array of string for saving all enabled plugins? (or even, a key with Flags, if the list is self-contained?) Can plugins be manually added by the user? I’m sure the code runs great like it is, but the settings tree that’s resulting of it is hard to understand from an external point of view. Could there be a way to clean it?
The plugin scheme just determines if we should disable a given .so/.py/etc. I didn't want to use an array of strings because at the time I wanted something that is compartmentalized by plugin namespace. The extention-type schema allows us to have a plugin module enabled, but disable a certain plugin interface within it. For example, we can disable just the completion provider from the clang plugin. Every plugin can implement a variety of some 20 plugin interfaces.
(In reply to Christian Hergert from comment #1) > The extention-type schema allows us to have a plugin module enabled, but > disable a certain plugin interface within it. > > For example, we can disable just the completion provider from the clang > plugin. > > Every plugin can implement a variety of some 20 plugin interfaces. Ok, so IIUC, I should map “org.gnome.builder.extension-type” to every subfolder of any subfolder of “/org/gnome/builder/extension-types/” with how it’s done now. But doing it that way, Dconf Editor cannot know about the plugins list before one interface has been enabled or disabled in each one time, and will never know about the available interfaces. That’s a little sad. Why didn’t you use the same “org.gnome.builder.plugin” schema to enable/disable the interfaces? (in a Flags key?) Even if some interfaces would not be available for some of the plugins, that would make things easier to read, no?
(In reply to Arnaud B. from comment #2) > Why didn’t you use the same “org.gnome.builder.plugin” schema to > enable/disable the interfaces? (in a Flags key?) Even if some interfaces > would not be available for some of the plugins, that would make things > easier to read, no? Because I didn't think of doing it that way. I don't exactly like the idea of updating the schema for each plugin interface we add because it makes for untested interactions when going between stable and nightly branches (which people often do for various reasons).
(In reply to Christian Hergert from comment #3) > Because I didn't think of doing it that way. That’s a good reason. ^^’ > I don't exactly like the idea of updating the schema for each plugin > interface we add because it makes for untested interactions when going > between stable and nightly branches (which people often do for various > reasons). There’s a way to do it “correctly” by syncing the old and the new settings for one cycle or so, but that’s not an easy path. Is there a hope that this area of your code could be reworked for other reasons? Is there a way to have a list of possible interfaces by plugin? Can users install their own plugins? If so, is that considered common or not?
(In reply to Arnaud B. from comment #4) > There’s a way to do it “correctly” by syncing the old and the new settings > for one cycle or so, but that’s not an easy path. Is there a hope that this > area of your code could be reworked for other reasons? It's been pretty stable for many releases, so I have no plans to go in and change things. > Is there a way to have a list of possible interfaces by plugin? I don't believe libpeas exposes API for this today, but it could certainly be added. That wouldn't help externally though as we bundle a lot of plugins into the executables. > Can users install their own plugins? If so, is that considered common or not? Yes, however it is not common. I only know of a couple that are not in-tree.
Ok. I’ve pushed the corrected mappings for “plugins”, as there’s no real hope to see that tree improve. Thanks for the explanations!