Category: glib

Posted on

All the Old Showstoppers

okay, new rule ((apologies to Bill Maher)): it’s okay to install a GObject property like this:

pspec = g_param_spec_string ("title",
			     "Title",
			     "The title of the item",
			     NULL,
			     G_PARAM_READWRITE);
g_object_class_install_property (gobject_class, PROP_TITLE, pspec);

instead of the usual way you see in other GObject-based libraries, where we l33t h4x0rs dispense from the use of an explicit GParamSpec variable. this is especially true if you are trapped in 1983 and are still using an ANSI 80×25 terminal — though you should probably know that here, in 2008, 100+ columns are safe.

oh, and fill out the name and blurb fields of the property: GObject provides a little bit of introspection, but if you willfully ignore it then we can just forget about stuff like the GObject-Introspection project.

please, every time you install a property using a line like this:

g_object_class_install_property (
	gobject_class, PROP_TITLE,
	g_param_spec_string ("title", NULL, NULL, NULL,
	                     G_PARAM_READABLE | G_PARAM_WRITABLE));

an unfortunate incident will involve a bucket of puppies and a belt sander.

comments saying “gobject sucks you should be using ${ZEALOTS_OWN}” will be deleted without mercy because they miss the point by a hundred and fortyseven miles

Posted on

Good Intentions/2

gtk+: I’ve been working again on the RecentManager and in trunk you’ll see some new stuff, namely:

  • use GIO to determine the MIME type of a URI, on every platform supported
  • use the file monitoring API to avoid polling the storage file
  • add a GtkSettings property for clamping the recently used resources list to a 30 days limit

more stuff I’d like to add is:

  • small parser changes to GBookmarkFile, to reflect changes in the spec
  • bulk addition, for applications storing multiple items when quitting
  • new API needed to follow the usability review in bug 349541
  • moving the RecentItem icon code to GIO, and add API to extract the thumbnail

twitter: I’ve been using Twitter a lot in the past two weeks; it’s nice, it makes it easier to copy and paste a quote or a thought, and the 160 characters limit is an interesting challenge. As it’s been ages since I last wrote an application ((lately all I’ve been doing was writing libraries)), I decided to start writing a Twitter reader/writer — using GTK+, Clutter and Tidy; without much thinking, I opened gvim and started writing code in C ((hey, that’s what I do for a living, it’s hard to switch off; plus, I could reuse some of the platform libraries)) — so, the obvious thing that happened was that I ended up writing a library yet again in order to use Twitter’s web API. luckily for me, libsoup has now a really nice API to work with; all you need is GET and POST to their RESTful API, retrieve the result, parse it through JSON-GLib, hide everything inside a new GObject and you have a wrapper around a web service. the application, you say? oh, I was sure I forgot something. well, it’s coming along — it just needs some work still.

Posted on

Failsafe

About JSON-GLib: things have gone quiet on that front, but lately I’ve resumed working on it ((In a couple of separate branches, for the time being, but when those are ready, they will be merged back into master and will be released as 0.6.0)).

I decided to try the new GLib test framework that has landed in the 2.15 cycle; GLib and GTK+ are both already using it, and now a branch of JSON-GLib is GTest-powered. Setting it up is not hard – but it requires some changes in the build environment. The API is quite straightforward — just call:

  g_test_init (&argc, &argv, NULL);

inside your main, then add the test functions with:

  g_test_add_func ("/test-section/foo", test_function_foo);
  g_test_add_func ("/test-section/bar", test_function_bar);

and finally run the test using:

  return g_test_run ();

which will return the exit code used by the gtester program to determined whether the successfully test passed or not.

The test suite is built along with your library or application, but run only with make check and make distcheck. There’s also an automatic report generator which will dump an XML file with the results, which you can then parse to create HTML pages or other forms of report. The rest of the work is putting a set of pre-cooked declarations for the Makefile templates into the root of your project; including it in every Makefile.am file; create some tests directories; and dump there the test units. I bet that Anjuta or other IDEs with autotools support can be tweaked to do this stuff for you.

JSON-GLib is now using GTest to test the data types API (for the time being, Array and part of the Node) and the Parser behaviour; nothing very complicated, at first, but it’s good to have it all automated and a simple make away. Adding new test cases to exercise the whole API will be the priority in the next weeks.