Planet Cleanstick

I love lamp

Jason Scheirer posted a photo:

At LACMA

</content>

OFF

Jason Scheirer posted a photo:

</content>

Ante show

Jason Scheirer posted a photo:

</content>

Azure Ray

Jason Scheirer posted a photo:

</content>

If You Fall

Jason Scheirer posted a photo:

</content>

Fuzzy couch

Jason Scheirer posted a photo:

</content>

Blown out couch

Jason Scheirer posted a photo:

</content>

I should have used a better camera couch

Jason Scheirer posted a photo:

</content>

Toulouse

Jason Scheirer posted a photo:

</content>

Better focus

Jason Scheirer posted a photo:

A mantis nymph somehow ended up on my handlebars on my ride home

</content>

Mantis

Jason Scheirer posted a photo:

</content>

Mantis

Jason Scheirer posted a photo:

</content>

Yeah Yeah Yeahs

Jason Scheirer posted a photo:

At the Pomona Fox

</content>

Nix

The other day I found out about the Nix package manager. It's interesting because each version of package (called a derivation for some reason) is in an isolated directory, and the environment is built from symlinks and long PATH variables and the like. This gives some niceties like atomic upgrades, and the ability to reason about broken dependencies much more easily; the developers term it a purely functional package manager. You can also have multiple versions of a package installed and switch between versions using a "profiles" feature.

This got my brain working a little. In Nix, the packages are specified as a set of attributes and a shell script that together describe how to build the package from source. When installing, it first checks various places for a suitable binary version and if there isn't one, it will download the source and build it. So Nix could give us beautiful support for testing and hacking on bits of GNOME. Imagine I decide to rewrite GtkTreeView, for whatever reason. I set up a new profile which uses Gtk+ from git, and keeps the source in my home directory somewhere. Nix can download binary versions of the latest GLib unstable, and any other deps not satisfied by the distro, so I don't have to waste time building those. I'm not sure what Nix would do about the apps that depend on Gtk+; ideally you could tell it the ABI wasn't changing so it would just run the same versions of apps but linked against the unstable Gtk+. This isn't possible at the moment and would be hard to implement, I imagine. Right now Nix could install new versions of various apps, hopefully just the ones you specify to save duplicating your entire system. The point anyway is that now I can do some hacking and test my changes in my real environment straight away, all with no danger of breaking my actual system.

I know there are major obstacles to achieving this. Nix isn't perfect - it uses wastes quite a bit of time and disk space, although there is a distro using it in the real-world. I wrote to their mailing list, and it seems like a lot of what I mention above is possible but isn't really documented or used much at the moment. And of course it's not like jhbuild doesn't work well. Still, I kind of think this is a vision of the future. It would be awesome being able to pick and choose bits of your system to hack on and have it integrate perfectly.

Interestingly, nix would also be really useful for packaging MSYS. I mean the dependency problems there are so complex that the msysGIT people choose to ship an entirely separate environment.

August 17th ~19:00 UTC

Hi everyone! I thought I would write my final SOC report to my blog, so that it gets everyone excited about a really cool new API that you can't easily use for anything at the moment, but it is going to be awesome when you can!

My original idea was basically to take the gconf-peditor widgets and make them GtkBuildable, saving a lot of wasted effort. I was going to do some other stuff to make GConf more bearable as well. By the time I started coding, this had become ignoring GConf entirely (which is on its way out sooner than I realised) and essentially closing bug 494329, and related work.

So here are the various things I have written over the last few months:

• GLib
  I added a pretty printer for GVariant objects, which is now in the main gvariant branch of glib.
  
  
• GTK+
  My Gtk+ branch can read the following:

  <object class="GtkCheckButton" id="foo">
    <property name="active" setting="foo">true</property>
    ...

  and later on, you can call gtk_builder_bind_settings_full (...) and it will call a function for each of these bound properties. To avoid a GSettings dependency, nothing happens automatically yet: you have to pass g_settings_bind as the callback.
  
  
