elementary-dev-community team mailing list archive
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:
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
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
1. Add a ./configure option to enable Granite support, i.e.
--enable-granite-support. Look at --enable-ref-tracking to see how to
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
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
On Tue, Feb 26, 2013 at 11:33 PM, Victor <victoreduardm@xxxxxxxxx>
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
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
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:
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
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?
On Sat, Feb 9, 2013 at 12:34 PM, Victor <victoreduardm@xxxxxxxxx>
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>
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:
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
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
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
* 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
This above is a proposal and not set in stone. Comments and
questions are welcome.