some nice gsettings facts

i haven’t written about gsettings in a while. i’ve been working on it a lot though. i will now write about a couple of nice things that gsettings will do for you.

many backends
you can have many backends for gsettings. dconf is merely one of them. the backends are local to the process, so you can have (for example, and already implemented) a keyfile backend that reads/writes .ini directly from the process or a backend that just stores the settings temporarily in memory.

settings and notification without a mainloop
gsettings makes all change notifications from the context of the _set() call that caused them. this means that if you are using a gsettings backend that never receives external events (like the temporary memory example) then you don’t need a mainloop at all.

no blocking, no async
gsettings (and dconf) were carefully designed from the start so that gsettings calls will simultaneously never block and never require async completion callbacks. in the case of using gsettings with the dconf backend, all reads are read directly from the memory-mapped settings database — so no blocking here.

writes, of course, have to go through the dconf service, so things are a little more tricky. when you do a _set() call the call is sent as a async dbus call. as mentioned above, a change notification is generated immediately from context of the _set() call. the value that you set is temporarily locally cached so that _get() calls before the dbus call complete will get this value directly. if the dbus call comes back affirmatively then the local cached copy is forgotten (since it is now in the database). if the dbus call comes back indicating an error (which really should be quite exceptional) then the local cached copy is forgotten -and- an additional change notification is emitted. to the programmer this gives the appearance that the change occurred successfully but then was reverted back to its original value by someone outside the program. this is consistent and provides a very simple to use interface that never blocks. this particular setup does require a mainloop.

of course, a great feature of this setup is that the dconf service can fsync() to its heart’s content without ever blocking an application’s user interface. rather nicely side-steps that whole debate, i say.

support for lists
gsettings has native support for lists of settings — things like accounts or gnome-terminal profiles. a GSettingsList object will keep track of the settings items in the list and you get nice “added” and “removed” signals when things change. if a GSettings item is part of a list then you also get a “destroyed” signal on that object itself (and its children) if it is ever removed from the list.

delayed apply
it is possible to create a ‘delayed apply’ gsettings object. when you modify this gsettings object, all the changes you make are instantly visible to yourself (ie: you can query it again to see the updated value) but are not written to the database (or even visible to other gsettings objects in your program) until you call apply(). this allows for having your settings object consistent with your preferences dialog box until «apply» is clicked.

support for GTK
a GSettingsList can be used with GtkTreeView. all the hard work of implementing GtkTreeModel has been done for you. in the near future i even plan to add support for making it very easy to create dialogs with «add» «remove» and «modify» buttons for lists of items. also (currently written in vala and being ported to C today) is a simple GSettingsDialog class which subclasses GtkDialog and tracks a GSettings object. if the settings is destroyed the dialog is destroyed with it. if the settings is delayed-apply then an «apply» button is automatically added (and wired up and set sensitive as appropriate). my summer of code student, sam thursfield, is currently investigating ways to improve the creation of these preferences dialog boxes. with any luck, writing code for simple preferences dialogs may be a thing of the past.

currently some evil hacks are used so that if gsettings detects that it is linked with libgtk then additional functionality is enabled (ie: using dlsym() to implement GtkTreeModel). after today there will be a separate libgsettings-ui and eventually (hopefully) these features will merge into GTK itself.

a release is coming soon.

gnio

hello everyone

many of you know that i’ve been working on gnio for a little while. it is available from git://git.desrt.ca/gnio

gnio is a networking library built on the foundations of gio. it allows you to use network connections as input and output streams.

you need the gresolver branch of glib in order to use it. that’s at git://git.desrt.ca/glib

i think it’s pretty nice, but i’d like some feedback. if you could take it for a spin and send flames my way, it would be greatly appreciated. i’m specifically looking for API suggestions.

any bugs or feature requests should be filed in the ‘network’ component of glib on bgo. contributions of code, docs, tests are most welcome and i encourage you to attach git-format-patch output to the relevant bugs.

thanks :)

uds

currently on the plane on the way back home from uds. it’s been a pretty great week, but i’m glad to be getting home.

first thing: props to canonical. when i was checking out of the hotel the guy at the desk said something to the effect of “and canonical has everything covered”. that stuck with me.

earlier this year i was considering a job with canonical. it turns out that my interests were more aligned with work elsewhere and i ended up working for codethink. despite being employed elsewhere, canonical still invited me to uds. when you take a step back to consider that, you really realise that we live in a special sort of world. “normal companies” don’t tend to do things like that.

