My GSOC 2013 project: a new break timer application for GNOME

A little while ago, my proposal was accepted for Google Summer of Code 2013. So, this summer I will be working with Jasper St. Pierre and the GNOME project on a shiny new break timer application. We’re going to spend some time filling out the wiki page for the new break timer design, and from mid-June to mid-September I will try to implement it as well as I can.

A break timer application is pretty well what it says on the tin. It’s an application that can monitor your computer use and remind you to take a break every now and then. Things get a little tricky when we start thinking about how to make that sort of application effective. Among other things, gauging how much someone is using the computer is kind of fiddly, and people don’t really enjoy being interrupted all the time. If it’s done well, though, I think anyone can benefit from this type of application. Taking regular breaks isn’t just healthy for the body: it can keep your mind happy, too.

I’m excited about this project for a few reasons. First, I have been meaning to get involved with GNOME for a while, and I’m expecting to touch a few different projects in order to produce something seamless. This is also an itch I have wanted to scratch — I really want a good, shiny and new “take a break” app for a variety of reasons — and it’s an opportunity to tie up a loose end from a while ago. I actually already started on a new break timer app, but I never quite reached a releasable product. With my project this summer, I’m going to be starting with (some of) what I already made, which will allow me to iterate efficiently and, I hope, to create something beautiful and releasable by the deadline.

For the time being, I thought it might be fun to actually share the other one I keep mentioning, which has the strange working title “Brain Break”. It isn’t perfect, but if you’re interested in a take a break app made for GNOME 3 (and yes, that includes Unity), that uses GTK+3 and real desktop notifications (and not the old system tray), perhaps you will like it? I made it because I thought the existing options for break timer software were getting a little old, but also because those options didn’t really work for me: when there was a Skip or Postpone button, I got into the habit of pressing it as soon as I could. (I’m a computer nerd. Workarounds are my middle name). When there wasn’t, I would get angry at the software for interrupting me and I got into the habit of disabling it proactively (and then forgetting to turn it back on).

Brain Break doesn’t have a Postpone button or a Skip button, but it makes up for it with a “Take a break” overlay that blocks your screen without blocking input. So, you can finish that one last thing without needing to postpone or skip the break (or, for that matter, lose your train of thought). Because there’s no easy way to make the “Take a break” overlay go away, Break Break is hard to ignore, but it tries to be nice about it.

Brain Break is probably ready to use. I’ve been using it for ages, and I like it, at least. It’s on Launchpad at launchpad.net/brainbreak. If you’re using Ubuntu, you can install it very easily from its PPA, launchpad.net/~brainbreak/+archive/daily. Just open a terminal and run sudo add-apt-repository ppa:brainbreak/daily, then sudo apt-get update; sudo apt-get install brainbreak.

Brain Break's "take a break" screen is gentle, but hard to miss
Brain Break’s “take a break” screen is gentle, but hard to miss
Brain Break's settings tool
Use the break settings panel to set specific break times, or disable them for an hour

The new break timer app probably won’t be the same as Brain Break, but in order to make the new one as awesome as possible, maybe there’s something to learn from Brain Break? Please, try it out, and share your thoughts in the comments! You might like it, and either way I would love some feedback to get ideas flowing.

Reposted from June 11, with apologies to Planet Ubuntu. Hi there, Planet GNOME!

GNOME Break Timer: Week 2

I’m starting the third week of coding on my GSoC 2013 project, a new break timer application for GNOME. I spent the last two weeks working on an odd mix of little things. For the most part, my goal over that time was to make the gnome-break-timer project (previously brainbreak, still brainbreak in most places) nicer to work with. I’m a bit of a sucker for clean code, and, well…

By Manu Cornet, from Bonkers World
By Manu Cornet, from Bonkers World

