On Tue, 2011-04-19 at 19:02 -0400, Matthew Barnes wrote:
> On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote:
> > Note the 'gboolean retrying' argument to the libsoup "authenticate"
> > signal handler. We probably want to have something similar in the above
> > API too, because that's what
On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote:
> Note the 'gboolean retrying' argument to the libsoup "authenticate"
> signal handler. We probably want to have something similar in the above
> API too, because that's what tells the UI that it needs to ditch the
> existing remembered pas
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote:
>
> 2) ECredentials is way too complex. My intent for ECredentials was to
>have a self-contained authentication handling interface to avoid all
>the current nonsense with ECal and EBook where you have to always
>remember to conn
On Tue, 2011-04-19 at 21:00 +0200, Denis Washington wrote:
> During today's round of jhbuilding I noticed that the gnome-3-0 branch
> of e-d-s currently fails to build. The reason is a backport of a fix for
> bug #645783 [1] which relies on the sealing of CamelService done in
> master. I have at
Hello,
During today's round of jhbuilding I noticed that the gnome-3-0 branch
of e-d-s currently fails to build. The reason is a backport of a fix for
bug #645783 [1] which relies on the sealing of CamelService done in
master. I have attached a (hopefully correct) patch which fixes the problem
On Tue, 2011-04-19 at 18:37 +0200, Milan Crha wrote:
> Hmm, I think I understand, but I do not see clearly the point. Sometimes
> you do not know if the server requires the authentication, only after
> open, which will deliver (on idle) the "auth-required" signal, which can
> come before the backe
There's a really interesting thread over on desktop-devel-list. David
Zeuthen is taking on the task of desktop-wide online account management
for GNOME 3.2, with E-D-S integration among other things.
What he's describing sounds like the missing piece in my account
management redesign for dealing
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote:
> 1) There's no need for apps to use numeric IDs to track asynchronous
>operations; GCancellable fills that role. GCancellable is the app's
>handle to the ongoing operation. If the app wants to cancel an
>unfinished operation, i
On Tue, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
> No, not at all, EClient calls descendant's get_capabilities_sync on its
> own, when it's needed. The public get_capabilities API on descendants is
> sort of redundant in this case.
It that case we should have:
void e_client_get_capabilit
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
> I would like you to a incorporate some change to the free/busy api.
> Some servers allow querying free/busy information
> for multiple users at a time and the results appear in a iterative
> fashion. The freebusy information of some
>
On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
> I just created a new branch 'eclient' in eds [1] where is added my work
> on the new API which will deprecate EBook/ECal. It is following glib/gio
> async pattern and, I believe, makes things more coherent.
There's a few other weightier issue
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes wrote:
> On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
>> I just created a new branch 'eclient' in eds [1] where is added my work
>> on the new API which will deprecate EBook/ECal. It is following glib/gio
>> async pattern and, I believe, mak
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
> Havoc Pennington kept having to answer this same type of thing in the
> early days of GLib/GTK+ when people would ask why the API never uses
> "const" in functions that take but don't modify a GObject and GLib data
> structure.
>
> http://
On Tue, 2011-04-19 at 07:58 +0200, Milan Crha wrote:
> > * In EBookClient, drop the 'const' qualifier from EContact arguments.
> > Trying to use 'const' with GObjects is misguided and pointless. I've
> > cursed at EIterator many times for this.
>
> Yet another thing I wanted to address was a
Hi,
The meeting goes as follows,
* Project updates
* Discussion on queries/decisions
* Individual updates
Check out http://live.gnome.org/Evolution/CommunityMeet for more details.
- Chenthill.
___
evolution-hackers mailing list
evolution-hackers@gnome
15 matches
Mail list logo
