I’m pleased to announce the release of California 0.2, Yorba’s GNOME 3 calendar application. A lot has happened since we announced California (way back in March) and I’m happy to say that we got more features into this first release than I thought we’d make. Version 0.2 offers the following:
Month and Week views of events
Add and remove Google, CalDAV, and webcal (.ics) calendars
Integrates with Evolution Data Server, so your existing Evolution calendars are automatically available
Add, view, edit, and remove events (including recurring events)
A natural-language Quick Add parser for easily adding events: just type in the information and California schedules the event(s)
F1 online help (thanks Jim Campbell!)
Smooth animations and popovers for viewing information effortlessly
We’ve released Geary 0.8 and Shotwell 0.20 today and I’m pretty excited about getting these out the door to our users. Both releases include important fixes and some great new features.
Geary 0.8
While Geary 0.8 has a slew of new features and improvements, I would say the most visible for our users (compared to 0.6) are the following:
Robert Schroll’s redesign of the mail composer. Not only does it look a lot sharper and more modern than before, it also operates inline in the main window—that is, you type your reply right below the email you’re responding to. This means replying to a conversation is a more natural operation than opening a separate window or switching to a new view. You can still pop the composer out into a separate window, just press the Detach button and you’re on your way.
Gustavo Rubio’s hard work to get signature support into Geary. Now Geary will automatically insert a signature of your design into an email, whether new or replying to another. This is one of the most-requested features for Geary, so it’s good to get this in.
I’ve put in some hard work on improving database speed and IMAP connection stability. There’s still a couple of kinks here and there, but I feel like 0.8 is a big step forward in making Geary the kind of application you can leave on for days at a time without worrying about it slowing down, crashing, or losing its connection to the server.
In other words, if you’re a Geary user, you really should upgrade.
That said, here’s a more formal list of improvements:
Major redesign of email composer, now presented inline in main window
Composer will automatically add signature to emails
Saving drafts to server can be disabled
Improved interface, now using GtkHeaderBar and modern widgets
Database speed optimizations to reduce lags and improve read times
Improved connection handling and reestablishment
Show attachments lacking a Content-Disposition
Important bug fixes
Updated translations
The tarball for Geary 0.8 is available here. Visit the Geary home page for more information.
Shotwell 0.20
Shotwell 0.20 has a more modest set of improvements, but it’s still growing and developing. In particular, new photo sharing plugins were added and stability fixes have been included:
Support for Rajce.net and Gallery 3 photo services
Set background image for lock screen
Better detection of corrupt images during import
Important stability bug fixes
Updated translations
The tarball for Shotwell 0.20 is available here. Visit the Shotwell home page for more information.
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.
Eureka!
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 theworks.
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.
We at Yorba are pleased to announce the release of Geary 0.6.0, a new stable version of our IMAP mail client. Much has changed since our last stable release, including:
Basic search scope operators, such as from:john
An oft-requested “save sent mail” option for non-Gmail users
Separate actions for archive, trash, and delete
Much improved server support — if you found Geary unusable in the past on a Dovecot or other non-“cloud service” server, I’d urge you to give it another go
Many stability, speed, and interface improvements and bugfixes
Last Friday Daniel Foré made an announcement on elementary’s mailing list that has generated a considerable amount of interest:
Shotwell needs a new maintainer. … After some discussion with Jim, we think the best course of action is for elementary to fork Shotwell.
OMG! Ubuntu reported later that day (and with surprising speed) that “Elementary To Take Over Shotwell Development”. I’ve received emails from people wondering what this means for the future of Shotwell.
To be clear, Yorba remains the maintainer of Shotwell. elementary has not taken it over. Yorba recently took the rather large step of moving Shotwell and all its associated work (including our ticket database, wiki pages, architecture guidelines, and more) into the GNOME infrastructure. We didn’t do all that work just to hand the keys over to another group on another platform. We made the move because, when we did all the calculus, we agreed GNOME was the best location for the future of Shotwell. Going into the GNOME infrastructure opened (and is still opening) a lot of doors for us. However, Yorba’s resources are limited, and as of late we’ve not been focused full-time on improving Shotwell.
This put us into a bind, and so I began looking for outside individuals or groups who would be capable and willing of contributing to Shotwell in a more substantial way. I kept coming back to a group that has shown a great deal of energy and motivation in the past and a willingness to work with us: elementary. They expressed a lot of interest in improving Shotwell, and so we began a discussion about how that situation might look. In the end, we reached an understanding:
Shotwell will continue to be maintained by Yorba. We’ll triage bugs, take patches, fix critical bugs, ensure it builds with the latest versions of Vala and supporting libraries, and runs on the major distros. Yorba will continue to release Shotwell on a six-month schedule.
elementary agreed to jump in and improve Shotwell, but stated that all of their development must occur on Launchpad. They also wanted to rebrand the project to fit under their design umbrella. This includes integration with Contractor and other technologies they’re building for their OS.
It was agreed that they would fork the project to Launchpad and rename it Pantheon Photos to distinguish it from Shotwell. The pragmatic reason for this is to prevent name collisions with packaging. This also allows for elementary to customize Shotwell to their own platform and brand it separately.
As Shotwell maintainers, we’ll evaluate elementary’s work and look for commits that are useful to Shotwell users. We’ll cherry-pick that work and merge it into the Shotwell base.
elementary agreed not to relicense Shotwell, so its current license (LGPL 2.1) stands.
While elementary has big plans for Pantheon Photos, none of that work is happening in private and we’re free to take improvements as we wish (and likewise they’re free to pull improvements from Shotwell’s code base).
Additionally, this situation already exists, and has existed for years, with Ubuntu: they maintain their own fork of Shotwell to provide integration with Ubuntu Online Accounts. (I’ve referenced that situation before.) elementary is doing this on a larger scale, admittedly, but it’s not unique in the world of open-source and shouldn’t be a source of alarm.
(I regret that Daniel wrote “Shotwell needs a new maintainer.” I was privy to that email before it was posted and should’ve asked he reword it. That was my fault, not his.)
I can’t emphasize enough that Shotwell is not being discontinued or end-of-lifed, and elementary has not “taken over” Shotwell. We’ll continue to maintain Shotwell and release versions with our usual distribution targets. This is why I tweeted that this situation is a win for everyone (a sentiment echoed by Bryan Landuke) — users won’t necessarily have to pick-and-choose which app they want to use, or even which distribution, in order to manage their photos.
JIm Nelson's blog + archives from Yorba Foundation's original blog
I’m pleased to announce the release of California 0.2, Yorba’s GNOME 3 calendar application. A lot has happened since we announced California (way back in March) and I’m happy to say that we got more features into this first release than I thought we’d make. Version 0.2 offers the following:
