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,
Victor.
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.
Regards,
Hakan
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.
Thanks,
-- Jim
