I'm at the point now with the account-mgmt branch where I have to deal
with the settings that trickle down into the various Camel providers.
The way the settings are managed now is to embed them into the Camel
service's URL string as a list of named parameters. This is suboptimal
for the same
On Thu, 2011-06-09 at 18:40 +0200, Milan Crha wrote:
By the way, thinking of your announcement, I hope you are fine if I'll
finish this stop using deprecated Book/Cal API in evo as soon as
possible and commit it, thus it'll have more testing (I'm pretty sure
I'll introduce few regressions and
On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote:
Thanks, I'll do that. Just the first transition will be about not using
deprecated API, the second part of it, making calls async, is a very
different task, as I go through calendar sources and see all the sync
calls and the API being served
/evolution/addressbook/${ESOURCE_UID}
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote:
Maybe it can pump them, but it doesn't deliver them, as far as my tests
showed, because they are usually delivered on idle, which never happen
with blocked main loop. That's the reason why I added there this loop.
Only notice that this loop
On Fri, 2011-05-20 at 16:13 +0100, David Woodhouse wrote:
I have lost count of the number of times I've been trying to debug
something in e-calendar-factory, but the factory I'm running in gdb is
*not* the one that's actually being used.
Sometimes I forget to kill the old factory. Sometimes
On Fri, 2011-05-13 at 12:48 +0100, Ross Burton wrote:
On 12 May 2011 11:44, Patrick Ohly patrick.o...@gmx.de wrote:
It'll lead to a change of the D-Bus API. For master that shouldn't be
a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
guess we have to bite the bullet
On Mon, 2011-05-09 at 17:49 +0200, Milan Crha wrote:
It's just because of (so called) consistency. With merging common error
codes into E_CLIENT_ERROR_ namespace I realized that checking for
particular errors will not be that easy as is now, because one might
have two switches, one for domain
I made some changes to Camel and Evolution in time for 3.1.1.
I realize it's a bit last minute but I wanted to pack all the changes
into one soname bump for libcamel. This is a strategic move to solve
some issues on the account-mgmt branch, but it also simplifies a good
deal of code in
On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote:
There was just a little problem with ECalView, which had 'client'
property, which is referring to ECal, instead of ECalClient, and I was
forced to invent different name for it. But after a bit of sleeping
and small thinking I might be wrong
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest that
besides modernizing the API we also take this opportunity to move more
of EBook/ECal into a common core.
Opening and listing databases don't have to be separate. Turn
On Thu, 2011-04-28 at 13:12 +0100, David Woodhouse wrote:
As I understand it, an soname bump (from libfoo.so.5 to libfoo.so.6)
should *only* be used for backwards-incompatible changes.
Correct. One such example of a backwards-incompatible change is
increasing the size of a public GObject
On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
You obviously face of a circular dependency, so it's not doable in a
clean way. Also because EClient is in libedataserver, EBookClient in
addressbook/libebook and similarly ECalClient in calendar/libecal. Both
descendants link to
On Thu, 2011-04-28 at 18:11 +0200, Milan Crha wrote:
Yes, when I was changing server side data-views for book and cal, then
if turned out that the D-Bus API is exactly the same except of the
DBUS_PROXY_NAME and book/cal strings in a file.
Thus having type param for both factories too,
On Thu, 2011-04-28 at 14:49 +0200, Patrick Ohly wrote:
Please, let's avoid E_CLIENT_TYPE_CALENDAR. For people less familiar
with Evolution terminology it is not clear whether this includes tasks.
In Evolution, it doesn't, but in other contexts it does. For example,
Nokia phones store events
On Thu, 2011-04-28 at 21:16 +0200, Patrick Ohly wrote:
Agreed, the library dependency issue is a problem. That could be solved
by an utility library on top of libecal and libebook which offers the
unified API.
Or you could just write your own function in EvolutionSync. It's just a
switch
After playing around with CamelSession earlier this week, the whole
CamelSessionThreadMsg API finally annoyed me enough to replace it with
something more modern.
The new API is a lot cleaner, I think, and uses the same mechanisms that
the asynchronous functions use. Low-priority background jobs
On Fri, 2011-04-22 at 19:03 +0200, Milan Crha wrote:
Yup, though it'll be (internally - aka in D-Bus) still a signal. This
request of ECredentials object seems strange to me, because I understand
the ECredentials as something which actually holds credentials, not
something what is asking for
On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote:
void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient
*client, ECredentials *credentials, gpointer user_data), gpointer
user_data);
gboolean e_client_open_new_finish (GAsyncResult *result, EClient
**client, GError
On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote:
It's technically not passed in this function, it's a callback
signature. :) It would be used as a signal handler for auth-required
signal in the function, as I think of it right now.
Yeah I'd like to kill the auth-required signal too as I've
To help smooth the way for the account-mgmt I've made a few improvements
to the CamelSession and CamelService APIs in 3.1. It's not necessarily
the *final* APIs that will wind up in 3.2, but more like the first round
of changes leading up to 3.2.
* Every CamelService instance now has a unique ID
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 clear
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 issues
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
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 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 backend
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 password
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.
Thanks for posting this, Milan. I
On Thu, 2011-04-07 at 10:47 +0200, Patrick Ohly wrote:
The sequence of events is this:
1. e_cal_new_system_calendar()
2. e_cal_new_from_uri(local:system, ...
3. get source list
4. search_known_sources() by comparing e_source_peek_absolute_uri()
against
On Tue, 2011-04-05 at 16:31 +0530, Chenthill Palanisamy wrote:
This would certainly help distributions which want to stay with
Evolution 2.32 for a while.. My only concern here is, while
cherry-picking patches how would we take care of the translations and
documentation ? Are we adhering to
On Fri, 2011-04-01 at 18:00 +0100, David Woodhouse wrote:
I hope that eventually, we might be permitted to use the real
gnome-2-32 branch in GNOME git for this, rather than having to do it
elsewhere. If that branch is a dead end and would otherwise be unused,
then there's no harm in letting
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote:
Although presumably there will be 3.01 and 3.02 releases so those
branches aren't *quite* as orphaned as 2.32 yet :)
Yeah, 3.0.1 at least per the GNOME schedule, although we've been doing
at least one additional stable update ever since
On Fri, 2011-04-01 at 23:46 +0100, David Woodhouse wrote:
Thus the patch below. Anyone got a better suggestion for how to handle
it? A patch to actually use this facility in the NTLM authenticator will
follow, of course...
One alternative approach might be to to stop letting the
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
]
Enabled=true
Identity=bbb# Refers to the default Mail Identity (uid: bbb)
[IMAP+ Backend]
...backend-specific options go here...
Mail Identity (uid: bbb)
[Data Source]
DisplayName=Matthew Barnes mbar...@redhat.com
BackendName=
Parent=aaa
[Mail Identity]
Name
On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote:
How much of a problem is that in practice?
It's getting to be a problem. Seemingly innocent changes to header
files break builds in unexpected ways. Here's a common scenario:
- Header file foo.h includes bar.h.
- A client program
On Wed, 2011-03-23 at 15:52 +0100, Patrick Ohly wrote:
I thought that this break would go into 3.0 (see my initial reply). So
if 3.1 requires changes anyway, then sure, go ahead and break it some
more ;-)
Oh, I missed that in your first reply. Sorry.
That was the plan originally, but
On Fri, 2011-03-18 at 13:10 -0400, Matthew Barnes wrote:
Would anyone object if I collect it all together under a top-level
tests directory? (After we branch next week, of course.) This would
include the automated unit tests for libebook and libecal as well as the
standalone widget demos
On Mon, 2011-03-21 at 15:50 +0100, Patrick Ohly wrote:
If you see some increased interest in EDS soon, then it might be because
MeeGo is currently investigating how to use EDS as the main PIM and
email system again.
Attached a rough outline of the current ideas. My expectation is that we
On Sun, 2011-03-20 at 13:37 +, David Woodhouse wrote:
This means new strings, which it's already late for, and it means code
changes, which it's damn close for since I haven't actually written them
yet. But still I suspect it's a good idea to get these into 3.0 since we
really want to be
Now that I've started writing unit tests for libedataserver, it occurs
to me that we have test code scattered all over the place in git.
Would anyone object if I collect it all together under a top-level
tests directory? (After we branch next week, of course.) This would
include the automated
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
It's getting to be branching time again. I think in the past we've
usually branched when the hard code freeze starts, which would be next
Monday. Shall we go with that again or does anyone have a desire to
branch sooner?
(Speaking for myself, I don't really have anything ready to land yet.)
On Sun, 2011-03-13 at 21:32 +, David Woodhouse wrote:
Ug, and now I've found that that workaround doesn't work either. If we
try to rename a folder, we end up blocking in the main thread, waiting
for the soup request that we deliberately put into an idle function so
that it could run in
On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote:
do not forget that the DB cache is compiled conditionally, because some
distros do not ship libdb. Using SQLite for this was mentioned months
ago, only no-one got time to actually do it, so go for it.
Also, as far as I know there is still
Long ago and cubicle far, far away I wrote this little debugging
enhancement for GObject that collects statistics about instance
creation, destruction, etc. by class type and then prints a nicely
formatted report when piped through a tool named 'gobject-stats'.
My proposal for it got kinda
On Fri, 2011-03-04 at 11:40 +, David Woodhouse wrote:
I'm working on Enterprise use of Evolution, and one of the big
requirements is encryption of data at rest. The answer just encrypt the
whole of the user's home directory only puts them off for so long.
Can you go into more detail about
On Fri, 2011-03-04 at 12:25 +, David Woodhouse wrote:
On Fri, 2011-03-04 at 07:17 -0500, Matthew Barnes wrote:
Perhaps it's a different story for mobile devices?
To a large extent, yes. The 'encrypt it all' solution means that you are
forced to unlock the device to do *anything
On Wed, 2011-03-02 at 15:19 +0100, Milan Crha wrote:
Not enough, because the above. I'm doing this [1] (2.91.91+). Search for
e_attachment_store_remove_all() calls (the patch fixes also placing of
attachments to the correct bar).
That works, I guess. In other places were I build a hash table
On Wed, 2011-03-02 at 09:36 -0500, Matthew Barnes wrote:
You might use something less aggressive, like iterator or path, for
local indexes.
Won't work in the general case. As soon as you insert or delete a row
prior to the row you're tracking, GtkTreeIter and GtkTreePath are both
invalid
On Sun, 2011-02-20 at 20:49 +0100, David Klasinc wrote:
I am working on Gwibber - microblogging client and one of the ideas that
has come up is using EDS for storing Gwibber contacts. I looked into
evolution-python bindings and it seems that I can pull this off.
However, I have two problems.
On Thu, 2011-02-17 at 18:37 +, David Woodhouse wrote:
I assume that your intention is that the Camel async methods would *not*
be similarly broken, and that you should be able to call them from *any*
thread and expect them not to break?
If so, we need be *very* careful about calling into
be a base_uri attribute with a URI
scheme of either file: or local:. Delete all the On This Computer
entries with a base_uri=file://... attribute.
Hope this helps,
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change
On Mon, 2011-02-14 at 21:18 +0530, vikas ruhil wrote:
can tell in more detail about Meeting ?
i want to participate in meeting ?
so please tell ?
See: http://projects.gnome.org/evolution/meetings.shtml
We should add some boilerplate text to these meeting announcements that
includes the
On Tue, 2011-02-08 at 14:23 +0100, Onyeibo Oku wrote:
The Help-About on my Evolution mail menu still reads 'Evolution 2.32.1'
but I see Development is now at 3.x. Is there anyway I can experience
the future Evolution Mail Client while you guys do your thing? Is the
risk of test-running still
On Mon, 2011-02-07 at 09:50 +0100, Milan Crha wrote:
And that's what is wrong with it. I do not know the polling interval,
chosen by gio developers, but I prefer to be able to set the polling
time myself, for fine-tuning. Not talking about unnecessary network
traffic for those (rather rare?)
When creating a new local calendar or memo list or task list there's an
option for choosing your own iCalendar file and among _those_ settings
are choices for how and when to check the file for changes: On open,
On file change and Periodically.
On open is implied with all choices -- obviously we
On Thu, 2011-02-03 at 12:43 -0500, Reid Thompson wrote:
Is there a way to determine where I'm mixing GTK 2 3?
I'm not aware of a good way. In the past I've had to pick through
pkgconfig files to figure out what's dragging it in, but it's slow and
painful.
Evolution, Evolution-Data-Server and
yet. I set the requirement to a bogus value to force
the use of --disable-image-inline when building Evolution against gtk3.
Now that we _require_ gtk3, I need to figure out what to do about this.
For now use --disable-image-inline.
Matthew Barnes
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
As of today, we have dropped support for gtk+-2.0. Evolution and all
related modules now require gtk+-3.0.
Until the GTK+ team releases version 3.0, I'm going to keep our gtk+-3.0
requirement set to the latest tarball release -- currently 2.99.2 -- to
ensure we're all keeping up with the latest
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 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 Mon, 2011-01-24 at 08:50 +0100, Milan Crha wrote:
what about wait till Wednesday, after evolution team meeting, and then
merge gtk3 branches to master branches, and require gtk3 for the Monday
2.91.6 release? It saves a bit of work for you, and also forces people
to fix new issues related
On Tue, 2010-11-23 at 23:50 -0500, Matthew Barnes wrote:
Migration issues aside, since that's already a project unto itself, is
there any reason why our keyring items can't be as simple as:
Description: Evolution data source source-uid
Attributes: source: source-uid
This would make
On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote:
Nope, go for it. It may also fix an issue with BirthdayAnniversaries
calendar, when using authenticated addressbook, as right now there is no
easy way to ask for a stored password for that book. Of course, there
will be needed new API for
On Thu, 2011-01-20 at 18:55 +0100, Christian Hilberg wrote:
++ from the evolution-kolab team. Any idea on how to handle exactly this
right
now (we'll be implementing that soon on a totally obsolete Evo version, i.e.
2.30 ;-)? Since we did not yet implement this part, we can do so in a way
On Sun, 2011-01-09 at 15:13 -0500, Matthew Barnes wrote:
If no one objects I'll plan to do this later this week. So speak up now
or commit now if you have any pending changes. I'll make sure any last
minute commits aren't lost.
The gtk3 branches are rebased now. Delete your local copy
speak up now
or commit now if you have any pending changes. I'll make sure any last
minute commits aren't lost.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http
On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote:
The cleanest and most obvious solution is to install the backends into
separate address book and calendar directories, then have each factory
process load from the appropriate directory.
This will require a few API changes
On Wed, 2011-01-05 at 13:17 +0100, Milan Crha wrote:
are you sure they are kept in memory? I see the factory calls
Yes, GTypes are registered permanently whether the class is loaded
statically or dynamically. This isn't about class instances.
Do you mean you are returning from the backend
correctly
point to them.
If there's no objections I'd like to get this fixed in 2.91 even though
it's not currently causing any problems in 2.91, but just to get it out
of the way. I'll take care of updating the Exchange modules as well.
Matthew Barnes
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 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
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
Signals:void(*load_error) (ESourceRegistry *registry,
GFile *file,
GQuark error_domain,
On Tue, 2010-12-14 at 04:47 -0700, Vibha Yadav wrote:
Evolution is now compilable against gtk3. Please checkout the gtk3 branch for
+ gtkhtml
+ evolution-data-server
+ evolution
Awesome! Nice work!
Let's hope that's the last of the API breaks.
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
On Tue, 2010-12-07 at 21:50 +0100, Stefano Facchini wrote:
I didn't mean that I wanted to file bugs about compilation, but about
the window showing the list of emails. Instead of showing the list, it
shows whatever occupied that region of the screen before switching to
Evolution mail: for
On Tue, 2010-12-07 at 22:09 +0100, Stefano Facchini wrote:
Il giorno mar, 07/12/2010 alle 15.02 -0600, Matthew Barnes ha scritto:
Are you aware of this?
Yes, it turned out to be a GTK+ bug. It was fixed last month.
So to fix it I'd need to update GTK+2, not evolution?
Correct
On Tue, 2010-11-23 at 23:50 -0500, Matthew Barnes wrote:
Also, while we're on the subject of password storage, pretty please can
we drop support for the old legacy ~/.gnome2_private/Evolution password
file and make keyring integration mandatory for Evolution 3.0? We are
the only ones still
On Thu, 2010-12-02 at 15:25 +0100, Milan Crha wrote:
I would use the last version in the migration code check, and if any fix
in the migration routine would be done after another release, then just
increase the number in the version check. It might work as long as the
changes will be done
/archives/evolution-hackers/2010-March/msg00023.html
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mon, 2010-11-22 at 16:17 -0500, Matthew Barnes wrote:
I'll ponder on this some more. I don't want to get too far off on a
security tangent right now since this key file proposal is already a
tangent from migrating to GSettings. But it's good to discuss now so I
can come back to it later
I finished my first pass at converting all the address book and calendar
backends to the new key file API and am now looking at our GNOME Keyring
integration.
Once again I'm getting bit by the fact that the URIs we've historically
used to identify data sources is just making things needlessly
I have a stupid question.
I've been converting the various address book and calendar backends to
my key-file based ESource proposal, and in several configuration dialogs
such as LDAP address books and GroupWise calendars, I see this setting
with choices in a combo box:
Use secure connection:
On Mon, 2010-11-22 at 19:48 +0100, Yves-Alexis Perez wrote:
As I understood it, SSL meant a tunneled connection over SSL/TLS, using
the relevant port (995/pops, 993/imaps, 465/smtps, 636/ldaps). TLS means
STARTTLS over a normal connection, so usually using the standard port
(110/143/25/389).
On Mon, 2010-11-22 at 21:47 +0100, Yves-Alexis Perez wrote:
Simplifying the settings is a good idea, but pretty please, no wizard à
la thunderbird, it's *horrible*, everytime I need to use it I want to
die.
Don't worry, I'm not writing any new wizards. This should be as
transparent and
On Mon, 2010-11-15 at 08:49 -0500, Reid Thompson wrote:
my latest build attempt with glib, gtk+, evo-* all at git head appears
to fail due to some api changes.
Could someone post me the (highest?) tag/branch levels of glib, gtk+
that will allow me to build evo-* git head?
The master branch
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
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. We've known for years that this is a really bad
approach, and I
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 Tue, 2010-10-26 at 15:43 +0200, Rodrigo Moya wrote:
I was wondering if someone has started working on the migration to
GSettings, so that I could lend a hand, so anyone?
Yes, I have. Though so far I've only been nipping around the edges and
making preparations.
This is going to be larger
On Fri, 2010-10-22 at 09:32 -0400, Matthew Barnes wrote:
Anyway, I already owe other people some code reviews so I'll put away my
hackers hat for a few days and try to look at this over the weekend. It
may need to sit on a branch for a little while longer because I don't
want Evolution
On Fri, 2010-10-22 at 15:01 +0200, Benjamin Otte wrote:
I've pushed a rendering-cleanup branch to git that cleans up evo code
to compile with GDK_DISABLE_DEPRECTAED again. As I'm fortunately not a
specialist on Evo code, someone should look it over, but from my
testing, things still look fine.
On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote:
I'm trying to unwind some code in Camel and in Evolution.
The problem I have is that if you change an email account's extra
options (e.g. imapx's apply filters to new messages), then those
changes don't take effect until you
On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
The other solution was to maintain all exchange providers in a single
package, merging evolution-exchange, evolution-ews and evolution-mapi
into a single package. Other collaboration providers like
evolution-groupwise and evolution-kolab (yet to
On Sat, 2010-10-16 at 11:49 -0400, Martin Owens wrote:
* Cached Camel provider data moves to ~/.cache/evolution/mail. This
includes folders.db. Files for local accounts will be divided up:
index files for searching would go in ~/.cache, whereas actual mail
content
On Mon, 2010-10-04 at 17:33 +0200, Javier Jardón wrote:
The patch attached should fix the problem
Thanks for this. Applied to master branch of evolution-data-server and
evolution. Our other modules are still using GLib's gettext, so I guess
they'll need to be fixed similarly when we switch
201 - 300 of 465 matches
Mail list logo