So, to start off, I switched over to Automake from my old build system, which was using BuilDj and Waf. I’m still a big fan of those two, at least philosophically. In practice, Automake just seemed like a good choice because it’s familiar to people, and I really want to maintain a high bus factor for this project. This isn’t the sort of application that I would expect to have a continuous flow of regular contributors, so I think it’s important that someone can jump in and figure it out for without too many obstacles.

One interesting puzzle here was doing a convenience library with Automake and Vala. I started using convenience libraries for this project so I could strictly define different parts of the application. The idea is code at one level shouldn’t know anything about code above it, and we can formalize that by actually building these bits of code to separate objects that get linked together later. This also, conveniently, allows us to reuse the code that is common between the settings panel and the break timer daemon without needing to compile it twice. Not a big deal here, but I like it anyway.

I found lots of helpful information about doing convenience libraries with Automake, but Vala posed something of a problem because Automake doesn’t do everything for us with Vala (yet). I need to pass several extra flags to valac, both for the library and for the target that uses the library, and I need to do that without messing up build dependencies. I don’t want to run into cases where the build fails (or, worse, doesn’t fail!) until I run make clean. (For what it’s worth, the old build system with BuilDj and Waf figured this out wonderfully and generally rebuilt the thing about twice as fast as Automake, but I also hadn’t set up localization or config.h, so I guess that’s kind of moot). I checked out how some projects like Deja Dup were doing convenience libraries, and I came up with a handy reusable pattern:

Makefile.am for the rather unhelpfully named “common” module:

M_CPPFLAGS = $(BRAINBREAK_CFLAGS) \
	-include $(CONFIG_HEADER)

noinst_LTLIBRARIES = \
	libcommon.la

libcommon_la_SOURCES = \
	NaturalTime.vala \
	SessionStatus.vala \
	...

libcommon_la_LIBADD = \
	$(BRAINBREAK_LIBS)

libcommon_la_VALAFLAGS = \
	--pkg gio-2.0 \
	--library common \
	--vapi common.vapi \
	-H common.h

junk_files = \
	$(libcommon_la_SOURCES:.vala=.c) \
	libcommon_la_vala.stamp

dist-hook:
	cd $(distdir) && rm -f $(junk_files)

CLEANFILES = \
	$(junk_files) \
	common.vapi \
	common.h

Makefile.am for some code that uses that module:

AM_CPPFLAGS = $(BRAINBREAK_CFLAGS) \
	-include $(CONFIG_HEADER) \
	-I $(top_srcdir)/common

SUBDIRS = 

bin_PROGRAMS = \
	brainbreak-settings

brainbreak_settings_SOURCES = \
	ApplicationPanel.vala \
	BreakPanel.vala \
	BreakType.vala \
	main.vala \
	...

brainbreak_settings_VALAFLAGS = \
	--pkg gtk+-3.0 \
	$(top_srcdir)/common/common.vapi

brainbreak_settings_LDADD = \
	$(BRAINBREAK_LIBS) \
	$(top_srcdir)/common/libcommon.la

brainbreak_settings_vala.stamp: \
	$(top_srcdir)/common/libcommon_la_vala.stamp

junk_files = \
	$(brainbreak_settings_SOURCES:.vala=.c) \
	brainbreak_settings_vala.stamp

dist-hook:
	cd $(distdir) && rm -f $(junk_files)

CLEANFILES = \
	$(junk_files)

Of course, I also rewrote a bunch of stuff which had been thrown together a little too hastily. I knew I would need to rewrite a lot of code, but I wanted to get the “rewrite and start over” bug out of my system in the beginning, and I think it worked. Allan Day already came up with some lovely mockups that I could start with, so I used those to guide me in choosing what needed work. As I worked through implementing different bits of his “take a break” UI, I noticed some aspects that would have been quite difficult with the design I had earlier. I squished and pulled things accordingly, giving the UI code a little more power and knowledge, and getting rid of needlessly arcane kinds of “reusable” code. But that’s all a little boring.

