elementary-dev-community team mailing list archive

[Daniel Foré <daniel@xxxxxxxxxxxxxxxx>]

Off the top of my head:

Source list (or if it doesn't make sense from an architecture standpoint for Geary, it should at least look like source list),
About,
Welcome,
Contractor,
Fix .content-view in the compose dialog,
Make the edit-mark icon inherit from the theme

On the long term:

Copy source list badges to the message list

Best Regards,
Daniel Foré

El feb 21, 2013, a las 4:08 p.m., Jim Nelson <jim@xxxxxxxxx> escribió:

> 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
>>>> 
>>>> 
>>>> 
>>> 
>> 
> -- 
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp