← Back to team overview

elementary-dev-community team mailing list archive

Re: Granite and Geary


I apologize for the overdue response, we've been busy here with Shotwell and Geary and, as you may've heard, the crowdfunding campaign we'll be starting shortly.

Victor, I hope you're still up for taking on this project.  I should tell you, today I've removed Granite support from Geary.  As you can see, it wasn't much: http://redmine.yorba.org/projects/geary/repository/revisions/45aca6d22cfcbebe2bfc526d6c346b81bdd908df

Looking over the suggestions so far in this conversation, I think Welcome Screen is a good starting point, with one caveat.  Geary today already has a Welcome dialog that allows the user to type in their email particulars and get started.  Would the Granite Welcome Screen replace this or simply be shown before our Welcome dialog?

The one nice thing about Welcome Screen is (I think) there's an easy way to hook this into the application, so it should be fairly effortless.

We're pretty darn busy around here, but I do want to get started on this.  Victor, I recommend cloning our git repo on your local machine (or github, or Launchpad, or wherever you like, I suppose) and begin hacking on Geary to add the Welcome screen.  I suggest the following steps:

1. Add a ./configure option to enable Granite support, i.e. --enable-granite-support.  Look at --enable-ref-tracking to see how to do this. 2. Again using ref tracking as a model, add GRANITE_SUPPORT to the valac command-line if the configure flag is set.  This means we can use #if GRANITE_SUPPORT (or whatever name we pick) in the code.
3. Create a src/client/granite directory.
4. Create a geary-granite-application.vala file in that directory.  Add it to the CMakeLists.txt file so it's built with the client code. 5. GearyGraniteApplication should subclass GearyApplication.  The entire class should be surrounded by #IF GRANITE_SUPPORT. 6. In src/client/main.vala, instantiate GearyGraniteApplication rather than GearyApplication using #if again.

This is my general game plan.  With this basic framework in place, you can start hanging Granite-specific code off of GearyGraniteApplication.  In the future, as hooks may be needed, GearyApplication (or its other classes) can be modified to suit your needs.

When Elementary builds Geary, their packaging should use the flag you've added.  If all works well, we'll have a Granite-enabled Geary application.

Does this sound good?  Let me know!  Feel free to ping me if you have questions.  It might take a while, but I'll do my best to get back to you.

-- Jim

On Tue, Feb 26, 2013 at 11:33 PM, Victor <victoreduardm@xxxxxxxxx> wrote:
Hi Jim,

Sorry for the late response!

In regard to your question, I would like to start working on the welcome screen because it's easier to implement and doesn't require adding many new abstractions. I'd also work on Granite to add the features needed by Geary, as I had already mentioned in the respective issue/ticket.

Adding code to have Geary use Granite's Source List (A.K.A. sidebar) implies a lot of work, since the APIs are very different. You can have a look at Granite's API here: http://pastebin.ubuntu.com/5559185/.

Being the developer who implemented Granite's Source List, I know how to make Geary's sidebar have an elementary-like look on top of your current API, and I'm already familiar with Geary/Shotwell's Sidebar implementation, but I doubt this is the approach you want elementary to take here.

Before jumping into coding I would like to have a technical discussion regarding the design implications of these changes in order to gather all your opinions and suggestions. I know that you are very busy, and I don't want to take a lot of time away from you. So, is there any specific time when I can meet you up, introduce myself, and discuss this?

Have a nice day and thank you for your time,


On Thu, Feb 21, 2013 at 6:08 PM, Jim Nelson <jim@xxxxxxxxx> wrote:
Hi Victor,

No one else has come forward, so it looks like you have the field!

I don't think more than 2 days a week are necessary here.  Mostly it's about maintaining a few slight changes to the code, not a big overhaul.

Let's start by discussing what Granite changes you (or the Elementary team) want to see in Geary.  We can prioritize those and go from there.

These are the outstanding Granite tickets in our Redmine tracker:

About Box - http://redmine.yorba.org/issues/6089
Welcome Screen - http://redmine.yorba.org/issues/6090
DecoratedWindow for composer - http://redmine.yorba.org/issues/6112

I'm sure there's more, this is just a starting list.  Anyone want to pitch in more ideas?

-- Jim

