On 01/29/2013 11:01 AM, Tanu Kaskinen wrote: > On Tue, 2013-01-29 at 09:02 +0100, David Henningsson wrote: >> On 01/22/2013 10:43 PM, Tanu Kaskinen wrote: >>> Hi all, >>> >>> GConf is deprecated. We have a bug that asks us to convert to GSettings: >>> https://bugs.freedesktop.org/show_bug.cgi?id=57743 >>> >>> As I have written in the bug, I don't really want to move to GSettings. >> >> So far, I'm agreeing with you. >> >> But can we take a step back? I want it to be easy to debug the >> configuration and why a specific module is loaded. >> >> And you proposed to split the configuration into several .pa files at >> PulseConf, even if the exact directory structure wasn't really worked >> out. That seems largely related to this issue. >> >> I'm just thinking - if we're replacing gconf anyway, can we come up with >> something more unified/generic that would fit in the new directory/file >> structure, instead of inventing a new type of configuration storage for >> this particular problem? > > The new "manager modules" that I suggested could store their settings > as .pa scripts. Would that be enough to make you happy? > > The scripts could be stored in a location from which they would get > picked up automatically by the main configuration script, or the scripts > could be stored in a location from which they would only get picked up > by the manager modules. > > If the scripts were included automatically by the main configuration > script (default.pa), that would have the problem that when a manager > module is removed from the configuration, its settings are not cleared > automatically. So if the user removes module-rtp from the configuration, > unwanted rtp modules may still get loaded. Therefore, I'd prefer the > manager modules to control the module loading instead of including the > scripts from the main configuration script. > > I don't think the settings storage format makes a big difference when > trying to figure out why a specific module is loaded, What makes it easier to figure out, would be 1) less files/directories to look in 2) less number of ways to load a module GConf fails in both of the above. I was hoping we could do better. > so maybe you're > having problem with the whole "manager module" concept? Maybe so. If we try to design this from the client's perspective, i e paprefs or possibly other apps in the future, we would essentially need these function additions to the client API: * Is a module loaded by default on startup (set/get) * Module parameters (set/get) * Possibly a way to get/set in what order modules are loaded at startup, but not sure if this is really needed. Now whether this is all handled by a "manager module" or by the core is an implementation detail, but it seems weird if a manager module could remove itself (and I fail to see any point in having several manager modules?), so probably it makes more sense to have it in the core. Second, to be able to accurately answer "is a module loaded by default on startup", I assume such code would have to go through all the .pa scripts in all directories. Exactly how to do a user level override, that e g disables a module loading of a module that is loaded by default for all users, I think we don't have the directory structure to permit that yet, which is why I brought the directory structure thing up. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
