[pulseaudio-discuss] RFC: Getting rid of the GConf dependency
david.henningsson at canonical.com
Tue Jan 29 03:03:18 PST 2013
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:
>>> 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?
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.
More information about the pulseaudio-discuss