GConf plans for 2.8

	I'm going to create a gnome-2-6 branch for GConf soon.

	Here's a rough list of what looks like might be plausibly done for

Patches ready to go

  * Allow notifications from backends:


    At the moment gconfd itself notifies from operations which change 
    values. This patch adds an API for backends which allows them to
    notice values have changed and inform gconfd. It will be useful
    for backends like the LDAP backend or if we figure out a sane
    way for the XML backend to notice files have changed and reload.

  * API to allow arbitrary stacks of sources:


    The patch basically just adds the gconf_engine_get_for_addresses() 
    API, but involves significant re-factoring of parts of GConf. The 
    idea here is that we could make gconf-editor into a useful sysadmin 
    tool which allows you to create new configuration sources and model 
    how it would look when added to the default sources list.

Patches exist, but needs looking at/more work

  * LDAP backend:


    The idea here is to allow you to store your preferences in LDAP. The
    code looks like a good start but will require more work.

  * gconftool-2 --unload (reverse of --load)


    A simple patch to allow to inverse of --unload so that packages like
    the panel can cleanly remove themselves. The patch looks pretty 
    reasonable and just needs to be reviewed.

Useful things which shouldn't be too hard

  * Allow using the markup backend's subtree-in-a-file feature to be used


    The markup backend (which became the default in 2.6) has a feature
    whereby each of the %gconf.xml files can be merged into a single
    file which contains an entire subtree. We need to figure out a
    strategy for using this feature that won't completely break compatibility
    with older version of GNOME.

  * set/get_filename()


    Some apps store full paths of files in GConf which completely breaks
    things when you change username or log into a GNOME installed in a
    different prefix. This suggested API would make things easier for
    app developers by storing filenames without these absolute elements 
    of the path.

  * Make gconf not spam syslog


    gconfd needlessly spams syslog. It probably should only use syslog
    for actual errors. Also, some work on making gconfd easier to debug
    would be useful here too.

	There a plenty more longer term plans for GConf which Havoc has written
up at:



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]