Proposal for a general setup panel (overview)

[Thomas Leonard]

On Wed, Aug 21, 2002 at 10:33:25AM +0200, Jasper Huijsmans wrote:
> At 09:52 AM 8/21/02 +0200, you wrote:
> [...]
> >Nope, well, kinda, the plugin is in charge of loading/saving settings to
> >file and display a gui. The rest should be handled by the xsettings
> >manager.
> 
> Some people would consider this 'hijacking' of the standard and it assumes
> we always run with our own xsettings manager. This more or less makes it
> impossible to use parts of xfce in other environments (e.g. xfwm4 for GNOME
> or ROX) while still being able to change settings. I'm not saying this is
> wrong, but it's a consequence of using XSETTINGS, isn't it?
> 
> Would it be possible to use our own XFSETTINGS window and use the protocol
> described in XSETTINGS for our own settings? The xfsettings manager can then
> manage both settings windows or only the xfce one if there is another
> settings manager present.

Sounds like a good idea. I suspect GNOME should be doing this too if
they've added their own settings.

[...]
> >That's another approach, probably closer to the ROX-filer way, if I
> >remember well. Thomas, still with us on this list ?

Yep. On holiday though, so I might be a bit slow to respond.

> A big difference of course is that with ROX the configuration is all
> in-process, so that makes some things a bit easier.
> 
> However if we decide on a communications protocol (XSETTINGS) and have a
> library to communicate with the settings manager the difference may not be
> so big.
> 
> If I remember correctly ROX options system uses two types of configuration
> files:
> 
> - one xml file to describe the dialog. This file includes the type of 
> widgets to use (like glade) and the names of the options. There may be
> information on the limits of each option and a default value as well,
> I'm not sure.

Yes, in some cases (spin buttons and sliders currently).

> - separate parts of ROX read their own config file and register options with
>   the options system. The option is registered by name, which must match the
>   name in the dialog config file. It can also provide callback functions 
>   that will be called when something changes.

All the options are now stored in a single file loaded and saved by the
options system. Also, I removed per-option callbacks. Before, you could
either get notified when a single option changed or whenever anything
changed.

Turned out, the only code that was using per-option callbacks was just
caching the result (not an issue after I switched to using static
structures). Now, you just do:

	void my_notify(void)
	{
		if (my_option.has_changed)
			g_print("option now %s\n", my_option.value);
	}

This gets called after groups of changes (eg, Revert or after loading).

Values are always strings, but if the string is a valid number too then
option.int_value is set to it for efficiency.

We allow code to register extra types of option widget, which may be a
problem for out-of-process options. If you have a shared library, it might
not cause any problems. 

Having the dialog layout in XML allowed us to remove vast amounts of messy
code, and keep the style consistant, so I'm rather pleased with it (it's
ROX-Filer's third attempt at an options system ;-).


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk		tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1