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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
