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.
Jim, I wish you the best on this endeavour. I’ve been waiting for a native GNOME/GTK calendar app with proper attention to usability details since… 2005.
Evolution’s calendar has a few dealbreaker issues: http://jeff.ecchi.ca/blog/2011/06/25/evolutions-calendar-looking-for-love/
It kinda baffles me how nobody except Google Calendar, iCal and Sunbird ever got basics like “drag and drop” correctly. Please please please nail this down. I want to be able to drag and drop any event from anywhere to anywhere (to move events in month view, week view, day view), to shorten or lengthen events, etc. Google cal is pretty close to perfect in that regard, though I’m willing to be impressed by new and better workflows.
Then:
– “upcoming weeks” view. I don’t care about the past, I only want to see the next 3-4 weeks (configurable) from today. There are some corner cases where I switch to month view to see the boundaries or delve into the past, but they’re rare occurrences.
– Multiple timezones support, perhaps with a nice autocompletion/map widget. I don’t know what time it is in Berlin and if we’re DST or not, I just know that my appointment is with someone there and I’m on the other side of the world and I must be able to trust the computer on that.
– Reminders that actually work and pop up at the proper time. I don’t know what’s the deal with Evolution’s appointments showing at the wrong time (or not at all) half of the time, or “snooze/remind me later” not always working; I’ve grown to not rely on them for the past few years. Create some crazy test suite and prove to me that this thing works flawlessly please 🙂
Do all that and you have my seal of approval 🙂
Google cal integration/other sync mechanisms? Nice to have, but secondary to all of the above.
Bonus points for natural language parsing in both English and the user’s locale (ex: creating an event by typing “TPS report meeting next tuesday at 14h40 for 35 mins at room 2044 #work #online”)
All those demands, and nothing to offer except for a “seal of approval”. How about you get your wallet out and make a DONATION of approval.
I love it! The calendar app was the last app I was missing on my Gnome desktop. It looks fantastic! I’m really happy you are using the modern Gnome widgets to integrate it smoothly to the other Gnome core apps! I’m really looking forward to it. Thanks a lot!
Completely agree! I think it’s great that users get a choice. There is no one app that is going to suit all people’s needs and some things could be implemented better than others. 100% percent support this!
Really happy to hear that yorba is working on this. It will receive a warm welcome to my collection of apps, that’s for sure!
good work!
Coding calendars can be surpisingly tricky, it sounds like you’ve come up with a good model.
This app is just what I needed to make Google Calendar integration in Gnome perfect! Good work!
You guys are always making the most elegant software for linux, thank you for all your hard work!!! Ever look into elementary OS?They seem to have a look and feel more like what you do then default ubuntu.
What about Maya? It’s elementary’s calendar powered by EDS and written in Vala.
Haha I asked the same question an hour later than you. Too bad Jim has not answered.
Hey Jim, this looks awesome!
I was curious, though, what were your reservations about working on Maya Calendar, from elementary. It is obviously not written in C, so I assume it had something to do with the time handling or the network backends.
Anyway, I wish you good luck, and hope California turns into a great calendar application.
Thank you for this. I am looking forward!
I think the EDS thing is a brilliant idea! But if you add eds support, not only stop here, but add options to import ical, webCAL, etc pls as well! I know that if you use evolution you can import those data trough evolution, but such options should be there in California (btw. a brilliant name!) from the get go!
It looks great!! California will be gnome dependent, or it will be possible to use it in other gtk based DE like xfce or elementary without extra dependencies?
And for curiosity, do you think rust will be an interesting languange to change from vala in the future for gnome environment since it looks quite promising?
Thanks for your great work!! 😉
Looks great!
Thanks for keep pushing open source further.
This is great news! Thank you!
Have you considered JavaScript instead of Vila?
If you look at the Brackets project the amount of developers that have contributed is mind blowing! For every Linux contributor they have they have 100 Windows contributors. If they had chosen a platform dependent language, they would at this point maybe have released version 2 instead of the current version 37.
Go and Dart are also very popular alternatives, where Docker is written in Go, and have also a very impressive amount of contributions from all platforms.
I don’t think a good email and calendar program is a unique problem to Linux. Also being able to run Geary and California on Linux at home, and on Windows at work, would make it even more enjoyable =)
Windows has many, many more users and developers than Linux/GNOME and it’s still complete and utter garbage. You are clearly very new to this game. Come back in about 5 years when you have a clue.
JavaScript…? Pfft.
Hey Jim! Really happy to see this; it looks promising indeed. Let me know if you want to talk design at any point. 🙂
Will this integrate with Google Calendar?
Yes.
Great!
Echoing Shnatsel and others: Why not Maya?
Will this integrate with Firefox OS Calendar?
Still no comment on maya!?
I cannot wait for a native calendar app in Ubuntu. Thanks guys. Hope there’s a version to be downloaded soon. 🙂
I wanna see it combined with the at/chron command. That way it could do something on my pc on a certain date.
Still no comment on maya!?
Will this integrate with Firefox OS Calendar?
Only if their calendar uses EDS for its backend, which it probably does not.
However, if their calendar stores its information on the network in a CalDAV or WebCal location, then California can read (and synchronize) from there.