Tag Archives: gtk

Introducing California, a new GNOME 3 calendar


When Yorba announced Geary some time back, one question we were often asked was, Where’s the calendar?  When we replied that Geary was not going to have a calendar — that it was an email client, nothing more — the question often turned into a request: Will you make a calendar app then?

We saw it coming.  When we were planning Geary, we talked internally about calendaring and its close relationship to email.  We agreed that, like our approach to Geary, that was best handled by a dedicated application rather than bolted-on as yet another feature.

So it’s not terribly surprising for me to announce that Yorba has begun work on a new calendar application for GNOME 3: California.  The philosophy that guided our development of Geary is present in California as well: simple to set up, quick and easy to use, focused on its particular task but flexible for each person’s workflow.  The first commit was in January and work has progressed far enough that we’re ready to start talking about it.


The current implementation relies on Evolution Data Server (EDS) for all backend calendar operations, but the code is architected so other backends (such as GData) can be added later, perhaps even broken out as plugins.  The design is to use most of the modern GTK widgets and design goals, including GtkHeaderBar.  A lot of features are still unimplemented, of course, but development is continuing.

For more information and links, visit California’s home page.  Our ticket list is a good way to see what’s on the immediate horizon and report bugs and feature requests.  You can also subscribe to the California mailing list to discuss the application’s current state and future.

Be aware that in its current implementation you’ll need another EDS client (i.e. Evolution) to add and configure the calendars visible to California, but we hope to soon have that implemented as well.  And, no, Geary and California don’t talk yet, but that’s in the works.

What about GNOME Calendar?

One question we’ve already been asked is, why not work on GNOME Calendar?  We have a few reasons.

First, GNOME Calendar is written in C.  I know it sounds like language-chauvinism, but that’s not the language we at Yorba feel should be the future of GNOME application development.  (That is, the language for developing full-blown applications; I’m fine with C for the underlying libraries, although I would still suggest library developers consider Vala.)  It’s not fear of C itself, it’s the boilerplate and bookkeeping that GObject C development requires that becomes more and more onerous as a project grows.   It’s also the ramp-up required for new contributors to make productive patches.  We have coded two mature applications, Shotwell and Geary, in Vala.  We have good reasons for coding a third in the same.

Second, I have particular opinions about the underlying design (not merely the user interface) for a network calendar application that I felt were not being approached in GNOME Calendar, or indeed in other calendar applications we looked at.  With California I’ve put a bit of work into a flexible date and time model that treats date spans as iterable collections; makes various units of time (weeks, months, years, etc.) iterable date spans as well as concrete units; knows the difference between calendar time and wall clock time; can deal with iCal‘s timezone model; and so forth.  The date/time model is cleanly separated from the backend network connectors and from the UI itself.  It also makes full use of GObject’s properties and signals so they can be directly bound to GTK widgets.  This is a GObject application; let’s live and breathe GObject then.

Third, the knee-jerk reaction that everyone in the GNOME community should be working on a single set of applications is not realistic nor a vision for growth.  There’s nothing wrong with GNOME users having choices for their applications.  Parallel development of applications even fosters growth as one team takes ideas from another, and vice-versa.  Some people like Thunderbird, some people like Evolution, some people like Mutt, some people like Geary; what’s wrong with that?  I suspect the idea is that it’s better to pool all available resources behind one code base, but that assumes a flawed one-size-fits-all vision of software that is less true in 2014 than it ever was before.

Shotwell and GNOME 3

Earlier today I created a new branch in the Shotwell git repository called “gtk3”.  This branch holds a version of Shotwell that builds successfully under GTK+/GDK 3.

Due to time and resource constraints, we don’t have plans to have a GNOME 3 version of Shotwell ready for its 0.11 release.  The gtk3 branch will be maintained and updated through the 0.11 cycle to keep it from straying too far from the trunk.  At some point (most likely during 0.12 development) we’ll merge it back into trunk.  At that point, Shotwell will be a GNOME 3 application.

Although Shotwell compiles and runs under GNOME 3, there are some notable outstanding bugs.  The ticket title is prefixed with [gtk3] to distinguish them from bugs that cross both versions.  The GTK+3-specific issues include:

http://redmine.yorba.org/issues/3455 – Port to GTK+3 (this is the umbrella ticket for the complete task)
http://redmine.yorba.org/issues/3869 – [gtk3] Histogram not drawn correctly
http://redmine.yorba.org/issues/3870 – [gtk3] Horizontal scrollbar appears in checkerboard pages
http://redmine.yorba.org/issues/3871 – [gtk3] No text in publish progress bar
http://redmine.yorba.org/issues/3872 – [gtk3] Verify I18N
http://redmine.yorba.org/issues/3873 – [gtk3] Search bar problems
http://redmine.yorba.org/issues/3874 – [gtk3] Basic Information pane has no border

We encourage anyone who’s interested in the future of Shotwell under GNOME 3 to try out this git branch.  To download from our repository:

$ git clone git://yorba.org/shotwell
$ cd shotwell
$ git checkout gtk3
$ ./configure
$ make

You can run Shotwell from the build directory or “make install” to run from its installed location.

To reiterate, this branch is under active development and not slated for the 0.11 release.  In other words, use at your own risk.  It’s worth taking the time to back up your Shotwell database before use:


If you do find a bug or an issue, please let us know by reporting it to our Redmine server:


If the bug seems to be GTK+3-specific, please prefix the ticket title with [gtk3].  Thanks!