crop up you can show that distributors
still shipping an unsupported Evolution release have been informed.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https
Hi Christian,
I've been having the same build issue on Debian.
Revert this commit and you should be able to build again:
https://git.gnome.org/browse/evolution-data-server/commit/?id=a2790163af4d3f375a778055d0e2699207dfd050
Matthew Barnes
- Original Message -
Hi,
I don't know why
- Forwarded Message -
From: schaarsc schaa...@gmx.de
To: Matthew Barnes mbar...@redhat.com
Sent: Friday, September 26, 2014 10:11:45 AM
Subject: Re: [Evolution-hackers] e-d-s build problems
Hi Matthew,
thank you!
reverting
Revert this commit and you should be able to build again
On Mon, 2014-06-09 at 16:57 +0200, Tomas Popela wrote:
Hi,
the WebKit based composer was commited into master with [0].
Awesome! Congrats on landing that - that's a pretty major feature and
I'll start testing it immediately. Also I have to say I'm thrilled to
finally see GtkHTML die for
On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote:
Aren't you going to run into the same problem with a GObject-based
proxies for these libical objects? The proxies are reference-counted,
the libical objects are not, so they may go away before their proxies
do. This would leave the proxy
certificate is really the only way to ensure previous messages are not
altered.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution
On Mon, 2014-03-17 at 20:05 +0100, Patrick Ohly wrote:
While I have no say in how Evolution gets developed, I nonetheless would
like to warn against merging unstable and known buggy code into master.
What if it turns out that the code can't be stabilized in time for the
next release? Can it be
on your distro. Just copy the script to your
$HOME/.local/bin, and do git-new-workdir --help to see how it works.
That's my bag of tricks.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
On Mon, 2014-03-03 at 15:51 -0500, Matthew Barnes wrote:
Been thinking about our release schedule after 3.12.0, when we break
with GNOME and embark on our own annual development/support cycle.
I'd like to release updates at a more predictable cadence than GNOME.
With the GNOME 3.12.0
On Thu, 2014-03-06 at 17:06 +0100, Milan Crha wrote:
Right, that's the only being active currently from my point of view too
(and according to commit log). Should I figure out the right git command
and just get rid of those in eds/evo/ews/ema?
Yeah, have at it.
I think the commands you need
On Thu, 2014-03-06 at 11:40 -0500, Paul Smith wrote:
If you have a new-ish git you can use the --delete flag instead of the
colon (exactly the same result, but more readable):
git push --delete origin branch-name
Thanks for the tip, that's much easier to remember.
Matt
Late last week I finally got the IMAPX backend fully ported to use GLib
streams directly.
I debated whether to push the commits for 3.12, being that it's kinda
late in the cycle, but I've been running the code for several days and
it seems alright. It's in master now, so keep an eye on IMAP this
double as an are you sure? check to help avoid accidents.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
.
No interest in this, as it would only compound our workload. SQLite is
the chosen tool for the job. But you're free to fork Camel if you like.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
On Mon, 2014-01-27 at 17:03 +0100, Fabiano Fidêncio wrote:
I'd like to see a student working on Evolution family on this year
GSoC (if GNOME is accept as an org, of course). So, I'm starting this
thread to keep track/discuss possible ideas and, as soon as we have
settled on them, move to
and jhbuild doesn't
automatically clean up after itself.
Just uninstall the old E-D-S and rebuild.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org
Here's my list.
There's a few items on the wiki page I've been dragging along for a few
releases now. Those are still on my agenda, even the importer rewrite.
https://wiki.gnome.org/Apps/Evolution/Planning310
Additionally I want to really focus on getting Camel's API fixed up well
enough to
better to submit patches to our bug tracking
system [1] so we can... well, track them easier.
Matthew Barnes
[1] http://bugzilla.gnome.org
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit
On Thu, 2014-01-02 at 11:30 +0100, Patrick Ohly wrote:
I just noticed that libecal bumped its soname to libecal-1.2.so.16 in
EDS 3.10. The corresponding commit is:
commit f30ae26320b359666b345c92405bf87f3f43250a
Author: Matthew Barnes mbar...@redhat.com
Date: Tue Jul 16 06:34:02 2013
regularly were the tarball download links,
which are now on the front wiki page:
https://wiki.gnome.org/Apps/Evolution#Get_the_Source_Code
I'll be mining the Evolution website for any remaining useful tidbits
that aren't already on the wiki, and attempting to set up forwarding.
Matthew Barnes
[1
appreciated.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
'
prefix, and silently omits anything it had trouble reading when saving
back to disk, thereby corrupting the file.
More often than not I have to manually audit the changes it makes with
git add -p before committing.
Matthew Barnes
___
evolution-hackers
monitor the standard output.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mon, 2013-11-04 at 15:18 +0900, Tristan Van Berkom wrote:
The goal is to transform the gtk-doc generated html
pages into something that actually looks like a
reference manual.
Before starting on this long and tedious task of going
through the symbols one by one and checking them off a
is not very well documented. I gleaned the example
above from Evolution code. I can try to elaborate further if needed.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https
On Mon, 2013-10-21 at 18:27 +0200, Tristan Van Berkom wrote:
The maintenance in question is pretty simple, every
stable release (directly after branching for the next
stable release would be the ideal time) a new case
needs to be added to the addressbook migration test.
I really appreciate
On Mon, 2013-10-14 at 09:48 +0530, samarjit Adhikari wrote:
Where did you release 3.10?
Evolution 3.10 was released at the same time as GNOME 3.10, available at
the usual place (download.gnome.org/sources).
I've just been lazy about updating the website lately.
Matthew Barnes
I just released 3.10.1 and still haven't seen an official release
schedule from GNOME, so I penciled one in for us based on the 3.7
schedule from last year.
https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO#Release_Schedule
According to this schedule, the first 3.11 release is due next Monday
On Thu, 2013-10-10 at 11:24 +0200, Fabiano Fidencio wrote:
Please, take a look into:
http://blog.fidencio.org/2013/10/evolution-ews-testing-eewsconnections.html
Nice work! More automated testing is definitely needed.
Maybe this could serve as a template for testing the other HTTP-based
.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
was thinking just a line item with a link to your blog post.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
The IMAPX classes were moved into Camel's public API to serve as base
classes for evolution-kolab. But since Christian has parted ways with
us it would appear the evolution-kolab project is no longer active.
I'm planning a good deal of API changes to IMAPX over the next few
months as I work
You may have noticed our wiki pages moved from wiki.gnome.org/Evolution
to wiki.gnome.org/Apps/Evolution.
This happened last Friday at Jon McCann's request. I agreed since he
added an automatic redirect from Evolution to Apps/Evolution.
What I didn't realize was most of our pages were using
together on IRC for about *six years* now!
I hope we can do this again some time.
Matthew Barnes
[1] https://mail.gnome.org/archives/evolution-list/2013-July/msg00162.html
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your
On Mon, 2013-07-29 at 01:26 +0200, Tobias Mueller wrote:
Hm. I'm wondering whether this is a problem for the rest of GNOME, too.
Do the arguments brought up in this thread apply to Evolution (and
friends) only? If no: Would the rest of GNOME also benefit from a
different release schedule? If
On Wed, 2013-07-24 at 07:21 -0400, Paul Smith wrote:
Not being familiar with Evo development I'm not sure how feasible it is,
but ideally part of the change in release cycle would mean divorce from
the Gnome version lockstep, and Evo being able to build against multiple
versions of Gnome. If
On Tue, 2013-07-23 at 10:10 -0400, Matthew Barnes wrote:
My feeling is just that at this point in the project's lifespan, our
users would be better served by a longer support window. They still
want to see improvements and new features, but more than anything I
think they just want stability
I've been kicking around this idea for awhile now, but haven't said
anything until now. I'm putting it out there as food for thought.
Increasingly I'm feeling like the traditional 6-month release cycle is
just too short for Evolution. In terms of development, we have a pretty
short window for
On Tue, 2013-07-09 at 08:34 +0530, Joe Steeve wrote:
So, I managed to build it. But, how to run it without screwing my local
configuration. The gnome from my distro (Debian Wheezy) is 3.4.
Easiest ways are to either run 3.9.x from a separate user account, or
install a virtual machine.
Matthew
Can you get a backtrace on that warning, please?
G_DEBUG=fatal_warnings gdb evolution
- Original Message -
From: Reid Thompson reid.thomp...@ateb.com
To: evolution-hackers@gnome.org
Sent: Monday, June 24, 2013 9:16:30 AM
Subject: [Evolution-hackers] (evolution:30823): GLib-WARNING
$ G_DEBUG=fatal_warnings gdb evolution /opt/evo/bin/evolution-src
(evolution:6219): Gtk-WARNING **: Failed to register client:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files
/opt/evo/bin/evolution-src: line 46:
on it. It will be merged into the master branch
once it's deemed feature-complete and stable.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution
On Thu, 2013-05-30 at 11:56 +0100, David Woodhouse wrote:
We had a local copy of the LZX decompression code, taken from libmspack
and then hacked up somewhat to support the variant that the EWS GAL
uses. I cleaned up that code and got it accepted into upstream
libmspack, and libmspack 0.4 has
.
No, the colon is part of the Maildir specification.
All the files must have the form: unique_name:2,flags
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https
.
Looks like something's wrong with your font configuration.
3.8.2 works fine here.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman
On Thu, 2013-04-18 at 11:25 -0400, Matthew Barnes wrote:
I think we just need to port the changes here to Evolution:
https://git.gnome.org/browse/evolution-data-server/commit/?id=fb9b02e43251b7f4004eb41791f0a3553eeb2b4c
I'll take care of it.
Should be fixed now for both master and gnome-3-8
On Wed, 2013-04-17 at 16:21 +, Reid Thompson wrote:
For the past few days my builds of evolution, and evolution-ews ahave
been failing with essentially the same error...
Try a clean rebuild.
I just did a successful make distcheck on Evolution.
Matthew Barnes
://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-data-server-util.c#n1368
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo
://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Thu, 2013-03-21 at 12:41 +0100, Milan Crha wrote:
This way we've a backward compatibility, only clients which would like
to be non-interactive will advertise it, others will work like before.
To be able to address the need to disable/enable interactive mode after
open, there might be
The master branches are now for 3.9 development. Have at it!
The gnome-3-8 branches are under a code freeze until the 3.8.0 release
on March 25.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
-direct.pc file into 3.8.0,
which is why I'm bringing this up now.
Any objections?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo
On Sat, 2013-03-09 at 22:57 +0200, Ebru Akagunduz wrote:
How can i fix it?
Install evolution-data-server from git first.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit
can work around it by registering the GType earlier.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
-address-book-N where 'N' is
the test case number or some other increasing integer.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman
On Sun, 2013-02-24 at 20:54 -0500, Matthew Barnes wrote:
We could try letting EBookClient create its own EDBusAddressBookFactory
proxy, call its OpenAddressBook method, and then immediately destroy it.
That would simplify the code, eliminate the global variable, and quite
possibly fix
On Thu, 2013-02-21 at 20:10 +0100, Milan Crha wrote:
Checking GNOME schedule, I propose Wednesday, March 6th, two days after
3.7.91 release. I'd pick the next week, but maybe there will be any
things fixed, especially if others would like to see anything in
particular being fixed in 3.6.4,
in Evolution was meant to be temporary. The long
term solution, which I simply haven't had time for yet, is to move all
that backend-specific configuration widgetry into E-D-S.
But I can make that a priority for 3.10 if we're already talking about
regressing back to arbitrary string tables.
Matthew
to the base ESourceExtension class.
Maybe I don't understand what problem this is trying to solve.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org
nowadays are ESources with a [Mail Signature] extension,
for example, and I'm also considering porting our filter rules and saved
searches to use ESource in a similar manner.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
. Sometimes that's the prudent thing to do.
Case in point:
My main focus now and going into 3.9 is finishing the WebKit composer.
It missed 3.8, unfortunately. Still too many unresolved regressions.
Matthew Barnes
___
evolution-hackers mailing list
evolution
On Wed, 2013-02-06 at 00:47 +0900, Tristan Van Berkom wrote:
We should consider adding capability identifiers for recent additions
such a ESourceRevisionGuards ESourceBackendSummarySetup.
Yes, I agree.
___
evolution-hackers mailing list
On Tue, 2013-02-05 at 17:02 +0100, Milan Crha wrote:
that sounds new to me, as I recall some exchange plugins did change
capabilities based on user preferences. As an example, one could setup
GAL browsable in preferences, in which case the capabilities property
had been populated with one more
.
With equivalent changes to the calendar factory, of course.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Thu, 2013-01-17 at 11:08 +0100, Milan Crha wrote:
I'm sorry, but I'm quite confused with the EServerSideSource's
remote-deletable and removable properties. They seem to me like they
should do the same, mark the ESource with a flag that it can be removed
by a user, but they are actually not.
On Tue, 2013-01-15 at 17:45 +0100, Paul Menzel wrote:
Did anybody ever run this with Evolution?
The code coverage option is for use with the E-D-S unit test suite, not
for running Evolution. The E-D-S tests currently cover about 2% of the
code, or something pathetic like that.
Matthew Barnes
On Mon, 2013-01-14 at 10:24 +0100, Milan Crha wrote:
I noticed some time ago that the code is full of redundant type casts,
but I do not understand what it is good for.
For better readability, in cases where the type definition also hints at
what the callback does.
. If I end up having to carry it the
rest of the way then it then it's at least a year out yet since I have
other priorities. This is a nice-to-have, not a must-have feature.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
is an optional dependency.
On GNOME 3.4 you'll have to pass --disable-weather to configure.
More details here:
https://bugzilla.gnome.org/show_bug.cgi?id=672805
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list
]
if (e_account_list_find (accounts, E_ACCOUNT_ID_ADDRESS, id))
{
~~~^~~~
1 warning generated.
You're on your own to patch that.
EAccount and EAccountList classes are gone in 3.6 and later.
Matthew Barnes
require a strategy? :)
I'm in kind of a wait-and-see mode with Evolution's GNOME affiliation
given the direction GNOME 3 is going, which has not been to my liking.
But afaik Evolution is still welcome on gnome.org. So I'm content to
sit tight for now.
Matthew Barnes
itself with:
e_dbus_server_quit (server, E_DBUS_SERVER_EXIT_RELOAD)
instead of depending on the client to tell it to.
Does that sound like an improvement over the way it works now?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers
On Sat, 2012-12-15 at 13:32 -0500, Matthew Barnes wrote:
I'm debating whether or not to support the imap-features Evolution
plugin in IMAPX or just throw out the plugin at the same time we throw
out the legacy IMAP backend. The plugin currently only works with the
legacy IMAP backend.
Just
the possibility of doing this kind of thing more smartly
behind the scenes.
Thanks for the feedback.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman
from
GConf entries to plaintext data files. Account info is now stored in
~/.config/evolution/sources where it's much easier to backup and copy.
The contents of this directory determine whether Evolution runs the
account wizard on startup.
Matthew Barnes
On Thu, 2012-12-13 at 08:59 +0100, Milan Crha wrote:
I didn't understand from the initial announcement that you'll not only
merge those above in one .so, but that you'll also move all the files
into one folder. This makes it quite messy to find anything, the
previous file layout was better
On Sun, 2012-12-09 at 08:59 -0500, Matthew Barnes wrote:
I expect this is a couple days worth of monkey work, but I should have
it done by mid-week in time for the 3.7.3 release.
Just committed this to master.
If you're building from git, I would strongly advise blowing away your
current
On Tue, 2012-11-27 at 14:20 -0500, Matthew Barnes wrote:
Immediately after the merge I'm going to consolidate Evolution's base
libraries into a single base utility library. libeutil seems as good
a name as anything else I can think of, so I'm going to stick with that.
Since the webkit
in the library.
With all the base utility libraries under one header, maybe we can then
get serious about producing some good API documentation for this stuff.
My attempts thus far have been half-hearted at best.
Matthew Barnes
___
evolution-hackers
.
Shutdown Evolution and try running this little script:
http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https
On Tue, 2012-11-27 at 14:20 -0500, Matthew Barnes wrote:
The new libeutil will include APIs that are currently scattered across:
a11y/libevolution-a11y.so
e-util/libeutil.so
filter/libfilter.so
widgets/e-timezone-dialog/libetimezonedialog.so
widgets/editor/libeeditor.so
out, especially in quoted replies.)
Matt
On Mon, 2012-11-26 at 08:37 +0100, Milan Crha wrote:
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote:
1) Write this as a ESourceRegistryServer extension, and just link to
GTK+ from the extension module. That way it's easily removable
On Thu, 2012-11-22 at 08:52 +0100, Milan Crha wrote:
I'm only waiting for an opinion from Matthew, then I'll happily change
the build script.
I guess I don't have a strong attachment to it.
ChangeLog files are technically part of the GNU Coding Standards [1],
and strictly speaking the product
motions in their general direction.
I'm hoping next year we can start taking real steps in that direction.
That's the best answer I can offer for now. In the meantime, maybe
consider using a Virtual Private Network. ;)
Matthew Barnes
___
evolution
On Fri, 2012-11-02 at 14:12 +, Reid Thompson wrote:
When compiling from current head, compilation stops on reaching
@GNOME_CODE_COVERAGE_RULES@
You need a more recent gnome-common. 3.6 or later.
___
evolution-hackers mailing list
are supported by
its respective Camel/E-D-S backend.
Matthew Barnes
[1] http://git.gnome.org/browse/evolution/tree/modules
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https
still at a
bit of loss as to your use case.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
/ESourceMigrationGuide#How_do_I_create_a_new_calendar_or_address_book.3F
Hope this helps,
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo
be inhibited
by something pushing a different thread-default GMainContext. Otherwise
deadlocks occur when an ESourceRegistry method has to stop and wait for
a signal emission from the GDBusObjectManagerClient, such as in the case
described above.
Matthew Barnes
On Mon, 2012-09-17 at 12:18 +0200, Christian Hilberg wrote:
Matt, I guess it'll be you pushing 3.6.0 out the door, right? (It's just
a matter of when to expect 3.6.0 to be out so I can wrap up evolution-kolab
for that release).
Yes, I'll handle 3.6.0 next weekend.
See:
be on the clock, and thereafter reachable by email only until
Monday, October 8th.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo
On Wed, 2012-09-05 at 09:57 +0200, Christian Hilberg wrote:
Thanks for the heads-up. I remember you mention some sort of API
restructuring / rework concerning E-D-S, D-Bus and EClients you had in
mind for 3.7/3.8 cycle. Do you have anything cooking in this regard
already? Might be worth
On Wed, 2012-08-29 at 16:11 +, Reid Thompson wrote:
(evolution-calendar-factory:8178): GLib-GIO-WARNING **: Can't find
module 'dconf' specified in GSETTINGS_BACKEND
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
On Fri, 2012-08-17 at 08:31 +0200, Milan Crha wrote:
ews account name
+-- Foreign Folders
+-- Mailbox - someone else
+-- some subscribed folder
+-- Favourites (Public Folders)
+-- Mailbox - User Name
I was suggesting to have separate top-level
for
remote mail?
Those directories are for caching remote mail, correct.
The accounts themselves are in ~/.config/evolution/sources now.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe
mail folders.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
filters to new messages in Inbox on this server
Maybe the backend is confused as to which folder is now Inbox. Does
your Inbox folder show an Inbox icon in the folder tree?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
On Thu, 2012-08-16 at 19:04 +0200, Milan Crha wrote:
ouch, I did that, I didn't think of filters at all :( The reason for
movement to Mailbox - User Name is to be able to add folders of other
users to the ews. They will then show in Foreign Folders/Mailbox -
other user/..., but it seems I
Just for the record, I made a few API changes to Camel over the weekend.
The changes help increase Camel's thread-safety. One lesson I learned
during the account-mgmt work is when returning a pointer to a reference
counted object in a multi-threaded environment, it's better to return a
new
On Mon, 2012-08-13 at 19:00 +0100, Philip Withnall wrote:
This is all great work! Just a point to note: Telepathy uses the
convention of calling refcounting getters ‘_dup_’ (e.g.
“camel_session_dup_service()”) rather than ‘_ref_’. This seems better
(imo) because ‘ref’ could get confused with a
1 - 100 of 465 matches
Mail list logo
