Some thoughts on settings manager

[Jasper Huijsmans]

On Mon, 18 Nov 2002 16:37:46 +0100 (MET)
Olivier Fourdan <fourdan at xfce.org> wrote:
...
> > 3) registering a channel and options
> > This can either be done by the app or by the plugins. To find the 
> > plugins the app could provide a location for the plugin or the
> > settings
> 
> Only the plugin registers channels. The apps listen to a channel.
> 

Makes sense.

> Ideally, people who write an app also write a plugin for the setting
> manager.
>  

Except the SETTINGS channel. Perhaps this should be
included with the settings manager.

> > manager searches a number of predefined locations
> > (XFSETTINGS_PLUGIN_PATH?).
> 
> $prefix/lib/xfce4/mcsplugins/
> 

Not important, but I was thinking of the hypothetical situation when
RedHat 8.3 includes XFce 4 and a new utility is released and the user
wants to install it in $HOME or /usr/local. We we can just require the
plugins to be installed in the ${prefix} location of the manager.

> If the user installs xfce4 in h[is|er] homedir, prefix is $HOME. I
> mean if a user has the rights to install an application, (s)he also
> have the right to install the plugin.
> 
> > I think the plugins should set initial defaults since only they have
> > direct access to the setttings manager. The application would
> > require extra API to set values for properties and that would
> > partially defeat the purpose of the plugins.
> > 
> > After obtaining the inital default values the settings manager can
> > see if it has saved previous values and apply those instead of the
> > defaults given.
> 
> Why setting defaults and then loading the values ? Why not loading the
> values at first ?

I was thinking of the initial situation when there are no saved
settings. But you're right, the manager should first check the saved
values and if unavailable it should ask for default values.

>  
> > 4) Actually changing the settings
> > The plugins can do this using the settings manager library if they
> > have a pointer to the XSettingsManager structure.
> 
> I was thinking of a structure like :
> 
> typedef struct _McsPlugin
> {
>     XSettingsManager *manager;
>     char *plugin_name;
>     GtkWidget *top;
>     GdkPixbuf *icon;
>     char *caption;
> }
>  

Perfect. Is plugin_name the channel name and caption a human readable
version ("XFCE" versus "XFce panel")?

> 
> And then the mcs manager scans for all available plugins in the
> correct location, allocate a McsPlugin structure and set the manager
> field, tries to load the plugin and :
> o if it loads, calls mcs_plugin_init(McsPlugin *mcsp)
>   the plugin will fill in the blanks of the structure, ie 
>   set the plugin_name, top, icon and caption
> o if it doesn't load (ie not a mcs plugin), the manager frees the
> allocated 
>   structure.
> 
> Then, the manager can call gtk_widget_show on the top widget when a
> show request is received. We can add an optionnal run_dialog routine
> that can be called (if defined) rather than gtk_widget_show()
> 

If you're not concerned with memory usage this is ok. Otherwise a
function pointer to a run_dialog function could be used instead of the
widget.

> Later, we shall be able to write a gui for the manager so that all
> plugins are displayed with icons, caption etc.
> 
...
> > To reduce memory usage the settings manager should load and unload
> > the plugins when required. 
> 
> I don't think it's necessary. We won't have hundreds of plugins
> anyway.
> 

Right, we can always do that at a later stage of course.

thanks,
	Jasper