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.
Friday night at the