in any case, twice a year canonical flies a bunch of us out for this awesome event that they put on. this year i also attended fosscamp. for both events, the gnome group, as usual, spent a good deal of time on the hallway track getting things done.

a few hilights from this week:

notifications: by the end of the week many of us were refering to uds as “nbs: notification bikeshed summit”. in a way, it was a little bit demotivating to spend so much time talking on this subject. on thursday, however, christian hammond drove up to the googleplex from vmware and we all had a sitdown meeting. we came to a good compromise and — even better, as a result of the compromise — canonical’s changes are going upstream this cycle. in the end, i think this ended up being a pretty big win. also: awesome to see that rob carr is back. during uds he wrote what is probably the most awesome patch ever.

trash: i rewrote the gvfs trash backend and committed it to trunk on thursday. awalton (cool hacker who i met for the first time) is working on some associated UI changes to nautilus. seb will be rolling a jaunty package shortly after he arrives home. please try to break it — you know where to send the hatemail. :)

gnio: downloaded and started poking at gnio, which is a library to do networking in a way similar to gio (using the same stream abstractions, etc). started hacking on it a bit. christian and i are aiming to have this included in gio during this cycle (ie: by guadec time).

gritty: jono had one of the first sessions of fosscamp. his idea is that we’d have a lot more experimentation with the development of cool new software if it wasn’t so damned difficult to get your hacks on to other people’s machines. lowering the barrier to distribution would encourage people to share ideas. early exposure to users will encourage hackers to develop their ideas into proper projects. mvo and i have started hacking on a prototype for how this might work. gritty is a name chosen at random by mvo picking a number and me going to that line in /usr/share/dict/words (+/- about 10 lines… “groans” wasn’t such a good name). with any luck we can have a first version of this in jaunty.

in non-uds/fosscamp news, i’ve also heard word from rob that work on dconf will be starting within the next couple of weeks.

after a week, i am returning home with excitement and a renewed focus. i have a whole lot of projects that i’m pretty excited about.

time to start hacking!

as heard at uds

(talking about failed package installs)

mvo: “oh shit, it fucks!
desrt: “is that the official term?”
mvo: “well, you know…”
mvo: “probably the dialog will say something different… but yes.”

dconf lives!

development on dconf is going to be picking up again. there are two reasons for this:

1) i am done school!
2) i am now gainfully employed by codethink, courtesy of mr. rob taylor!

there are also some interesting side projects going on: gbus, for example.

i really enjoy this feeling that no matter how much gets done there is always new work to do.

more news soon…. :)

icanhasedit?

1 part federico + 1 part marnanel-musings + 1 part tango experiment + a couple of hours

= icanhasedit.py (very rough concept)

also in git at git.desrt.ca (git-clone git://git.desrt.ca/icanhasedit).

for best effect, set it as the default application for opening text files.

be warned: its saving is non-atomic.

call out to potential mentors for summer of code

the summer of code student application period is scheduled to open on march 24th and remain open until the 31st. at this time we will begin receiving applications from students interested in participating in summer of code with gnome.

after the application period closes, a small selection committee will decide which applications are accepted. we anticipate hundreds of applications from students, however, and in many cases, we will be unaware of the details concerning the area of gnome that the student is interested in working on.

if you’re interested in having students work for the summer on your corner of gnome, please sign up to be a mentor. generally, anyone who is a gnome foundation member will be accepted as a potential mentor. as applications are coming in, please comment on any that interest you and up/downmod as appropriate. indicate if you are willing to mentor a given application. this will make the job of reviewing applications and selecting the winners much easier and makes it more likely that your corner of gnome gets the attention that it deserves.

it’s not a bug, it’s a feature!

the hardy alpha 3 livecd has this strange compiz bug.

if the window decorator starts up before the gnome settings daemon then the decorator uses the default gtk selection colour (a deep blue). the bug is that when the settings daemon gets itself going the buttons on the window titlebar change colour but the titlebar itself stays stuck at the old colour.

this produces a very strange effect:

desrt metacity theme screenshot

when i first started up the live cd i said to myself “wow! this is a really cool new theme!”. the theme seemed to come and go, though, and i finally realised that what i was looking at was actually just a strange bug caused by a race condition.

anyway, i like this bug so much that i’ve turned it into a proper theme. i did this simply by taking the “human” metacity theme and hardcoding the two different colours into it.

unpack the tarball in your ~/.themes directory.

enjoy!

download here