Tag Archives: gnome 3

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.

Why I Like GNOME 3 Shell

Friday night at the c-base pre-registration party Karen Sandler asked me what I thought of GNOME 3, and in particular, the GNOME 3 Shell.  Although I’m generally impressed with it and enjoy using it daily, I couldn’t enumerate for her solid, tangible reasons.  (It probably had something to do with the bottle of Berliner I was holding.)  She asked me if I would blog my thoughts.

Here they are, for whatever they’re worth.

Stability – Considering this is an initial release, I’ve found the Shell to be remarkably stable.  I’ve had no freezes or crashes.  While that seems like a low bar to overcome, this is essentially an 0.1 release.  Not much 0.1 code can make the claim that it’s stable.  Most 0.1 code is just happy it compiles.

Performance – When I heard in Gran Canaria that Javascript was a key technology behind the Shell, my thoughts immediately went to scalability — both in terms of performance (the common use of the term) and of code manageability (which is how I use that term some times).  I can’t speak to the latter point because I’ve not dived into the Shell source, but in terms of the former, I find the Shell to be speedy and brisk.  The only stalls I’ve experienced were when the machine was under load.

Productivity – I should list this first, but I decided to save the best for last.  My productivity has jumped since I switched to GNOME 3 Shell.  This might be a highly subjective evaluation.  I suspect I’m not alone.

I suffer from a common malady, Easily Distracted Syndrome (EDS).  Flashy lights, running gauges, televisions tuned to static — anything blinking or back-lit steals my attention away from what’s in front of me.  GNOME 3 Shell’s minimal and colorless chrome keeps me focused on the work at hand.  This is a good thing.  Windows is by far the worst offender, but all desktops are culpable.  Jeffrey McIntyre at Slate wrote about this problem in 2008, noting that “Our desktops are now a thick impasto of tabbed windows, pull-down menus, dashboard widgets, and application alerts. No possible distraction gets left behind, no link, feed, IM, twitter, or poke unheeded.”  Since computers are supposed to help productivity, changing this state of affairs should be a high priority for any desktop designer.

I like that GNOME 3 Shell doesn’t have a lot of widgets to play with.  The Tweak Tool is about is far as it goes, and I’m happy with that decision.  With GNOME 2 Shell, whenever I created an account on a new machine, I was in for at least an hour’s worth of work rearranging the desktop to my liking.  When I sit down to a GNOME 3 desktop, there really isn’t much to do — but I do twiddle with it.  The following are changes I wish would be made to the out-of-box experience:

(Note: I’m sure all of these have been debated ad infinitum in chat rooms and on mailing lists.  I’m still going to list them.  Think of these as a kind of late vote — open-source hanging chad):

Power Off… – I understand the impulse to stay as minimal as possible, but requiring me to log out in order to power off the machine is frustrating.  I use a GNOME Shell extension to add Power Off… and Suspend to the system menu (it also adds Hibernate, which I could live without).  I can’t believe I’m the only one grumbling about having to find and install this extension.  One of the big guffaws over UNIX’s predecessor Multics was that you had to log in in order to log out.  (The myth came about because of a feature that could lock the console, much like screensavers today.)  Unlike this bit of Multics lore, make no mistake: with out-of-the-box GNOME 3, you have to log out in order to turn off the machine.

Weather indicator – This is the one distraction from the GNOME 2 Shell I wish was moved to GNOME 3.  Yes, there’s a couple of weather indicator extensions out there (here’s the one I’m using), but they’re rough around the edges, hard to configure, and have to be installed separately.  If the new Shell can support calendaring in the clock drop-down, certainly it’s not a stretch to have a weather indicator in the top bar as well.

Desktop – Some people never use ~/Desktop for anything.  Others store their entire lives in it.  I more or less fall in the former camp, but I do keep a few documents on my desktop now and then.  Beyond my personal habits, it’s an odd state of affairs that to the user the entire desktop background is an inactive, inaccessible void.  Fortunately the GNOME Tweak Tool allows for Nautilus to manage the desktop much as it did in the past.  That was the first switch I threw to ON when I ran the tool.

None of this is particularly damning, and in all I think the GNOME 3 Shell designers have done a great job.  Certainly I wouldn’t call it an “unholy mess” and then demand that the designers add features back, as though the way to clean a room is to toss more stuff on the rug.  With a few careful additions here and there, the experience would be just right.

I keep going back to the productivity gains I mentioned earlier.  Perhaps that’s the best compliment I can pay to the group: Your creation stays out of my way, which is exactly what I want.

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!