It’s been a good first day at the first ever West Coast Summit in my native city of San Francisco. A good turn-out all around and a lot of interesting talk about what’s next for GTK, particularly under-the-hood.
I’d like to extend my thanks to Endless Mobile for offering us their fantastic space in SoMa for us GNOME folk to use. Cheers!
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.
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.
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:
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.)
In October I briefly announced that Yorba was virtually moving — that we were in the process of transitioning from our self-hosted project server to GNOME’s infrastructure. Well, the move is all but complete. I’m pleased to announce that we’re now officially hosted inside the GNOME ecosphere: Bugzilla, git.gnome.org, mailing lists, the works. Here are links to our new wiki.gnome.org pages:
First, let me clarify that the Yorba Foundation has not merged or become subsumed by the GNOME Foundation. Financially and legally we’re still independent entities, albeit with a shared goal of spreading free software far and wide.
So, why’d we do it?
Yorba has always been a GNOME developer. Our applications are GNOME-specific and we build them with GNOME technologies and libraries. For almost five years now we’ve enjoyed a certain independence developing from outside the GNOME infrastructure, but we also were giving up a certain amount of integration that perhaps would’ve made our offerings that much better. It’s a trade-off. Recently we re-evaluated those trade-offs and decided that it made sense for Yorba to move into a tighter GNOME orbit. As such, we look forward to working closer with the GNOME team on things like application design and the future direction of the free desktop.
Yorban Charles Lindsay did a great job moving a mountain of our data to gnome.org, in particular our voluminous ticket database, which is approaching five years old. Not only are all our tickets now imported into GNOME’s Bugzilla (even their attachments), the final entry in our legacy Redmine tickets include instructions on how to locate that ticket in GNOME Bugzilla. He automated much of this with a Python script we’ve made available on github in case someone else out there needs to move their tickets (“issues” in Redmine parlance) from Redmine to Bugzilla.
I’d like to extend deep thanks to GNOME sysadmin whiz Andrea Veri for making the transition about as painless as I could imagine — no, even less. Andrea guided us through this process with grace and steady vision. I’d like to echo William Jon McCann’s call to “ensure Andrea Veri’s contract is renewed and stays on as the GNOME sysadmin”. You have Yorba’s vote, av!
In the past, Yorba used a standard sequential versioning scheme (0.1.0, 0.1.1, etc.) To differentiate between stable releases and builds from source control, we appended a descriptor to the version number (0.1.1+trunk, 0.1.1+branch). When we needed to issue pre-release tarballs to our partners, we used a different descriptor (0.1.1pr1, 0.1.1pr2).
Over the years we received a number of complaints about this, especially from package and repository maintainers (whose business, if you think about it, is very much about version numbers). With our move to GNOME, it seemed like a good time to revisit our scheme. The one numbering system we kept hearing was worth adopting was GNOME’s itself, where even numbers represent stable releases and odd numbers represent unstable releases. (I believe GNOME adopted this from the Linux kernel; where they got it from, or if they invented it themselves, I don’t know.) In addition, it was requested that we release unstable tarballs more often, to give distributors and packagers more time to prepare.
We decided to make the switch and have already adopted this with Geary. We recently released an 0.5.0 unstable, and will follow up soon (probably after the holidays) with an 0.5.1, and so forth. The next stable release of Geary will be 0.6. Similar changes will be coming soon for Yorba’s other projects.
One goal we have is to move all our projects that require internationalization into GNOME’s system. We’re not quite there yet; we need to do a little more work on our build systems in order to integrate fully. I hope to get that wrapped up next month. If you’re eager to offer translations for our projects, all I can ask is for your patience until we get this resolved. (If you’re a GNOME internationalization whiz, we’d appreciate your help in finishing the work.)
Due to this expected move, I’ve closed our Transifex project repositories. If you’ve made some translations recently, don’t worry, they’re not lost, I simply haven’t merged in the final snapshot of those strings. I’ll do so after the holidays.
Even though we no longer use it, we’ve decided to keep our Redmine project management server up for historical reasons. We’ve locked it down to prevent any changes.
With the server transition we also decided to clean house a bit. Over the years Yorba has developed or adopted technologies that didn’t get off the ground. Although Yorba is no longer maintaining them, we didn’t want them to simply disappear, as so we’ve moved them to our public github repo. The projects I’m speaking of are media (our early attempt at audio/video editors) and Valadate (a Vala-based unit testing framework).
Earlier this year Lionel Driscot’s “The Last GUADEC” was slashdotted, redditted, and everthing else-itted that can happen to a viral blog post in the tech community. It’s a provocative piece. It also sparked for me the impetus to write this entry, which I’ve been mulling over for a few months.
My one nit with Driscot’s post are the questions he ends with, his call to action:
How can we evolve? Can we move the GNOME spirit into a web browser? How can we make use of our history and bring freedom to users instead of becoming just another web dev consultancy company?
These are not the questions I would have asked. I do not believe the answers to these questions will yield appreciable fruit.
Here’s a portion of Emmanuele Bassi’s response to Driscot’s post (which I can no longer access, unfortunately):
GNOME is about building a whole operating system, and a whole ecosystem of apps, libraries, and tools, for people to create applications to consume and to create content.
This hovers closer to the questions I would have asked.
GNOME’s stated goal of “a complete free software solution for everyone” seems to me to be four-fifths met. What GNOME offers is (1) free, (2) software, (3) a solution, and (4) for everyone. I question the word complete.
I say this specifically as an application developer, not as someone maintaining a library or writing development tools. Yorba isn’t even a cross-platform developer. We target UNIX, and, frankly, we’re not proactive about any flavor of UNIX other than Linux. Our requirements for a development platform aren’t particularly stiff. Yet even slicing away Windows and Mac support, I still think GNOME is far from complete.
Here are the questions I would ask in place of Driscot’s:
If I was a developer building Mac, iOS, Windows, or Android applications, I’d be able to answer those questions. I honestly can’t answer those questions as GNOME application developer, at least not in full.
Thinking about those questions got me to thinking about another: What’s missing from the GNOME platform? I’ll take that up in my next post.
The past couple of weeks we’ve seen new interest in gexiv2, the photo metadata library Yorba developed specifically for Shotwell Photo Manager. The reason? GIMP has adopted gexiv2 (and therefore Exiv2) for their photo metadata needs.
So what is gexiv2, and how is it related to Exiv2, beyond the name past the initial “g-“?
In 2010, as Yorba was adding features and expanding file format support in Shotwell, we realized its photo metadata support was lacking. Shotwell was using libexif, a workable but spare library that only offered support for (surprise) Exif, one of three major photo metadata formats. The other two (IPTC and XMP) are not nearly as widely-used as Exif, in particular with JPEGs, but are still out there and needed to be supported.
So we started looking around for alternatives. We found our solution in Exiv2, a Swiss army knife for photo metadata. There was a problem: Exiv2 is written in C++, a language we can’t directly call from Vala. We needed an adapter of some kind, a C-to-C++ bridge. It would be even better if that adapter spoke GObject. We began to hash out how such a wrapper might work.
It turned out someone was one step ahead of us. Mike Gemünde had started a project called gexiv2 that wrapped Exiv2’s C++ with a C GObject interface — perfect! (The original repository is still available here.) It was incomplete, so we contacted him asking if we could contribute. Mike was focused on a C# photo metadata library and suggested we take gexiv2 over. We’ve been developing it since.
It’s been great working with the GIMP developers so far, in particular Michael Natterer and Jehan Pagès. We’ve received two significant patches from them, including a rework to move gexiv2 to autotools. This in turn allows gexiv2 to build on Windows, something we’d not targeted at all when we began development but is obviously a hard requirement for GIMP.
I’m certain there are a lot more work and improvements to come. Shotwell has gotten plenty of mileage out of Exiv2, but GIMP will definitely exercise all its control paths.