On Sat, Feb 9, 2013 at 12:34 PM, Victor <victoreduardm@xxxxxxxxx> wrote:
Nice suggestions Jim.

> This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API

I would not like to assume this responsibility alone, but I'd definitely like to contribute; count on me for this. I am only available two days per week though: Wednesday and Thursday.

On Thu, Feb 7, 2013 at 6:03 AM, Hakan Erduman <hakan@xxxxxxxxxx> wrote:
Hello Jim,

First, I'm not involved in the development of granite, midori or any elementary project.

As a bystander and developer I wonder why you did not try to reap the experiences of the midori project first. Midori pre-dates elementary and yet there is full integration - I wonder how they achieved it and so should you, I think.

Secondly, as a fellow developer of a small and notoriously underpowered free software project, I used to track every ubuntu release and found that a six month cycle is often too narrow. Tracking the LTS releases only is a very sound decision of the elementary project, I think.
Please consider the decision.

Just my $0.02, no offence meant.



Jim Nelson schrieb am 06.02.2013 22:16:
Hello all,

I'm Jim Nelson, executive director of Yorba and technical lead of Geary.  I've been communicating a little bit with Daniel about the future of Geary.  He asked I share my thoughts with all of you.

First of all, I'm excited that Geary is the default mail app for Elementary, the first distro to adopt, which is always an honor.  It also represents the kind of risk-taking that smaller distros will take, and I appreciate that.

However, as much as Yorba values what Elementary is bringing to the open desktop, we can't target Geary solely for it.  More specifically, I'm uncomfortable targeting Geary for Granite.  The Granite API seems to be fluid right now.

Yorba's policy for all our apps is to build on the current release of our dependencies, as well as the prior release, in the GNOME six-month cycle.  In practice, this means depending on the libraries in the current release of Ubuntu and the prior one.  For example, right now Geary builds on Precise and Quantal.  (It may build on older versions, but we don't guarantee that.)  At some point in this cycle we'll move to Raring.  Geary *may* build on Precise indefinitely, but if we need something in a library that wasn't available in Precise, then so be it.

This model means that our users don't have to be using the absolute latest-and-greatest, but also means we can take advantage of more-or-less the newest stuff.  It also means we don't fill our code base with conditionally-compiled patches to support newer library features while maintaining support for older ones.

Another policy Yorba adheres to is that we want trunk (master) to build, always.  This is quite important to me.

So here's our conundrum: Geary today has a sliver of Granite support #ifdef'd in.  It compiles under Precise but not Quantal due to some deprecated symbols.  I know more work on Granite is coming, which means Geary will fall farther and farther behind without active maintenance.  And we do have a number of requests for additional Granite support.  The umbrella ticket for that work is at http://redmine.yorba.org/issues/6088

We don't want that to happen.  We also don't want to fill Geary with a lot of conditional compilation code to support Granite.  So, as I said: a conundrum.

What I'm proposing is for a member of the Elementary community to step forward as a Geary champion: someone to actively work on a Granite version of Geary.  I propose doing that via two tried-and-true techniques of modern software development: object-oriented code and distributed source control.

To break it down:

* We'll work with this champion to refactor the Geary client in such a way that subclasses can hook into various events and provide Granite-specific UI elements over generic GTK elements.

* This champion will write the Vala code that subclasses Geary's client and calls Granite.

* Where this code lives is up for discussion.  One path is for this champion to fork Geary (i.e. on Launchpad) and add the Granite code to the fork.  Another path is for this code to live in the Yorba repo and is activated via a configure switch.  (Yes, this is conditional compilation, but the idea is to conditionally compile in *files*, not fill the existing files with #if's.)  We're doing something similar to support Ubuntu's Messaging Menu and Unity task bar.

* Elementary will need to build Geary in a PPA that enables this configure switch.

* This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API.  If the code lives on in the Yorba repo, we'll take those patches more or less as-is.  In other words, this champion (and, by extension, Elementary) is taking responsibility for this code.

The result of these steps, and the goal of this email, is to (a) make Geary a full-fledged member of the Elementary desktop, (b) keep Geary working on other desktops where Granite is not installed or is an older version, and (c) allow Elementary to make rapid changes to Geary so it represents Elementary's latest efforts.

This above is a proposal and not set in stone.  Comments and questions are welcome.


-- Jim