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 w
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 EWS
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes 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 the mail account
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 tha
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 manif
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 Evolution-Data-
I just pushed a new snapshot of my "account-mgmt" branch for Evolution
and Evolution-Data-Server.
http://git.gnome.org/browse/evolution/log/?h=account-mgmt
http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt
This is mostly for backup -- I haven't yet reached any particularly
si
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
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,
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 addition
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 migr
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote:
> I think I'm done now with the standalone address book backends and am
> moving on to calendars, so it seemed like a good stopping point for a
> status update.
>
> I pushed snapshot branches named "account-mgmt" to git.gnome.org. Try
> the
On Thu, 2011-01-27 at 08:15 +0100, Patrick Ohly wrote:
> On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote:
> > Can you elaborate on the creation use case? Sounds like you're creating
> > local data sources on the fly?
>
> Yes. The primary use case is in automated testing. Instead of having
On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote:
> Can you elaborate on the creation use case? Sounds like you're creating
> local data sources on the fly?
Yes. The primary use case is in automated testing. Instead of having to
create the database in advance via the GUI, the test driver do
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
> - cre
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
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,
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: org.gnome.evolution.dataserver.Addressbook
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
>org
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 mu
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 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 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 t
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
> > Signals:void(*load_error) (ESourceRegistry *registry,
> > GFile *file,
> > GQuark error_domain,
> >
>
> (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 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 on
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 GSe
More brain dumping so this is all out in the open.
Since I've been blathering on about this new ESource API and these
"extension" things but haven't actually posted the API, I thought I
should do so.
Also attached are my notes for the GSettings schemas for these various
ESourceExtension subclasse
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 test-source-comb
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 D
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 funct
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 addressbo
On Thu, 2010-11-11 at 08:55 +0100, Milan Crha wrote:
> Will be there any kind of property inheritance? As in your example
> above, I would like to define the 'color' in the [source]
> key-file-group, thus all extensions will inherit it, but, if user
> changes color for one of them, then it'll creat
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"
>
>
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
> As part of our transition from GConf to GSettings, which Rodrigo Moya
> has graciously been helping with, I've put some thought into addressing
> the XML string lists which we currently store in GConf under "accounts"
> and "sources" keys.
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 t
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
>
> Backends can also define their own groups and schemas for storing
> settings that are specific to that backend. Here's an off-the-cuff
> example of what a source describing a CalDAV calendar might look like:
>
> [source]
39 matches
Mail list logo