I’m really excited for the next bit. I will be working on a beautiful new Break Settings application, complete with GtkHeaderBar and (hopefully) a non-ridiculous time input widget. I’ll post some pictures and a new download soon!

GNOME Break Timer: Week 4

My work is coming along nicely with the new break timer application for GNOME. I started off week three working on some extra pieces for the break monitor component. I disabled its big “take a break” overlay, and I added some new functionality: the screen locks automatically during a long break, there’s a new “break interrupted” notification that appears at just the right moment (like when you unlock the screen), and there are some helpful sounds when breaks start and stop.

With that bit behaving mostly as intended, for now, I switched over to the other half to the application: its settings screen. The new settings screen is very different from the old one. Actually, the way it’s presented is that the settings application is the break timer application, and it just continues running in the background when you close it. That makes a ton of sense, of course, but it’s different from how this is implemented so I’ll probably sound nonsensical for a bit as I get used to describing it that way.

The new settings screen (or whatever we call it now) is already feeling quite nice.
The new settings screen (or whatever we call it now) is already feeling quite nice.

It took a surprising amount of fiddling to get the break status to show up correctly in the new Break Timer application, but I learned some interesting things about Vala along the way. These two bits of the application talk to each other over dbus, so to make that easier I define my interface in a source file that is common between the two components, and then I implement it in the code that actually provides the dbus service. Here’s how that looks (in a very simplified, contrived form, of course):

// common/IMyService.vala:

public const string MY_BUS_NAME = "org.my.application";
public const string MY_OBJECT_PATH = "/org/my/service";

[DBus (name = "org.my.service")]
public interface IMyService : Object {
	public abstract string[] get_messages() throws IOError;
}

// service/main.vala:

[DBus (name = "org.my.service")]
private class MyService : Object, IMyService {
	public string[] get_messages() {
		return {"Hello", "world"};
	}
}

public int main(string[] args) {
	try {
		DBusConnection connection = Bus.get_sync(BusType.SESSION, null);
		connection.register_object(
			MY_OBJECT_PATH,
			new MyService()
		);
	} catch (IOError error) {
		GLib.error("Error registering service on the session bus: %s", error.message);
	}
	return 0;
}

// client/main.vala:

IMyService my_service = Bus.get_proxy_sync(
	BusType.SESSION,
	MY_BUS_NAME,
	MY_OBJECT_PATH
);