• gsettings
  I have a branch with some small changes to GSettings, such as loading schemas from outside the system schemas database. My main contribution is that I just wrote a windows registry backend, with .. wait for it ... full change notification support. So hopefully (I haven't actually tried this in the real world, but it works in my tests) you can update your app's UI as the user edits the settings in regedit and crazy nonsense like that.
  
  (This is all done just with Windows API functions - which is smart enough to tell you a registry has changed, but not smart enough to tell you what value it was, or do so asynchronously. So the code currently caches the settings in memory and works out what has changed the hard way. A month ago I wouldn't have predicted even that to be possible :)
  
  
• gsettings-gtk
  Some of my stuff is still in its own repo at the moment. Here we have g_settings_bind() and an (incomplete) GtkBuildable version of GSettingsList. There is also a script which will read a GtkBuilder file and output a GSettings schema, based on which object properties are bound. Given that you will always need a settings schema, code to control the settings and code that is controlled by the settings, this seems like the best way to minimise duplication of effort; the default values are taken from the default values in the ui. Another option would be to generate the schema from the properties of the object it controls, but this is left as an exercise for now ...
  
  
• GLADE
  Finally, so people can actually use this stuff easily, I did some GLADE hacking. This branch has a simple GladeSettingsEditor dialog which can edit property bindings .. and even has some incomplete GtkSettingsList editing. Although the dialog works fine, it needs some more stupidity checks; at the moment for example you can bind checkbutton.active and set a related action at the same time.
  

I think this is a reasonable amount of work for 3 or so months .. especially counting the time I wasted on autotools issues and git confusion :) Compared to my original proposal, some big things on the gsettings-ui side are still unfinished .. but I have done some other things not in the proposal at all, so it balances out I guess. The inspiration for this project was the fact that working with GConf sucks, and you end up wasting a lot of time, so I'll be continuing working on this until I can use it in my apps in place of the GConf API. My future plans include (ignoring the obvious things such as testing and merging into the main repos) supporting flag and enum values in various useful ways, converting some apps which currently have a lot of code dedicated to preferences and replacing it with a much smaller amount of gsettings code (mainly for the satisfaction), and writing a tutorial entitled "How to use GSettings and GTK+ to make your life much easier"

Thanks to ryan for sorting me out all the time, and also to tristan for help on the GLADE side, and to everyone who spends time making GNOME rock

what a gwan?

• I heard some talk a while back about ways to get automake to shut up. It turns out it now can, using a new silent mode.
  
  It involves adding the following to configure.ac:
  

  m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES])

  (using m4_ifdef so that the script continues to work with automake 1.10 and older)
  
  And passing the --enable-silent-rules flag to configure. Of course, it also involves updating your infrastructure to support automake 1.11, and prepending something like $(AM_V_GEN) on any custom Makefile actions you have .. but these are technicalities
  
  In fact, this autotools mythbuster document has a couple of other gems, such as how to implement non-recursive automake correctly.
  
  
• Been using my new Thinkpad X40 for a while. It's nice having a computer new enough to run compiz. It's also nice having a notebook with a 2 hour battery life, so I can take it up a hill and sit coding for longer than it took me to get there. I installed the Karmic beta, which keeps warning me that the disk is about to die, presumably because it reports a load cycle count of 92 billion. I take this value with a pinch of salt.
  
  
• Less than 24 hours before the summer of code 'pencils down' time. Tomorrow I will post a nice report on all the stuff I have done, it will very be exciting!

Penny goes for a swim

Jon Atkinson posted a video:

The Luke Newell method of teaching your dog to swim.

</content>

Some more jhbuild on windows

• Discovered something that was up with my jhbuild branch: zlib installed its import library with the wrong name, so libtool didn't build DLL's of its deps. This is now fixed in my git.


