1. Monday

1.1. Participants

Ryan Lortie, Vincent Untz, Matthias Clasen, Colin Walters, David Zeuthen

1.2. Unsorted notes

Topics (everybody):

• ghashfile review
• dconf/gsettings overview and status
• migration story
• merge gsettings
• gdbus finish
• scope out gvfs-to-gdbus porting

DConf/GSettings Status (Ryan)

• gvariant in glib (DONE)
• gobject needs some serialization framework (probably defer this)
• gsettingsbackend needs gio (abstract class with extension point)
  • gmemorysettings (builtin)
  • dconf backend
  • registry backend (win32)
  • maybe a OS X backend (based on ige-conf stuff in devhelp)
• dconfbackend links against libdconf
• libdconf opens database for reading, and talks to dconfd over dbus for writing
• database design:
  • /user/... /default/... /system/... /login/...
  • default and system are system-wide and always written over the system bus
  • /user is user-specific
  • /login is holding the values for the login session
• dconfd can be activated on both the session bus and the system bus
• dconf is untyped key-value store
• schema information lives on the gsettings level
• how schemas currently work:
  • schema descriptions get installed in /usr/share/somewhere
  • there is a schema cache that gets compiled from that
  • apps only use the schema cache at runtime
  • dconf-editor will use the installed schema files
  • not yet possible, but would be nice: compile schemas into the binary
  • apps will not work without a schema
• where is the code: gsettings branch of glib, dconf repo

Migration story:

• not realistic to port everything for GNOME3
• no need for a flag day, every app can be ported at its own pace
• GConf and GSettings can coexist (some complication when keys are used across modules)

• may want to have support for easy one-time migration GConf db -> DConf db

some side-chatter about pros and cons of using libdbus in gdbus

• one problem: apps will have multiple private connections (one for dbus-glib, one for gvfs, one for gdbus)
• should port gvfs to gdbus as a priority to get rid of at least one private connection

gvariant insight:

• strings need to be valid utf8
• should add easy support for sending strings as byte arrays

2. Tuesday

2.1. Participants

Colin Walters, Ryan Lortie, Vincent Untz, Matthias Clasen, David Zeuthen

2.2. Notes

Hacking day, not too much discussion.

• Vincent is implementing the GSettingsMemoryBackend and adding keyfile support
• Ryan is porting GSettingsSchema to the new hash file format
• Matthias has added context support to GSettingsBackend to give an easy way to use GSettings e.g. for system defaults
• Colin is implementing his GApplication class
• David showed up late

The results are appearing in the new-settings branch of GLib

3. Wednesday

3.1. Participants

Vincent Untz, Ryan Lortie, Matthias Clasen

3.2. Notes

Matthias assembled some data on GConf schemas and how widely they are used across modules: Hackfests/GSettings2010/Notes/GConfSchemas

Something that came out of discussion between Ryan and Vincent is to add some facility for overriding schema defaults via some lookaside keyfile, to help distributors and system administrators.

We discussed transition again, and came up with a plan:

• Write a standalone binary, say g2dconf, that gets run at login time
• It reads files from a directory in /usr/share/somewhere
• The files describe a mapping from gconf keys to gsettings keys, for a given gsettings schema
• g2dconf reads keys out of GConf and writes them to gsettings, according to the mapping in the file
• g2dconf maintains a list of already-converted files and a timestamp somewhere in the users homedir, e.g. ~/.g2dconf
• An application that gets ported from GConf to gsettings can chose to migrate existing user settings simply by installing such a mapping file

During the day, Matthias started to put together a testsuite for GSettings.

The current plan for the upcoming merge is to include GSettings, GSettingsBackend, the memory backend, the delay backend, the schema compiler, but leave out GSettingsList and property binding. The to-be-merged parts are all in good shape, and we should be able to get a .0 release out next week.