Some thoughts on settings manager

[Olivier Fourdan]

Hi Jasper,

Quoting Jasper Huijsmans <jasper at moongroup.com>:

> As I see it there are four basic ways in which code may need to interact
> 
> with the settings manger:
> 
> 1) listening
> This is easy and fully covered by the client library. An app can listen
> to it's own channel and others.
> 
> 2) requesting a configuration dialog for a channel.
> This is accomplished by the client library using the "SHOW" atom.
> 
> 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.

Ideally, people who write an app also write a plugin for the setting manager.
 
> manager searches a number of predefined locations
> (XFSETTINGS_PLUGIN_PATH?).

$prefix/lib/xfce4/mcsplugins/

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 ?
 
> 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;
}
 

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()

Later, we shall be able to write a gui for the manager so that all plugins are
displayed with icons, caption etc.

> Functions a plugin must provide:
> 
>    char *get_channel_name(void);
>    void *set_default_values(XSettingsManager *sm);
>    GtkWidget *create_options_dialog(XSettingsManager *sm);
> 
> We have to think about what we want. If we want all separate dialogs the
> function can be
> 
>    void run_options_dialog(XSettingsManger *sm);
> 
> if we want a control-center-like app, the dialog needs buttons to revert
> the options and close the dialog and the plugin needs access to the 
> revert button at least.
> 
>    GtkWidget *create_options_dialog(XSettingsManager *sm,
>                                     GtkWidget *revert);
> 
> 
> The settings manager saves the settings in a simple xml format, like:
> 
> <channel name="SETTINGS">
>    <option name="Net/Doubleclicktime" type="INT" value="50"/>
> </channel>
> <channel name="XFCE">
>    <option name="size" type="INT" value="1"/>
>    <option name="theme" type="STRING" value="Curve"/>
> </channel>
> 
> 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.

> Initially all plugins are opened, their name and
> location saved in a list, the channel is created and the plugin is asked
> to set default values for the options. Then the plugin is closed and 
> opened when a client request a dialog for that channel.

Channels are created by the plugin, not the manager.

> Well, this is how I understand it. Am I missing anything?
> 
> Should I try to write a sample plugin for the panel based on this API?
> 
>      Jasper
> 
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at moongroup.com
> http://moongroup.com/mailman/listinfo/xfce4-dev
> 



--
XFce is a lightweight  desktop  environment  for  various *NIX systems. 
Designed for productivity,  it loads  and  executes  applications fast,
while conserving  system resources. XFce is all free software, released
under GNU General Public License.    Available from http://www.xfce.org