• Finally bought a new laptop. I've had the same Thinkpad T20 for 3 years, and I imagine it's been around for 3 or 4 years before I got hold of it. For a while, the trackpoint controller has been a bit crazy, the screen is unreliable and the case is cracked so I found an X40 on ebay this morning for £160. I was hoping to get something better suited to working outside (black isn't the ideal colour for use in the sun, never mind the transmissive screen) but this doesn't seem to be a priority of laptop makers, so my odds of getting something cheap in this line are low :) I also worry about the 12" screen for coding on, but I guess spare monitors aren't too hard to find if I am stuck without a desktop for a while. I looked at some other makes, but it's hard to justify buying anything other than a thinkpad - there's so many niceties I would miss, and I worry that no other make has comparable build quality. Long live the thinkpad!

Pretty view from my windows

Springtime is here in the win32 world. First GCC 4.4.0 and now MSYS 1.0.11. There's magic in the air. And a few nights ago I built gtk+ completely from source on Windows using jhbuild, mingw and MSYS.

I tried to repeat this yesterday using gcc 4.4.0 instead of gcc 3.4.5, and this caused many new problems :) I've just about run out of time to fix them up for now, so I thought I would present my findings as they are. I wrote up a nice set of instructions which live at http://afuera.me.uk/jhbuild-windows/. They have worked for me with gcc 3.4.5 and are very close to working with gcc 4.4.0. There are various pitfalls, but all the ones I have come across are documented and hacked around. So take it for a spin!! .. I will happily accept more/improved -windows modulesets, fixes for the various things I've had to hack around, or any sort of drugs that might help me recover from the mental trauma.

I have also started work on an MS Windows registry backend for GSettings .. my SOC stuff has been neglected recently while I've been away, but I think with a few days of solid effort it's all going to start really coming together. It's going to be exciting to start converting some apps and tearing out big chunks of newly-redundant code :)

Autohell, part 995

• I'm putting in a little time today on my windows branch of jhbuild. Running git now works (using a .bat file to call MSYSgit in its own shell, it's all messy but works fine once it's set up).
  
  
• I spent the past hour or so wondering why ACLOCAL_FLAGS was being ignored. I finally realised that it's not actually honoured by aclocal at all and never has been. autogen.sh scripts tend to execute aclocal $ACLOCAL_FLAGS which make it work often enough that I assumed it was meant to.
  
  Now I wonder whether autoreconf would accept a patch to make it honour $ACLOCAL_FLAGS, or if I should patch Pixman's autogen.sh to call autoreconf $ACLOCAL_FLAGS .. and any others that don't ..
  
  
• Highlights of Glastonbury were definitely Blur, and a more obscure band called Edward II who I last saw aged about 12.
  
  Best wishes for everyone in Gran Canaria!

GLADEs

This week I started exploring the wild world of GLADE!! After losing a day to the fact that I hadn't done a 'make install' after changing the API in some way (the plugins were still being loaded from PREFIX/lib/glade3, so all hell was subtly breaking loose), I managed to implement the following provisional UI for binding settings to properties:



Most properties can be bound, including many that you would never want to - but the 'Bind to' widget is normally hidden for these. It defaults to shown on the 'data' properties you'd normally bind to, such as GtkEntry.text and GtkCheckButton.active.

A bonus of this is you get 'guards' (where one toggle affects the sensitivity of an area of the dialog) basically for free. Just bind the 'sensitive' property of the container widget to the same key as the toggle, and all of its children will be disabled/enabled appropriately.

Last week I stayed a few days with my parents in Wales. Generously the sun came out and I got out a bit.



This week I am headed to Glastonbury! I like to get to lots of festivals every year and Glastonbury is far and away the best in the country. I often work at them but I'd hate to do that at Glastonbury, there's already not nearly enough time to see the whole of the festival. It just so happens there are several recently reformed big-name bands playing this summer, I think it is going to be one to remember!

Luna Park

Jason Scheirer posted a photo:

</content>

Fish

Jason Scheirer posted a photo:

</content>