Vala does a great job making all of that just work, though I did run into some trouble when I tried to define a signal in my interface. Normally we just have the signal in the interface definition and it’s automatically available for any implementing class (think mixins), but something was getting muddled up somewhere and, while the signal was available to the application, it was never registered on dbus. So, my client application couldn’t use it. The obvious workaround is to just not implement the Vala interface with MyService (so it’s just private class MyService : Object {), but I hate to do that because the nice thing about using the same Vala interface on either end is you can’t change them independently. So, I’m less likely to do something dumb like change the DBus interface in a way that breaks part of the settings application. In the end I wasn’t using signals in my dbus interface anyway, so I didn’t have to deal with it.

Another curious puzzle I ran into was an annoying race condition, where the Break Timer application would detect the break monitor daemon on dbus, and try to talk to it, and then fail because the interface it was expecting was not available (unexpected error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.brainbreak.Breaks.TimerBreak' on object at path /org/brainbreak/Breaks/microbreak). This turned out to be a lot simpler than I originally assumed: I’m using GtkApplication, which registers the application ID on dbus in order to handle uniqueness. What happened is GtkApplication would acquire the well-known name of my break monitor daemon on dbus, then the settings application would get some CPU time and see the daemon’s name on dbus and try to talk to it, but at that stage the daemon had not actually initialized, so its break-tracking-related services weren’t registered, yet – just the name. The fix is really simple: the value for my GtkApplication’s application_id needs to be different from the well-known dbus name I use to access the break timer’s special dbus interface. I just changed application_id to that dbus name + “.Application”. Then, after all of the initialization is complete, I get the dbus connection object for the application and own a different name on the bus for the service that the application itself provides:

var connection = this.get_dbus_connection();
if (connection != null) {
	Bus.own_name_on_connection(connection, HELPER_BUS_NAME, BusNameOwnerFlags.REPLACE, null, null);
}
We have a lot of room to play with for cute little status messages.
We have a lot of room to play with for cute little status messages.

That all gave me a nice opportunity to explore some changes to the break schedule dialog, which is what’s left of the original break settings application. I got rid of the On / Off switch beside each break type, and instead I added a combo box to select a particular type of schedule: either micro breaks and full breaks, just micro breaks, or just full breaks. This helps to establish what full breaks and micro breaks are, and it allows us to present the different break schedules up front, instead of hiding that more meaningful choice behind a rather arcane assortment of switches.

The Schedule dialog has two fewer buttons, and some much more direct choices.
The Schedule dialog has two fewer buttons, and some much more direct choices.

I’m working on this with Ubuntu 13.04 and the GNOME 3 repository, so I’m trying to keep everything compatible with GTK 3.8. To use the wonderful new HeaderBar widget, I’m using libgd. It’s meant to be used as a git submodule, but I’m still using bzr for this project (pending an even more compelling reason to switch). So, I added an extra git clone command in my automake.sh, which does essentially the same thing as git submodules. This is all a little strange, and the moment I switch this project to a git repository is getting very close, but for the time being I just feel a little happier pushing to Launchpad and getting that quick feedback when I break the build. With that said, there was an extra stumbling block with my fake libgd submodule and Launchpad: the build server wasn’t letting my build script access the internet to do its git clone libgd thing, but there is no way I am adding the libgd codebase to my project without a very good reason. So, I set up a git import for libgd in Launchpad, and I added one more line to my bzr-builder recipe: nest submodules lp:~dylanmccall/brainbreak/libgd libgd.

So, that means there’s still a working repository to play with the latest code! This version only works in an environment with GNOME 3.8 or above, like Fedora 19 or Ubuntu Saucy (or, if you’re feeling adventurous, Ubuntu 13.04 with the GNOME 3 PPA), but it does work! For Ubuntu, it’s a different repository than before: ppa:brainbreak/experimental. It should also build and run from source relatively smoothly.

That’s all for now. This is rough around the edges, but I think it’s starting to make sense. If you try it, please consider leaving a comment to share how it goes.

GNOME Break Timer: Week 6

It’s time to talk about my GSoC project again, where I’m making a new break timer app for GNOME. First, thank you, dear readers, for your feedback and support so far! It really helps to know other people are interested in this.

The last two weeks have been about tying up loose ends so I don’t get bogged down later on. First, I removed all traces of the old working title. This application is called GNOME Break Timer, now, instead of having several different names (and things that looked like names) strewn about. It probably only bothered me, but I’m really glad to have some logic on that front.

I got our cool introductory slideshow running. It appears if you launch Break Timer and breaks are not enabled. So, it will appear when you start Break Timer for the first time, and if you happen to turn it off at some point and want to start using it again. GtkStack was fantastic for this. It’s really nice to see GTK making animated transitions so easy, and apparently doing a pretty good job drawing them. I think it will be really exciting when applications are doing more of this in the future.

Incidentally, I updated the settings application to optionally support GTK 3.9+ with its very cool new gtk_window_set_titlebar function! I was a little disappointed to learn that I have to add the close button to the HeaderBar myself at the moment, which seems a little silly. So, I did some guessing about best practice (and borrowed some code from GNOME Clocks), then I made a little custom widget for the problem so I wouldn’t have to think about it any more.

#if HAS_GTK_3_10
using Gtk;
#else
using Gd;
#endif

/**
 * A Gtk.HeaderBar that expects to be set as the titlebar for a Gtk.Window.
 * If it is in titlebar mode, it adds a conventional close button and adjusts
 * its own titles accordingly.
 */
public class WindowHeaderBar : HeaderBar { // Gtk.HeaderBar or Gd.HeaderBar
	private weak Gtk.Window owner_window;
	private Gtk.Button close_button;
	private Gtk.Separator close_separator;

	private bool is_titlebar;

	public WindowHeaderBar(Gtk.Window window) {
		this.owner_window = window;

		this.close_separator = new Gtk.Separator (Gtk.Orientation.VERTICAL);
		this.close_separator.valign = Gtk.Align.FILL;

		this.close_button = new Gtk.Button();
		this.close_button.set_image(
			new Gtk.Image.from_icon_name("window-close-symbolic", Gtk.IconSize.MENU)
		);
		this.close_button.get_style_context().add_class("image-button");
		this.close_button.relief = Gtk.ReliefStyle.NONE;
		this.close_button.valign = Gtk.Align.CENTER;
		this.close_button.clicked.connect(this.on_close_button_clicked_cb);

		this.realize.connect(() => {
			this.pack_end(this.close_separator);
			this.pack_end(this.close_button);
		});
	}

	public new void set_title(string? title) {
		if (this.is_titlebar && title == null) {
			title = this.owner_window.title;
		}
		base.set_title(title);
	}

	public void set_is_titlebar(bool is_titlebar) {
		this.is_titlebar = is_titlebar;
		this.close_separator.set_visible(is_titlebar);
		this.close_button.set_visible(is_titlebar);
		this.set_title(this.title);
	}

	private void on_close_button_clicked_cb() {
		var event = new Gdk.Event (Gdk.EventType.DESTROY);
		event.any.window = this.owner_window.get_window();
		event.any.send_event = 1;
		Gtk.main_do_event (event);
	}
}

This widget belongs to a particular GtkWindow. When it is being used as a titlebar, it shows a Close button and borrows the title from that window when one is not set for the HeaderBar itself. You can see that happening in my video demo of the welcome slideshow. If it is not used as a titlebar, the widget behaves as usual – so, it looks like one of these:

Screenshot from 2013-07-26 19:20:37

Screenshot from 2013-07-26 19:20:19

Unfortunately, I can’t find a nice way for the widget to detect when it’s being used as a window’s titlebar, so it needs a set_is_titlebar method that gets called by the owner. Other than that, the ugliness is self-contained.

Another small change I’m very happy with is to how the break notifications appear. They are persistent, now, so as long as you need to take a break there will be a notification for it in the message tray. This makes them much tidier, and harder to miss. Now I just wish there was a way to have a notification banner stay open without needing to mark it as “critical” priority. I hate the idea that a “take a break” notification could take priority over a “low battery” notification…

How to install GNOME Break Timer

As always, I have been messing with my packages. If you want to try the latest test of GNOME Break Timer, there are two things you can do:

  • You can download this archive for the latest release and do the usual ./configure, make and make install thing. To build on Debian, it depends on libx11-dev, libxtst-dev, libxi-dev, as well as valac and libgtk3-dev (>= 3.7) and the other usual suspects.
  • Or, if you’re running Ubuntu 13.10 (or 13.04 with GNOME 3.8 installed), there’s a working PPA, so open a terminal and enter sudo add-apt-repository ppa:brainbreak/experimental && sudo apt-get update && sudo apt-get install gnome-break-timer. Note that the package has a different name than before (even though the repository is the same), so if you installed the brainbreak-experimental package earlier (thank you very much, by the way!), you’ll need to install gnome-break-timer anyway.

Next week, I’m going to make a serious effort to gather feedback on how this is working. I’m thinking of hooking up Piwik for some rudimentary statistics-gathering within the app. I’m not sure how much trouble it would be, or if it would be worth doing. We’ll see, anyway. I will also be looking at things outside Break Timer that could be changed to enable certain features, such as better lock screen notifications out of the box. GUADEC would be a perfect venue for that sort of thing, but unfortunately I won’t be there. (Next year, maybe?). Still, even if it’s just on IRC and mailing lists, it will be nice to poke my head outside this little corner I’ve been working in.

GNOME Break Timer: Week 8

Seriously regretting my boring choice of titles for these blog posts, but it’s too late to change it now.

Why, hello there! The last two weeks haven’t been the brilliantest for my work on GNOME Break Timer – partly because all my other unrelated projects, which I’ve been mostly ignoring in favour of Break Timer, have suddenly flared up and demanded attention – but I still got some nice stuff done. And I passed my statistics course and almost finished a cool charity website. (More on that soon, I hope?).

Most importantly, I decided that it’s time to add some tests. I added a test folder to the build system, and after bracing myself for a nightmare I was really impressed with how easy it was to get going. Further evidence that my fear of tests is entirely irrational.

With all the GNOME project automake stuff set up, I just needed to build a test runner using GLib’s test framework and list it in the TEST_PROGS variable. make check is figured out all on its own. So, that was lovely!

While everyone was off having fun at GUADEC, I fooled around writing unit tests. Of course, I did run into some trickiness: most of my time was spent making the application more testable (cursing Automake some more, putting everything in noinst_LTLIBRARIES), and fixing bugs that I encountered in the process of writing unit tests. This is all for a good cause, though: I am feeling more and more confident that the bus factor for this project can increase beyond 1.

Of course, I didn’t write unit tests for everything. That would be lovely, but it could also take quite a long time. (Quicker now, of course, since all the kinks have been worked out). Instead, I focused on parts of the application that I have broken by accident in the past: monitoring activity, and triggering breaks. The application uses many global things like system time, as well as timers and timeouts. Those can all be rather troublesome to test, unfortunately, but I found my way around them. I created a custom g_get_real_time function that will either return the actual time or a time set by the test suite, so we can rigorously test how certain objects behave as the time changes.

Most of this is quite boring, but I’m happy with it anyway. I wasn’t thrilled with glib’s syntax for writing a test suite – I’m used to wrapping these things in objects – so I borrowed the TestSuite and TestCase classes from libgee’s test suite, adding some extra twists.

Here is tests.vala, which is used by all of the test runners:

// GLib's TestSuite and TestCase are compact classes, so we wrap them in real GLib.Objects for convenience
// This base code is partly borrowed from libgee's test suite, at https://git.gnome.org/browse/libgee

public abstract class SimpleTestSuite : Object {
	private GLib.TestSuite g_test_suite;
	private Adaptor[] adaptors = new Adaptor[0];

	private class Adaptor {
		private SimpleTestSuite test_suite;
		private SimpleTestCase test;

		public Adaptor(SimpleTestSuite test_suite, owned SimpleTestCase test) {
			this.test_suite = test_suite;
			this.test = (owned)test;
		}

		private string get_short_name() {
			string base_name = this.test_suite.get_name();
			string test_full_name = this.test.get_name();
			if (test_full_name.has_prefix(base_name)) {
				return test_full_name.splice(0, base_name.length);
			} else {
				return test_full_name;
			}
		}

		private void setup(void *fixture) {
			this.test_suite.setup();
		}

		private void run(void *fixture) {
			this.test.run(this.test_suite);
		}

		private void teardown(void *fixture) {
			this.test_suite.teardown();
		}

		public GLib.TestCase get_g_test_case() {
			return new GLib.TestCase(
				this.get_short_name(),
				(TestFixtureFunc)this.setup,
				(TestFixtureFunc)this.run,
				(TestFixtureFunc)this.teardown
			);
		}
	}

	public SimpleTestSuite() {
		var name = this.get_name();
		this.g_test_suite = new GLib.TestSuite(name);
	}

	public void add_to(GLib.TestSuite parent) {
		parent.add_suite(this.g_test_suite);
	}

	public GLib.TestSuite get_g_test_suite() {
		return this.g_test_suite;
	}

	public string get_name() {
		return this.get_type().name();
	}

	public void add_test(owned SimpleTestCase test) {
		var adaptor = new Adaptor(this, (owned)test);
		this.adaptors += adaptor;
		this.g_test_suite.add(adaptor.get_g_test_case());
	}

	public virtual void setup() {
	}

	public virtual void teardown() {
	}
}

public interface SimpleTestCase : Object {
	public abstract void run(T context);

	public void add_to(SimpleTestSuite test_suite) {
		test_suite.add_test(this);
	}

	public string get_name() {
		return this.get_type().name();
	}
}

class TestRunner : Object {
	private GLib.TestSuite root_suite;

	private File tmp_dir;
	const string SCHEMA_FILE_NAME = "org.gnome.break-timer.gschema.xml";

	public TestRunner(ref unowned string[] args, GLib.TestSuite? root_suite = null) {
		GLib.Test.init(ref args);
		if (root_suite == null) {
			this.root_suite = GLib.TestSuite.get_root();
		} else {
			this.root_suite = root_suite;
		}
	}

	public void add(SimpleTestSuite suite) {
		suite.add_to(this.root_suite);
	}

	public virtual void global_setup() {
		try {
			var tmp_path = DirUtils.make_tmp("gnome-break-timer-test-XXXXXX");
			tmp_dir = File.new_for_path(tmp_path);
		} catch (Error e) {
			GLib.warning("Error creating temporary directory for test files: %s".printf(e.message));
		}

		string target_data_path = Path.build_filename(tmp_dir.get_path(), "share");
		string target_schema_path = Path.build_filename(tmp_dir.get_path(), "share", "glib-2.0", "schemas");

		Environment.set_variable("GSETTINGS_BACKEND", "memory", true);

		var original_data_dirs = Environment.get_variable("XDG_DATA_DIRS");
		Environment.set_variable("XDG_DATA_DIRS", "%s:%s".printf(target_data_path, original_data_dirs), true);

		File source_schema_file = File.new_for_path(
			Path.build_filename(get_top_builddir(), "data", SCHEMA_FILE_NAME)
		);

		File target_schema_dir = File.new_for_path(target_schema_path);
		try {
			target_schema_dir.make_directory_with_parents();
		} catch (Error e) {
			GLib.warning("Error creating directory for schema files: %s", e.message);
		}

		File target_schema_file = File.new_for_path(
			Path.build_filename(target_schema_dir.get_path(), SCHEMA_FILE_NAME)
		);

		try {
			source_schema_file.copy(target_schema_file, FileCopyFlags.OVERWRITE);
		} catch (Error e) {
			GLib.warning("Error copying schema file: %s", e.message);
		}

		int compile_schemas_result = Posix.system("glib-compile-schemas %s".printf(target_schema_path));
		if (compile_schemas_result != 0) {
			GLib.warning("Could not compile schemas in %s", target_schema_path);
		}
	}

	public virtual void global_teardown() {
		if (tmp_dir != null) {
			var tmp_dir_path = tmp_dir.get_path();
			int delete_tmp_result = Posix.system("rm -rf %s".printf(tmp_dir_path));
			if (delete_tmp_result != 0) {
				GLib.warning("Could not delete temporary files in %s", tmp_dir_path);
			}
		}
	}

	public int run() {
		this.global_setup();
		GLib.Test.run();
		this.global_teardown();
		return 0;
	}

	private static string get_top_builddir() {
		var builddir = Environment.get_variable("top_builddir");
		if (builddir == null) builddir = "..";
		return builddir;
	}
}

And here’s a really simple test suite and test runner:

public class test_Example : SimpleTestSuite {
	public string? foo;

	public test_Example() {
		new test_example_foo_is_bar().add_to(this);
	}

	public override void setup() {
		this.foo = "bar";
	}
}

class test_example_foo_is_bar : Object, SimpleTestCase<test_Example> {
	public void run(test_Example context) {
		assert(context.foo == "bar");
	}
}

public static int main(string[] args) {
	var runner = new TestRunner(ref args);
	runner.add(new test_Example());
	return runner.run();
}

Of course, you might note that this still isn’t thread-safe since we’re passing the same test_Example instance as the parameter for all of our SimpleTestCases, and the syntax is slightly unusual, but I’m quite fond of the extra brevity. One nice bit is this figures out the name of each test based on GObject type information, so we never need to write it explicitly. The test runner ultimately says that a test named “/test_Example/test_example_foo_is_bar” has passed, and it can deal with all sorts of stuff well away from the test code. It’s worked well so far, anyway.

So, that’s about it for the last two weeks. I also submitted an art request for some new icons, and I’m going to try following up on that where I can. This is definitely in the “polish” phase – just with a lot yet to be polished.

GNOME Break Timer: Week 10

Earlier, when I mentioned that I was going to work on polish, I was thinking of a rather unfortunate line in my original roadmap that honestly just said “polish.” I started this chunk of my GSoC project with a new list of things I have been putting off for said polish phase, and it turned out to be quite substantial. I have several cool new things this week.

First, I added a simple, custom container widget that allocates space for all of it children – whether or not they are visible – and distributes that space among the visible children. This way, our Break Schedule dialog is always the same shape, even though its contents change. This is sort of like using a GtkStack with the homogeneous property set to true. Once I wrapped my head around size requests and allocations and requisitions, it was really easy to implement. I’m not sure if it’s correct, strictly speaking, but it works for me.

class FixedSizeGrid : Gtk.Grid {
	public FixedSizeGrid() {
		Object();
	}

	public override void adjust_size_request (Gtk.Orientation orientation, ref int minimum_size, ref int natural_size) {
		foreach (Gtk.Widget widget in this.get_hidden_children()) {
			int widget_allocated_size = 0;

			if (orientation == Gtk.Orientation.VERTICAL && this.orientation == Gtk.Orientation.VERTICAL) {
				widget_allocated_size = widget.get_allocated_height();
			} else if (orientation == Gtk.Orientation.HORIZONTAL && this.orientation == Gtk.Orientation.HORIZONTAL) {
				widget_allocated_size = widget.get_allocated_width();
			}

			minimum_size += widget_allocated_size;
			natural_size += widget_allocated_size;

			widget.adjust_size_request(orientation, ref minimum_size, ref natural_size);
		}

		base.adjust_size_request(orientation, ref minimum_size, ref natural_size);
	}

	private List get_hidden_children() {
		var hidden_children = new List();
		foreach (Gtk.Widget widget in this.get_children()) {
			if (! widget.is_visible()) hidden_children.append(widget);
		}
		return hidden_children;
	}
}

The big thing I worked on over the last two weeks was making the break timer service remember its state between sessions. Break Timer will remember if you need to take a break after you log out or restart the computer, and in the future it will be able to keep track of interesting statistics very easily. This also makes it much, much harder to “cheat,” by accident or intentionally, because it will always pick up where it left off.

I decided to store the program’s state in the user’s cache folder using a json file, since we can work with json-glib quite nicely from Vala code. That happens when the process is (cleanly) interrupted or when gnome-session says it’s time to stop. (Thanks to Guilhem Bonnefille on gnome-devel-list for pointing me in the right direction about gnome-session). When the application starts, it reads that cache file and updates all its timers and counters accordingly. The way I implemented this leaves the door wide open for keeping breaks in sync between systems, over the network, which would be really cool.

I ran some finicky problems working on this; I guess I don’t usually have to work with quite as many moving parts. I was very glad that several years of people extolling the virtues of test-driven development (most recently David Cameron’s awesome Quality Assurance course at SFU) finally rubbed off on me: as soon as I wrote a test case for the problem I was working on, it all got way easier. And I got a (slightly clunky) test case for free! I must remember to do more of that.