On Sun, 2012-04-29 at 19:50 -0400, Matthew Barnes wrote:
It's been awhile since I've posted a progress update on this branch, but
I just wanted to mention that as of this weekend I think I finally have
Evolution pretty much wrapped up now and am moving on to the groupware
modules starting with
It's been awhile since I've posted a progress update on this branch, but
I just wanted to mention that as of this weekend I think I finally have
Evolution pretty much wrapped up now and am moving on to the groupware
modules starting with Evolution-EWS, since I'm also on the hook for
integrating
I added a page to our wiki about the upcoming file format for account
data. It focuses more on the nuts and bolts of the file format itself
rather than the APIs used to access the data. In particular, I wanted
to get the mail account format written down somewhere since it's a bit
more complex
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes mbar...@redhat.com wrote:
I added a page to our wiki about the upcoming file format for account
data. It focuses more on the nuts and bolts of the file format itself
rather than the APIs used to access the data. In particular, I wanted
to get
Hi,
Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes:
[...]
Now I'll let you in on my master plan:
Either in the 3.2 or 3.4 time frame, after the branch is merged and has
some time to settle in and stabilize, I want to move these configuration
dialogs to
On Wed, 2011-09-14 at 11:27 +0200, Christian Hilberg wrote:
Doing his will finally make it possible to configure address books and
calendars for E-D-S independently of Evolution. With that in place, we
can start adding some nice desktop integration.
Has there already been a
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 Wed, 2011-03-30 at 07:49 +0200, Milan Crha wrote:
should it delete them too? I've a feeling there is no need for it,
especially when you want to have them as three separate independent
objects. But that's just a feeling.
As long as Evolution treats account/identity/transport triplets as a
In last week's IRC meeting I promised more details about the file format
I'm designing for mail accounts.
I like the way Thunderbird splits accounts, identities and transports
into orthogonal concepts. Each account has a default identity and
transport, but then you can go back and define
On Tue, 2011-03-29 at 09:26 -0400, Matthew Barnes wrote:
The hierarchy just ensures that deleting the mail account from the
ESource registry will also take out the default identity and transport
for that account.
Hi,
should it delete them too? I've a feeling there is no need for it,
On Tue, 2011-03-01 at 23:02 -0500, Matthew Barnes wrote:
My next steps are to write the migration code for all the XML blobs in
our sources GConf keys, and then it's on to mail accounts.
I rebased the account-mgmt branches [1] again to snapshot my progress.
Address book and calendar migration
On Do, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
libebook
- Remove e_book_new_from_uri() and e_book_get_uri().
- Remove e_book_get_addressbooks().
libecal
---
- Remove e_cal_new_from_uri() and e_cal_get_uri().
- Remove e_cal_get_sources().
I must admit that I
On Wed, 2011-01-26 at 16:23 +0100, Patrick Ohly wrote:
SyncEvolution uses all of these calls. I don't mind rewriting the code,
but let's make sure that there is a proper replacement.
What I need to do is:
- list all address books and calendars
- open any of the listed databases
- create
On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
I kinda wanted to tweak the names anyway, so here's my proposal for the
new D-Bus interface names:
Old: org.gnome.evolution.dataserver.addressbook.BookFactory
org.gnome.evolution.dataserver.calendar.CalFactory
On Tue, 2011-01-25 at 16:54 -0500, Matthew Barnes wrote:
The new names are (with both versions at '0'):
Bus Name:org.gnome.evolution.dataserver.AddressBook0
Object Path: org/gnome/evolution/dataserver/AddressBookFactory
Interface:
On Wed, 2011-01-26 at 06:17 +0100, Milan Crha wrote:
thanks for doing this. I'm only wondering, why not a dot or dash (if
available for bus names) between the version number and the bus name
itself? Was there anything preventing it to do it that way? (I'm not
much familiar with DBus itself, so
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote:
Now I'll let you in on my master plan:
Nice work Matt.
--
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
signature.asc
Description: This is a digitally signed message part
Another status update:
After much consideration I decided to drop GSettings from the equation
and just access key files directly. The key file part of the design is
working out well but I've been fighting with GSettings every step of the
way. It's not that that GSettings is bad, but it's very
On Mon, 2010-12-20 at 14:17 -0500, Matthew Barnes wrote:
Since removing an address book or calendar source will be as simple as
deleting its key file, in theory the backend process should be
notified of the file deletion event by its ESourceRegistry and can
then clean up after itself on its
On Tue, 2010-12-21 at 10:14 +0100, Milan Crha wrote:
I like your idea. It might work as long as the backend is running,
otherwise it will not, unless you'll add a listener for this in factory
and run the backend if needed.
I actually got it working last night for address books, although it
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
Overall the changes are having a simplifying effect on the code base,
but it will introduce an API break of some kind to almost every library
in E-D-S. That's what I wanted to talk about here.
Couple more API breaks to mention which
(I'm leaning away from having URI keys, favoring instead URI components
as separate keys from which a complete URI string can be formed.)
As someone who's used ESource in the past .. I always found the old
way of doing it oh-so-confusing. I even added the following code to
dates:
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
Signals:void(*load_error) (ESourceRegistry *registry,
GFile *file,
GQuark error_domain,
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
As usual this is turning out to be a bigger job than expected, and I'm
less confident now that I can get this all done by 2.91.90 but I'm still
gonna try. The alternative, since I -really- don't want these XML blobs
creeping into
On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
It would be good to allow also username changing in EPasswords. It's
very unusual to allow only password entering when most applications are
allowing to change both username and password (I'm not aware of any
other with enter password only
Here's a progress update on my account management rewrite.
I've been on travel for the past three weeks and still have another week
to go, so I've only been able to work on this in short spurts -- an hour
here, an hour there. But I've managed to work through all of E-D-S, get
the
Let's talk D-Bus.
I've started integrating the redesigned, key-file based ESource APIs in
a branch of Evolution-Data-Server and so far it's actually simplifying
the affected code. I'm leaving mail aside for now and just focusing on
calendars and address books.
I'm gonna have to remove some
Hi,
On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
I was a bit horrified to realize over the weekend the way we select a
backend from the factory processes when requesting a new EBook or ECal.
We convert an ESource object to XML and transmit the -entire- XML string
over
On Wed, 2010-11-10 at 16:20 -0500, Matthew Barnes wrote:
On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote:
Does this mean (for example) that we will be able to have a caldav
server, with credentials, and then just associate (and maybe
auto-discover) all of the user's addressbooks,
On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote:
Does this mean (for example) that we will be able to have a caldav
server, with credentials, and then just associate (and maybe
auto-discover) all of the user's addressbooks, calendars, todo-lists and
journals which the user has on that
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
Here's a few built-in top-level stub sources as trivial examples. They
don't do anything other than name a backend. They would appear as bold
group names in a source selector widget.
1. Filename/UID: on-this-computer
31 matches
Mail list logo
