Re: [Evolution-hackers] Imminent critical SSL problem in evolution 3.10

2014-10-29 Thread Matthew Barnes

On 10/29/2014 02:56 AM, Milan Crha wrote:

we look on the same thing in a different ways. My point of view:
the *current* stable version is 3.12.x (right now 3.12.7). This
current stable version doesn't suffer of the issue described for 3.10
version. It's not my fault that your distribution uses obsolete
evolution version; I do not have any influence on it. The bug as such
is fixed, in the *current* stable version. The 3.10 is dead for the
upstream. Nonetheless, my intention was to provide a fix for such
distributions anyway, in a way I chose. I'm not going to commit the
patch to the gnome-3-10 branch, I do not like to add changes into dead
branches, where no releases will be done.


Rather than burying the patch in Bugzilla or on a dead git branch, I 
suggest sending it to distributor-l...@gnome.org with an explanation of 
what versions are affected.


Then if any other complaints 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://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e-d-s build problems

2014-09-26 Thread Matthew Barnes
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 and when the problem started, but at the moment I
 cannot build e-d-s/master. I removed all my local/libs and tried a fresh
 checkout with jhbuild, same result DSO missing from command line
 
 to work around the issue I changed some Makefiles and added the missing
 symbols/lib manually to _LIBADD (see below)
 
 evo and e-d-s compile now, but I'm not 100% convinced of the result,
 since evo deleted my Personal addressbook the first time I started
 evo...
 
 Is something wrong with my system or are other people seeing the same
 issues? (I know there has been a similar thread earlier this year for
 3.12)
 
 Christian
 
 ---
 /usr/bin/ld:
 evolution_addressbook_factory_subprocess-evolution-addressbook-factory-subprocess.o:
 undefined reference to symbol 'e_dbus_subprocess_object_skeleton_new'
 
 evolution_addressbook_factory_subprocess_LDADD
 $(top_builddir)/private/libedbus-private.la \
 
 
 src/evolution-data-server/calendar/libecal/e-cal-client.c:832: undefined
 reference to `e_dbus_calendar_call_close'
 .libs/libecal_1_2_la-e-cal-client.o: In function
 `cal_client_get_backend_property_sync':
 
 libecal_1_2_la_LIBADD =
 $(top_builddir)/private/libedbus-private.la \
 
 ---
 src/evolution-data-server/calendar/libedata-cal/e-data-cal.c:569:
 undefined reference to `e_dbus_calendar_complete_open'
 
 
 libedata_cal_1_2_la_LIBADD = \
 $(top_builddir)/private/libedbus-private.la \
 evolution_calendar_factory_subprocess_LDADD = \
 $(top_builddir)/private/libedbus-private.la \
 
 
 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 https://mail.gnome.org/mailman/listinfo/evolution-hackers
 
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Fwd: e-d-s build problems

2014-09-26 Thread Matthew Barnes


- 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:
 https://git.gnome.org/browse/evolution-data-server/commit/?id=a2790163af4d3f375a778055d0e2699207dfd050

solved my problem too.

Christian

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] WebKit based Evolution composer status and future

2014-06-10 Thread Matthew Barnes
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 good!

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?

2014-05-20 Thread Matthew Barnes
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 with a dangling pointer or (if it somehow
 tracks the lifetime of the owner of the object) in a state where it is
 unusable.

I imagine the GObject proxies would need to hold their own copies of
libical objects and have some explicit set API to apply changes back
to a parent object.

It's more expensive, but that's the trade-off for thread-safety.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Developing a new protected message complement

2014-04-02 Thread Matthew Barnes
On Tue, 2014-04-01 at 11:02 -0430, BECERRA Silvana M SIDOR wrote:
 Actually, we're analyzing the possibility of going to a more updated
 version of EVO (we have it on canaima 4.0 based on debian 7.0 and
 Gnome 3.4.2), but we've had trouble compiling a newer version. Do
 you know where we can get a compiled version that works?

I've never heard of Canaima, but if it's a Debian derivative then
Debian's testing or experimental repos would be your best bet for
newer Evolution packages.

 
 However, to try to clarify a bit, what we mean by protected Email is
 that when reply/forward (inline mode) a protected message we're
 allow to write our response but we should not be able to modify the
 text of none of the old messages. Additionally, although not commented
 before, the message should also include custom field in the header
 that consolidates date, from, to, of all old messages in an orderly
 manner.

For that kind of protection to have any real meaning, all messages
should be cryptographically signed by their author and attached in full
to all replies and forwards.  An Evolution extension could conceivably
enforce that.

The inline editing mode simply copies and pastes the source message
body into what's essentially a free-form text editor.  Trying to protect
the pasted text in a free-form editor widget is pointless because it can
be easily spoofed, as can any kind of custom message header.

Cryptographically signing each message with a public key or a trusted
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-hackers


Re: [Evolution-hackers] Sieve application for filtering mail [was: Re: Evolution custom email message]

2014-03-27 Thread Matthew Barnes
On Thu, 2014-03-27 at 09:12 -0400, Adam Tauno Williams wrote:
 FYI, in case you want to look at some working code; the Horde suite [a
 set of web applications] has a mail-filter front-end named Ingo that has
 very good SIEVE support.
 https://github.com/horde/horde/tree/master/ingo/lib/Script/Sieve

Thanks, that may prove quite useful.


 Wow. I have to say I have *never* seen a UI that parsed SIEVE.  Every
 interface I have seen lets you create mail filter rules and `compiles`
 them into SIEVE.  Personally I wouldn't view *reading* SIEVE to be all
 that critical;  I would just like to be able to set my rules and have
 them compiled and activated on the server.

I think we also want to allow revising existing SIEVE rules, which means
parsing a rule sufficiently to present it in an editing UI.

Otherwise there would be no allowance for typos or revisions; any change
would require deleting the old rule and forcing the user to recreate it
in the editor from scratch.

With the aid of a parser generator tool like bison, it shouldn't be that
difficult to generate an abstract syntax tree from a SIEVE rule.  I have
some experience with bison to lend.

Also, having a good language-independent abstract representation will be
key to integration, as it will have to accommodate both SIEVE rules and
Evolution's local S-Expression rules (assuming we keep that format).

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


Re: [Evolution-hackers] WebKit based Evolution composer status and future

2014-03-17 Thread Matthew Barnes
On Mon, 2014-03-17 at 09:25 +0100, Tomas Popela wrote:
 Regarding the future of WebKit based Evolution composer I'm proposing
 this: merge webkit-composer branch into master when the 3.12 release
 will be branched and continue to work on it in master branch. This will
 hopefully bring more testers for the new composer. When the code will be
 in master I will continue to develop it and also porting it to WebKit2
 with the rest of Evolution.

That sounds reasonable.  Thanks for all the work you've put into this!

Since the master branch is under a code freeze this week, this would be
an excellent time to rebase the branch and sort out any conflicts in
preparation for merging -- if you haven't already.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Evolution moving to an annual schedule

2014-03-17 Thread Matthew Barnes
With the release of 3.12.0 next Monday, Evolution and E-D-S will
transition to an annual instead of semi-annual release schedule.

This is primarily to compensate for the long delays between upstream
releases and distribution releases, and will give Evolution users more
time to upgrade to and use a version supported by the development team.

The Evolution release schedule will consist of monthly updates to both
our development branch and latest stable release branch throughout the
year into February, and will then sync up with GNOME's SPRING release
schedule, starting with the .90 release through the final release,
honoring all the announcement and freeze periods therein.

Package maintainers of distributions on a semi-annual release schedule
should plan accordingly.

I've charted the Evolution release schedule for the coming year here:
https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO#Release_Schedule

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


Re: [Evolution-hackers] WebKit based Evolution composer status and future

2014-03-17 Thread Matthew Barnes
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 reverted or will Evolution have to go out with
 known regressions?

The next release following 3.12 will happen in March, 2015.  So we have
an entire year to stabilize the WebKit composer.  Also the HTML library
that the composer is currently based on has been dead several years now,
and I personally would like to wash my hands of it as soon as possible.

I haven't tested the branch in awhile, but I've seen numerous recent bug
reports from Milan and Tomas seems pretty responsive in fixing them.  As
long as that continues after merging, and we have a handle on the major
remaining regressions, I think it's a reasonable risk to finish the work
directly on the master branch.

If things still haven't stabilized by... let's say this year's GUADEC...
then we can start discussing a contingency plan for Evolution 3.14.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] newcomers: How should I compile Evolution?

2014-03-06 Thread Matthew Barnes
On Thu, 2014-03-06 at 09:58 +0100, Fabiano Fidêncio wrote:
 I can bet that (almost) every contributor has a different way to setup
 the environment, compile and use the fresh compiled Evolution and I'm
 here to describe the way I do my setup (based on Matthew's setup) :-)

Nice instructions!  I should transcribe this to a wiki page.

Let me amend this with a couple more tricks...

I also have three scripts (or just aliases would work too) named:

   autogen-eds

   autogen-evo

   autogen-ews

Each of these is basically just...

   ./autogen.sh --prefix=$PREFIX (yadda, yadda, yadda)

This is where I keep the configure options I routinely use for building
evolution-data-server, evolution, and evolution-ews, respectively.  It's
mainly just options like --enable-this or --disable-that, etc.  That way
I don't have to remember them all or keep them typing them all.

Also, a newcomer may not need this but just for completeness, I also
have a script named 'stable', which is almost the same as 'unstable',
but uses a different PREFIX ($HOME/local/stable).  It too references
'common', which is why 'common' is a separate script.

I use 'stable' for building our latest stable branch, currently
gnome-3-10.  It uses a different install prefix so I don't mix files
from the two branches.  That would be bad.

Also, speaking of branches, generic git trick:

For me the 'git-new-workdir' script that comes with git is a life saver!
It allows you have multiple working directories for the same repo
without cloning the whole repo, each checked out to a different branch.

That was my biggest complaint with git when I first started using it --
that to switch branches I first had to pack up whatever I was doing in
the current working directory, switch branches, and wipe the working
directory clean so I don't pick up build artifacts from the other
branch.  But that increases the build time and slows me down.

The 'git-new-workdir' script solves this, but it's not installed in
/usr/bin for some reason.  You have to dig it out of:

   /usr/share/doc/git/contrib/workdir

or some similar place 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 or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Proposal: Evolution 3.13 Release Schedule

2014-03-06 Thread Matthew Barnes
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 and 3.12.1 release dates in mind, I propose the
 following:
 
   - Release stable updates on the 2nd Monday of each month.
   - Release development updates on the 4th Monday of each month.


Another thing I've been thinking about is what to call our stable branch
names, starting with 3.12.  The usual gnome-3-x branch name is going to
be confusing, especially later this year when our version number starts
to diverge from GNOME's version number.

I suggest just naming the branches after the module name, similar to how
GLib and GTK+ do it.  e.g.

   evolution-3-12
   evolution-data-server-3-12
   evolution-ews-3-12
   evolution-mapi-3-12

That sound okay?  I don't have a strong preference for the name, other
than not using 'gnome' anymore.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] When talking about branches...

2014-03-06 Thread Matthew Barnes
On Thu, 2014-03-06 at 16:09 +0100, Milan Crha wrote:
 when talking about branches, what about deleting all those obsolete for
 years? I mean the development branches, not those release related.
 I believe they are useless, definitely those not touched for years (even
 for months, like mine where I initiated the EClient stuff couple years
 ago).

Sounds okay to me.  Looks like a there's a lot of cruft to sort through.

I think the wip/webkit-composer branch might still be alive (ask Tomas).

I don't know of any other live wip branches at the moment.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] When talking about branches...

2014-03-06 Thread Matthew Barnes
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 are:

  git branch -r   -- list all the remote branches

  git push origin :branch-name  -- deletes a remote branch

(I don't really understand the colon, but that's how it works.)

Obviously be careful if you try to automate this or use grep or
whatever.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] When talking about branches...

2014-03-06 Thread Matthew Barnes
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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Keep an eye on IMAP this week

2014-02-23 Thread Matthew Barnes
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 week.
If there's disastrous regressions I'm willing to revert.

Note, Camel has actually been using GLib streams since early 3.11, but
it was hidden behind the CamelStream API layer.  All these commits do is
cut out the middle man.  It's a significant step toward finally retiring
the whole CamelStream API.

I'll be porting the POP3 and NNTP backends after 3.12.  Those should be
easy by comparison.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] GSoC Ideas

2014-02-11 Thread Matthew Barnes
On Tue, 2014-02-11 at 18:18 +0100, Milan Crha wrote:
 On Tue, 2014-02-11 at 17:21 +0400, Emre Erenoglu wrote:
  2) Attachment Detach and Link function
 
 This one, from my point of view, doesn't qualify for a GSoC project,
 basically because it's only a serialization of two actions, which
 might not make anybody busy for couple weeks. Also, as Andre mentioned
 on the evolution-list, those detached attachments might not be
 available, if you move to other machine (supposing you'll move the
 attachment on a remote protocol, like IMAP, Exchange related, and so
 on), thus the link to it will be relevant only on one machine, and only
 until user actually deletes the file (or even better until overwrites it
 with a content from other attachment, which may then just confuse
 him/her, even unintentionally and being done by the user him/her-self).
 
 It doesn't mean that it cannot live as a bug request, for someone whom
 would like to play a bit with the code, it's just that it's too simple
 for a GSoC project, from my point of view.

I agree.  I think it would be sufficient to just prompt to save the
attachments before permanently removing them.  The prompt would also
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


Re: [Evolution-hackers] GSoC Ideas

2014-02-11 Thread Matthew Barnes
On Mon, 2014-02-10 at 09:41 -0500, Eldon Ziegler wrote:
 How about an ability to use a different backend DB, if that does not
 exist already? I use MongoDB to scoop up my email after Evolution stores
 it and it would be really great if MongoDB also could be used within
 Evolution itself.

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 or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] GSoC Ideas

2014-01-28 Thread Matthew Barnes
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 Evolution's wikipage.

A couple years ago I mentored a GSoC student on a concept demonstration
of a GTK-based server-side mail filter editor which would have used the
ManageSieve protocol.

The plan was to create a working stand-alone demo application for the
GSoC project, and then afterward start integrating it into Evolution.

The student never finished, but I still think it's a good idea.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] evolution-data-server build fails with undefined reference to camel_stream_new

2014-01-25 Thread Matthew Barnes
On Sat, 2014-01-25 at 12:42 -0800, Kerrick Staley wrote:
 Building evolution-data-server via JHBuild isn't working for me. The
 relevant section of the error output is [1], and the full log is
 attached. Does anyone know why this is happening?

Means you have old build artifacts installed 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/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [Draft] Evolution Road-map for post-3.12

2014-01-24 Thread Matthew Barnes
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 split off from E-D-S and declare stable.  I've intended to do
that for several years [1], but parts of Camel's API are still a mess
and I'm not yet willing to commit to them.

Among the things that need done yet are:

  * Kill CamelStream and all its subclasses and port Camel entirely
to GIO-based streams.  I'm already making some headway on that.

  * Move all the filtering logic into Evolution.  Camel's filtering
logic is already highly dependent on Evolution and not fleshed
out well enough to be usable on its own.  From there I can more
easily make some badly needed improvements under Evolution's
umbrella, where API stability isn't an issue.

  * GMime is Jeff Steadfast's partial fork of Camel, and there's
still a lot of shared heritage there.  I understand he added a
pretty comprehensive test suite, and I'd like to try importing
that and adapting it to Camel's current APIs.

  * Study/cleanup/document the summary database and virtual folders.
I still don't really have my head around these areas.  The APIs
are a mess and nothing's documented.  I'd like to spend a little
time on it and probably do some refactoring before the split,
because I can't maintain this stuff if I don't understand it.

  * Maybe annotate the API for introspection and generate language
bindings?  Even if there's no demand for Camel bindings, I think
the practice helps promote good discipline and API design and is
worth the effort.

Between the wiki page items, this stuff, and the usual caring and
feeding of the project, I think that's a pretty full plate for me.

Matt


[1] 
https://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [PATCH evolution-data-server] imapx: Remove check for NIL separator

2014-01-08 Thread Matthew Barnes
On Mon, 2013-12-30 at 00:37 +0100, Lubomir Rintel wrote:
 This has been tested with MUNI IMAP server along with:
 Subject: [PATCH evolution-data-server] imapx: Treat BODY[HEADER] as 
 equivalent to RFC822.HEADER
 Date: Sun, 29 Dec 2013 21:10:57 +0100
 Message-id: 1388347857-1479-1-git-send-email-lkund...@v3.sk
 
  camel/providers/imapx/camel-imapx-namespace.c | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/camel/providers/imapx/camel-imapx-namespace.c 
 b/camel/providers/imapx/camel-imapx-namespace.c
 index c86165b..c924d39 100644
 --- a/camel/providers/imapx/camel-imapx-namespace.c
 +++ b/camel/providers/imapx/camel-imapx-namespace.c
 @@ -93,7 +93,6 @@ camel_imapx_namespace_new (CamelIMAPXNamespaceCategory 
 category,
   CamelIMAPXNamespace *namespace;
  
   g_return_val_if_fail (prefix != NULL, NULL);
 - g_return_val_if_fail (separator != '\0', NULL);
  
   /* Not bothering with GObject properties for this class. */
  

Thanks for that.  I remember not being sure about that assertion when I
wrote it.  Either the RFC wasn't clear or I missed some fine print.

I'll commit this and your BODY[HEADER] patch for the next release.

For future reference it's 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 ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] libecal soname change

2014-01-02 Thread Matthew Barnes
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 -0400
 
 Bump libecal / libedata-cal soname for API breaks.
 
 Matthew, can you elaborate what that break is?

The libdata-cal bump was to cover the preceding commits:

commit f9ee1477151f2747745f2e90e1a7d34bc992b931
Author: Milan Crha mc...@redhat.com
Date:   Tue Jul 16 12:05:30 2013 +0200

Insufficient return values from e_cal_backend_get_object/_list()

These also returned ECalComponent, but it cannot hold a vCalendar,
which is returned when the component has detached instances.

commit 9da18738a150915500a44e0e7c54d9ef1eb4f3c4
Author: Milan Crha mc...@redhat.com
Date:   Tue Jul 16 09:01:55 2013 +0200

Bug #704220 - Incorrect runtime check in e_data_cal_respond_send_objects()

The libecal bump looks like it may have been a mistake on my part.  I
must have been under the impression the client-side API changed as well.

Sorry about that.

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


[Evolution-hackers] The wiki is the new official homepage

2013-12-18 Thread Matthew Barnes
In light of [1], the Evolution website on http://projects.gnome.org/ has
been decommissioned.  The Evolution wiki is our new official homepage.

http://wiki.gnome.org/Apps/Evolution

The website content was aging anyway, and was a pain to maintain.  About
the only thing I was updating 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] http://blogs.gnome.org/mccann/2013/12/17/lets-face-it/

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Junk filtering controls and logic are confusing

2013-11-23 Thread Matthew Barnes
On Sat, 2013-11-23 at 10:48 -0600, Michael Ekstrand wrote:
 The particular working of the junk filtering pane (Preferences - Mail
 Preferences - Junk) is confusing, and the functionality it controls is
 (A) hard to understand and (B) arguably incorrect.

Indeed.  You're wading into a mess here.

The junk filtering logic bounces between Camel and Evolution.  Camel's
filtering (both junk and otherwise) is highly dependent on Evolution and
at some point I'd like to move it all to Evolution and get Camel out of
the filtering business entirely.  (The relevant Camel APIs badly need an
overhaul as well, as they're ancient, error-handling is pretty much non-
existent and they block like crazy.)


 1. What all does 'Check incoming messages for junk' control? Everything?
 Just the junk plugin (spamassassin/bogofilter)?  Does checking or
 unchecking it affect whether custom headers are scanned?
 - Potential UI fix: the options for everything that is pre-empted by
 disabling junk checking should be disabled when the checkbox is cleared

I think the option should be removed entirely and be made per-account,
but that may be a bit of a project.  At the moment, only IMAP accounts
have their own junk filtering options, and I believe those options are
secondary to this master switch.

Disabling the Check incoming messages for junk turns off everything:
custom header checks, address book lookups, and junk filtering software.


 2. What option is ignored if a match for custom junk headers is found?
 - The code suggests that the address book and and junk filter plugin
 logic are both ignored if custom headers are found

Correct: headers first, then address book, then filtering software.  I
think it's meant to be in order of fastest to slowest.  As soon as any
of those tests determine the message to be junk, processing stops.


 3. What happens if there is no junk plugin (bogofilter/spamassassin)
 installed? UI makes it looks like the custom headers will work, and
 address book checking will work.  However, the code seems to disagree:
 looking at the junk_test function in camel-filter-search.c, it looks
 like everything is just bypassed if there is no junk filter installed.

Yeah you're right.  Probably even my handiwork.  The header and address
book checks should run regardless.  That's a valid bug.


 In my mail setup, I run SpamAssassin on the server (as a Postfix
 milter).  I want Evolution to check the spam headers set by the server,
 but not to mess with running bogofilter or spamassassin or anything like
 that locally.  Further, since my server's SpamAssassin doesn't know
 anything about my address book, I want the address book lookup to
 override the custom header check.

The processing order I mentioned above would have to be changed.

I don't have any strong opinions about that since I just use Bogofilter.


 The UI makes it ambiguous as to whether this is possible.  Looking
 through the code, to the extent that I understand it so far, it looks
 like it is not.  If I have no junk filter plugin, then Evolution will
 not do any checking, including for custom headers.  If I have one, then
 I'm double-scanning my mail and slowing down Evolution.  And the address
 book check doesn't interact with the header check.

It would be clearer if the UI read more like a checklist:

   [ ] First check this...

   [ ] Then check this...

   [ ] Then check this...


 In particular, a few things I am immediately interested in making
 happen:
  1. Making address book checks preempt spam header checks
  2. (maybe) figuring out why the spam header check isn't doing
 anything
  3. Making spam header  address book checks work without a spam
 filtering plugin
  4. Making spam filtering UI disable things to show how it works

Sounds great to me!

Polishing up those options and unbreaking whatever's broken would be
much 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


Re: [Evolution-hackers] Junk filtering controls and logic are confusing

2013-11-23 Thread Matthew Barnes
On Sat, 2013-11-23 at 15:44 -0600, Michael Ekstrand wrote:
 I've cooked up a pair of not-yet-tested patches that address (1) by
 moving the address book check before the header check and (3) by moving
 the 'do we have a junk filter?' test to right before the junk filter is
 actually moved.

Sounds good.  For (1) please add a comment to the junk_test() function
describing the rationale for the new ordering, for posterity.


   * Keep 'Check incoming messages for junk' as the top, top-level
 check box.  Have it enable/disable the following options, which
 are indented under it:
   * 'Skip junk detection if sender is in my address book'
   * 'Lookup in local address book only'
   * 'Check custom headers for junk flags'
   * 'Use external junk filter' drop-down (invisible if no
 plugin available, junk filter config UI is subordinate
 to this checkbox)
   * 'Delete junk messages' as top-level sibling of 'Check…', at the
 bottom of the pane
   * Get rid of the 'Option is ignored…' notice

Sounds good on paper.  Maybe you could post a screen shot when you get
things reworked?

A word of warning about Glade, if you choose to use it, is to carefully
check over the changes it makes after saving because it loves to corrupt
our .ui files.  Glade eats any widget types in the .ui file it doesn't
understand and sometimes doesn't get along well with our one-letter 'E'
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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Running Evolution from jhbuild

2013-11-22 Thread Matthew Barnes
On Fri, 2013-11-22 at 08:48 -0600, Michael Ekstrand wrote:
 I can't use the address book subsystem - it says the AddressBook6
 service isn't provided by any .service files.  I'm using the default
 moduleset, did 'jhbuild build evolution'.

You probably haven't configured your session bus to look for service
files in the place where jhbuild installs them.

Add something like this to your /etc/dbus-1/session.conf:

  servicedir/path/to/jhbuilt/share/dbus-1/services/servicedir

Or you could just start the services manually from a separate terminal
window.  That's what I usually do so I can 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


Re: [Evolution-hackers] EDS Documentation Effort

2013-11-04 Thread Matthew Barnes
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 huge
 list, I'd like to share my plans with the list. Hopefully
 with some of your feedback I can maximize the value of
 this work.

Excellent!  I'm happy to help out with this.

In the past year or two I've tried to discipline myself to document
every new symbol I add, and I've noticed Milan has started doing that
now too.  So the newer APIs should be in pretty good shape already.

A lot of the older APIs are either undocumented or the documentation
has... word-rotted... and is no longer accurate.  It's a mind-numbing
task to fix that stuff up and I've only managed to do it in fits and
starts.  A concerted effort I think is exactly what we need.


   o It probably makes sense here to evaluate also if and
 where there are multiple methods of achieving the
 same effect in the EDS user facing APIs (some of
 the e-data-server-utils.c parts might suffer this).
 
 In the case there are multiple code paths to the
 same result, we should take care to deprecate one
 of them.

Agreed.  In particular, I suggest not wasting much time on the EBook and
ECal APIs, as those have been deprecated for a couple years now and are
about ready to be dropped.


   o One thing I'd like to propose is a unified book for
 EDS.
 
 With a unified documentation package for the whole EDS
 API (perhaps excluding camel), a much more useful and
 comprehensive table of contents can be built.

Also agreed.  I don't know why that hadn't occurred to me already.  It
would make maintenance easier as well.

Yes, Camel docs should remain separate.  Camel is destined to be split
off from the E-D-S git module and should be considered a base dependency
of E-D-S, not really part of E-D-S.


Another good high-level goal would be to get all the Gtk-Doc warnings
fixed for things like improper gtk-doc syntax in comments, mismatched
argument names, etc.

It would be great we could enable TESTS = $(GTKDOC_CHECK) in the
Makefile.am and require that to pass as part of the release process.

Maybe we should take that one library at a time, though.


Anyway, big +1 from me on this whole proposal.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] EDS addressbook api info

2013-10-22 Thread Matthew Barnes
On Wed, 2013-10-23 at 00:39 +1100, Timothy Ward wrote:
 After looking at the latest EDS docs and the info on the latest EDS
 addressbook API I wondered if there were and docs related to reading the
 address book info in total all fields to another source, the code I am
 using is quite old and the addressbook API interface has changed many
 times and requires rewritting. Do any reference notes exist that would
 help me with this task.  

Not quite sure what you mean by reading to another source, but you can
obtain all the EContact objects from an address book with
e_book_client_get_contacts().

You'll want to pass an S-expression query that just matches everything.
I believe the way to do so is:

book_query = e_book_query_any_field_contains ();
sexp_string = e_book_query_to_string (book_query);

e_book_client_get_contacts (client, sexp_string, ...);

The query syntax 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://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regarding addressbook migration test case

2013-10-21 Thread Matthew Barnes
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 this.  Perhaps it could serve as a template for
other kinds of migration testing in the future.  The mbox - Maildir
migration back in 3.0 would have been less problematic with something
like this.

To clarify: New test cases are only *really* needed when the database
format changes, right?  A test-case-per-version policy is more about
maintainers can't be trusted to update tests when needed.

Not offended, in fact I agree.  Just want to make sure I have the
rationale straight.


 I've tried to make this as painless as possible,
 in order to add a new release to the list of tested
 stable releases, one needs to do the following:
 
   cd ~/path/to/evolution-data-server
   make -C tests/book-migration setup-migration
   git add tests/book-migration/db/3.12/contacts.db
   gedit tests/book-migration/db/3.12/Makefile
 (add contacts.db to EXTRA_DIST)
 
 For reference, you can see this commit[1] which adds
 EDS 3.10 to the list of releases to test.

Looks easy enough.

Best place for these extra steps would be:
https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO

Would you mind writing up a new section there (or I can), maybe after
Post-Release Updates?

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Tentative 3.11 schedule

2013-10-14 Thread Matthew Barnes
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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Tentative 3.11 schedule

2013-10-13 Thread 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
(October 21st).  Let's proceed with that unless GNOME posts something
official this week.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Testing EEwsConnection's API

2013-10-10 Thread Matthew Barnes
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
backends in the future.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] geocode-glib version

2013-09-01 Thread Matthew Barnes
On Sun, 2013-09-01 at 13:12 -0300, Sasa Ostrouska wrote:
 Hi I was just wondering if is there a special reason to use
 geocode-glib version 0.99.0 as there is
 
 already out a 0.99.2 so would be nice to have in configure.ac
 geocode-glib = 0.99.0 instead of geocode-glib = 0.99.0

There were substantial API changes on the master branch of geocode-glib
that we don't yet support.

I don't yet know if 0.99.2 includes those changes or if it's backward
compatible with 0.99.0.

If it's backward compatible then we can support it for Evolution 3.10,
otherwise it has to wait for Evolution 3.11/3.12.

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


Re: [Evolution-hackers] Evolution EWS: Planning the 3.12

2013-08-26 Thread Matthew Barnes
On Mon, 2013-08-26 at 08:27 +0200, Fabiano Fidencio wrote:
 I've been planning what I want to have implemented for 3.12, for
 evolution-ews.
 If you are interested, please, take a look into:
 http://blog.fidencio.org/2013/08/evolution-ews-planning-312.html
 
 Feel free to ping in #evolution or reply this message, if you want to
 discuss something about the planning.

Nice!  Thanks for that.

I need to get a Planning312 page going on the wiki soon [1].  When I do,
is it alright if I link to your blog post under an item titled Exchange
Web Services Improvements or something?

Matthew Barnes


[1] Similar to https://wiki.gnome.org/Apps/Evolution/Planning310

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution EWS: Planning the 3.12

2013-08-26 Thread Matthew Barnes
On Mon, 2013-08-26 at 15:48 +0200, Fabiano Fidencio wrote:
 If you prefer, I can put all these info in the wiki, following the way
 you have been done for 3.10.
 It's up to you :-)

Nah, no need to duplicate the info.

The wiki page in its present format isn't the best place for detailed
plans.  I 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


[Evolution-hackers] Move IMAPX back to a module library for 3.12

2013-08-19 Thread Matthew Barnes
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 toward completing IMAP NOTIFY support, and I would
prefer these changes not be seen as breaking Camel's public API so I
have sufficient freedom to change what needs changed.

Therefore I plan to move the IMAPX classes back to a runtime-loadable
module library after the 3.10 release.  If the evolution-kolab project
is resurrected at some point in the future then we can renegotiate this.

Any objections?

Matt



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Wiki moved

2013-08-13 Thread Matthew Barnes
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 absolute instead
of relative paths in wiki links, so the move broke all those links.

He and I fixed up what links we could find, but keep watch for any other
broken links on our wiki.

The absolute paths were mostly my fault, but to keep this from happening
again use this syntax:

   /ChildPage  (child of the current page)

   ../SiblingPage  (sibling of the current page)

Instead of:

   Apps/Evolution/SomePage  (this is an absolute path)

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Evolution Hackfest at GUADEC 2013

2013-08-13 Thread Matthew Barnes
Alberto Ruiz (my new boss) organized and led an Evolution hackfest at
this year's GUADEC in Brno, Czech Republic.

He posted a summary on his blog, for those interested:

http://aruiz.synaptia.net/siliconisland/2013/08/evolution-hackfest-2013-redux.html

The transition to an annual release cycle, which I brought up before in
[1], is a go for next year.  The Evolution team was in agreement, and I
got no objection from the GNOME release team.

It was really fun meeting almost everyone present in person for the
first time.  Even met Milan Crha for the first time, even though we've
been working 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 list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Reconsidering our release cycle

2013-07-28 Thread Matthew Barnes
On Fri, 2013-07-26 at 07:38 -0400, Matthew Barnes wrote:
 It seems like we have a general consensus among developers in favor of a
 longer release cycle.  Next week I think I'll pitch the idea to the user
 list just to get a sense of the response.

Just to follow up, I posted this to the user list over the weekend:
https://mail.gnome.org/archives/evolution-list/2013-July/msg00162.html

Too early to draw conclusions from the response, but so far so good.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Reconsidering our release cycle

2013-07-28 Thread Matthew Barnes
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 yes: Why would that be? The arguments on
 favour of a longer cycle seem to be very generic to me.

It's difficult to speak to GNOME as a whole because -- GNOME OS visions
notwithstanding -- GNOME is a diverse collection of independent projects
of different sizes, levels of maturity, activeness and agendas.

Different projects of different sizes have different needs.  I'd caution
against generalizing from one example.  The arguments brought up here
may not be unique to Evolution, but they're based on observations of how
well Evolution development policies are serving the Evolution community.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Reconsidering our release cycle

2013-07-28 Thread Matthew Barnes
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 Evo were changed to be more of a stand-alone
 utility (at least optionally), rather than being bundled with Gnome,
 that would be (IMO) a good thing for users.

I've already come to regard Evolution as a GTK+ application rather than
a GNOME application.  While we do have some (optional) desktop-specific
integration for GNOME and Unity, I for one do most of my development on
XFCE nowadays.

Evolution has also been buildable on multiple GNOME releases for awhile
now.  For the past several years I've tried to ensure the development
branch of Evolution and co. remains buildable on the latest *stable*
GNOME development platform, such that our major releases are actually
developed for the previous GNOME release.  Evolution 3.8, for example,
builds on both GNOME 3.8 and GNOME 3.6.

I think targeting the latest stable development platform strikes a good
balance between utilizing new advancements in the platform and keeping a
safe distance from the chaos at the bleeding edge.  I don't foresee that
policy changing as we transition to a longer release cycle.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Reconsidering our release cycle

2013-07-26 Thread Matthew Barnes
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 and to see their bugs fixed without
 waiting half a year.
 
 It's just an idea.  What do you guys think?


It seems like we have a general consensus among developers in favor of a
longer release cycle.  Next week I think I'll pitch the idea to the user
list just to get a sense of the response.

To clarify a few points:

* I should have been more explicit but I did mean ALL our modules, not
  just Evolution.  EWS, MAPI, and especially E-D-S.  I think E-D-S is
  more in need of a longer support cycle than Evolution itself, since
  a lot of our stable branch maintenance focuses on the infrastructure
  and backends provided by E-D-S.  IMAP, CalDAV, LDAP, etc.

* I see the wisdom in Milan's suggestion of sticking to our current
  version numbering, but just slowing it down.  It might cause some
  confusion initially, but once we jump ahead of the GNOME release
  numbers we can't go back.  So Evolution 4.0 is off the table.

  I do still find the year-based numbering appealing: Evolution 2014.x,
  etc., since there's no major version number to set false expectations
  for a project that does incremental improvements.  And users would be
  more aware of how old of a release they're using, instead of it being 
  some arbitrary number.  And it removes the idiotic lesser version == 
  less mature mentality when comparing two unrelated projects.  I just
  can't figure out what to call the development snapshots.

* I think our policy toward stable branch maintenance could be a little
  more relaxed during the first half of a release cycle in terms of what
  we allow in.  I don't know what that means exactly for us yet, but I
  have observed RHEL updates do sometimes include new features.  Maybe
  enterprise policies could be a rough guide until we find our footing.

* I like Milan's idea of publishing our own release schedule as an .ics
  file, as in http://www.gnome.org/start/unstable/schedule.ics.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Reconsidering our release cycle

2013-07-23 Thread Matthew Barnes
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 landing major changes and allowing adequate time for
testing before development freezes set in.

But more importantly, our users seem to be constantly playing catch-up
in terms of supported releases.  Because of the delay between upstream
releases and distro releases, by the time users finally upgrade to a
newer Evolution, more often than not they're upgrading to a version
that's either nearing the tail end of its 6-month support window or is
already unsupported.

That's frustrating, both for users and for me as a developer, but we
just don't have the manpower to support multiple stable releases and
still get any kind of significant development work done.

I'd like us to consider moving to a 12-month release cycle, which would
sync up with GNOME's release schedule annually instead of semi-annually.

Here's my initial proposal, if you guys are open to this:

* Continue with the 6-month releases through the end of the year, just
  because I think we need more lead time for such a major policy change.

* Bump Evolution's major version number to split away from GNOME's
  semi-annual release numbering.  Call the upcoming March 2014 release
  Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas).

* We would follow GNOME's string change announcement and freeze schedule
  in the months leading up to each March release.

* We would continue releasing stable updates and development snapshots
  at a steady pace.  Our release schedule could even be more predictable
  than it is now.  We could do, for example, stable releases on the 1st
  Monday of each month and development snapshots on the 3rd Monday.

Obviously there's more details to figure out, but I like the precedent
we've set with the 3.8 branch, and I think our users appreciate it too.

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 and to see their bugs fixed without
waiting half a year.

It's just an idea.  What do you guys think?

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Running evolution 3.10

2013-07-08 Thread Matthew Barnes
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 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


Re: [Evolution-hackers] (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.

2013-06-24 Thread Matthew Barnes
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 **: GError set 
 over the top of a previous GError or
 uninitialized memory.
 
 As information,
   i happened to notice this this morning.
 
 (evolution:30823): GLib-WARNING **: GError set over the top of a previous
 GError or uninitialized memory.
 This indicates a bug in someone's code. You must ensure an error is NULL
 before it's set.
 The overwriting error message was: Error executing filter search: Failed to
 retrieve message:  (and
   
   (match-all (= (pipe-message /bin/sh -c
   /home/rthompso/bin/catrootmail) 35))
 
   )
 
 
 Reid
 
 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 https://mail.gnome.org/mailman/listinfo/evolution-hackers
 
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.

2013-06-24 Thread Matthew Barnes
 $ 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:  7753 Trace/breakpoint trap   (core
 dumped) $prefix/bin/evolution-env $prefix/bin/evolution $@ 
 $logdir/evo.log.$i 21
 
 
 2) if I get past 1, if I can re-create the initial error.

Type continue (or just c) in gdb.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Crashes on webkit-composer Branch - even outside if composer?

2013-06-02 Thread Matthew Barnes
On Sun, 2013-06-02 at 23:19 +0200, Joey 4712 wrote:
 when buildiing Evolution from branch webkit-composer on Arch Linux it
 crashes after running for about 20 seconds to 2 minutes.

That branch is a work-in-progress and should not be used other than by
the developers working 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-hackers


Re: [Evolution-hackers] Backporting EWS GAL changes to 3.8

2013-05-30 Thread Matthew Barnes
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 been released a week or two ago.
 
 As part of that process, the libmspack maintainer spotted a number of
 bugs in our changes. These have all been fixed in the 0.4 release.
 
 I've fixed the build in master so that we either need to build with
 libmspack 0.4 as an additional dependency (recommended), or use a
 configure option to build with our internal version of the decompression
 code instead. If you configure without an appropriate libmspack, the
 resulting error will tell you about the --with-internal-lzx option.

That's the right way.

A two week-old release is far too new for a stable branch dependency,
especially one we're introducing mid-stream.  It needs to be optional
for now, but at the same time we do want packagers to be aware of it. 
Aborting the configure script by default with a workaround message if
libmspack 0.4 is not present accomplishes that.

We're giving special attention to the stable release this cycle, so I'm
willing to bend the rules a bit.

+1 from me.

I think we could remove the internal lzx copy as early as 3.11.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Colon is a show-stopper.

2013-05-17 Thread Matthew Barnes
On Fri, 2013-05-17 at 11:01 -0400, Mark Filipak wrote:
 Here is a typical message file:
 
 ~/.local/share/evolution/mail/local/cur/1365462216.8388_1.Iris:2,S
 
 Can I persuade Evolution to use some other character in lieu of the colon? 
 This 
 is very important to me... it's a show-stopper.

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://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] crash in 3.8.2

2013-05-12 Thread Matthew Barnes
On Sun, 2013-05-12 at 16:37 -0300, Sasa Ostrouska wrote:
 Fontconfig warning: /etc/fonts/conf.d/44-wqy-zenhei.conf, line 11:
 Having multiple values in test isn't supported and may not work as
 expected
 
 (evolution:11746): Gdk-ERROR **: The program 'evolution' received an X
 Window System error.

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/listinfo/evolution-hackers


Re: [Evolution-hackers] Build failures the past several days

2013-04-18 Thread Matthew Barnes
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 branches.

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Build failures the past several days

2013-04-17 Thread Matthew Barnes
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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] EDS 3.8.1 build problem

2013-04-14 Thread Matthew Barnes
On Sun, 2013-04-14 at 15:56 -0300, Sasa Ostrouska wrote:
 Hi, I'm trying to upgrade my evolution from 3.6.x to 3.8.x and I get
 the build brake at the tests.

Old build artifacts, most likely.  A clean rebuild should fix it.

The functions it claims it can't find are right here:
https://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/evolution-hackers


Re: [Evolution-hackers] Leaving debug symbols in

2013-04-11 Thread Matthew Barnes
On Thu, 2013-04-11 at 13:41 -0700, Bob Purvy wrote:
 How do I keep the symbols from getting removed on 'make install' ?
 I'm using 2.4.2.1, which I know is way old, but I have to use it for
 reasons you don't want to know.

Add -g to your CFLAGS environment variable and rebuild everything.

http://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


Re: [Evolution-hackers] Leaving debug symbols in

2013-04-11 Thread Matthew Barnes
On Thu, 2013-04-11 at 14:41 -0700, Bob Purvy wrote:
 I've watched the C compilations go by, and -g is already in the flags.
  If I look at shell/.libs/evolution, it's got symbols in it.  The
 problem is that make install strips them.

Hmm, don't know then.  Only make install-strip is supposed to do that.

I guess check your Makefile that INSTALL is not being defined with -s.

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


Re: [Evolution-hackers] Distinguish interactive and non-interactive EClient-s

2013-03-21 Thread Matthew Barnes
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 added a boolean property 'interactive-mode' to
 the client. Maybe it can replace the flag in the e_client_open() call
 completely.

It's not really the client or even the client connection which owns the
mode, but rather the backend.  The backend can only operate in one mode
at a time, since it authenticates or sets up a secure TCP connection on
behalf of _all_ clients.

I'd suggest a scheme were the client connection can provide the backend
with some sort of token which gives the backend permission to interact
with the user for as long as that connection is open.

When I was working on Ubuntu Online Accounts I learned their signond
system used an enum they called UiPolicy which I found appealing.

https://code.google.com/p/accounts-sso/source/browse/lib/SignOn/sessiondata.h?repo=signondname=2.4#58

If we rank a similar set of UI policies according to a desired
precedence, perhaps like:

NO_USER_INTERACTION_POLICY   (lowest precedence)
ALLOW_NOTIFICATIONS_POLICY
ALLOW_MODAL_DIALOGS_POLICY   (highest precedence)

then the backend could act according to the token with the highest
precedence.

(ALLOW_NOTIFICATIONS_POLICY could simply submit a hey, this needs your
attention! desktop notification in lieu of a dialog, perhaps with an
action button that would allow further user interaction.)

So for example, if a client submits an ALLOW_NOTIFICATIONS_POLICY token
to a backend that only previously had NO_USER_INTERACTION_POLICY tokens,
then the backend may now submit a desktop notification if it fails to
authenticate or establish a secure TCP connection.

If another client comes along and submits an ALLOW_MODEL_DIALOGS_POLICY
token to that same backend, the backend would then be allowed to act as
it does currently, for as long as it has that token.

Does that make sense?

Submitting these tokens could be a new EClient method, so we don't have
to hack the existing API.  Then it's just a matter of tracking tokens on
the server-side, which I'm sure is not too difficult.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] gnome-3-8 branches created

2013-03-17 Thread Matthew Barnes
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 or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Restructuring direct access mode

2013-03-15 Thread Matthew Barnes
I'd like to restructure the new direct access mode for address books a
bit for Evolution-Data-Server 3.9.1.

Tristan's client-side implementation looks to me like it really wants to
be a subclass.  It basically intercepts and overrides entire EBookClient
methods with its own behavior, which is what subclasses are for.

Unfortunately we never anticipated a need for subclassing EBookClient or
ECalClient, and they currently lack overridable method pointers in their
class structures.

I suggest we suffer an ABI bump and correct this for 3.9.1.  It's a bit
of a backward-compatibility break for anyone already using this feature,
but better to make the course correction now while it's still relatively
fresh, as it will only get harder to fix with time.


Specifically:

* Flesh out EBookClientClass and ECalClientClass definitions with
  synchronous and asynchronous method pointers, similar to what we
  already have in Camel.  Also insert plenty of struct padding for
  future expansion, while we're at it.

* Split direct access into EBookDirectClient and EBookDirectClientView
  subclasses.

* Repurpose the e_book_client_connect_direct_sync() function to
  instantiate and configure an EBookDirectClient.

* Split the direct mode APIs into a new library: libebook-direct

* And finally revert the awkward libebook / libebook-contacts split,
  which I doubt anyone will notice.


That would give us a more straight-forward dependency chain:

   libebook - libedata-book - libebook-direct


I already have this partially prototyped, and it's passing the test
suite, so I'm confident it will work.

To help ease the transition from 3.8 to 3.10, we could add a fake
libebook-direct.pc file to the gnome-3-8 branch, which would just
require libebook.pc.

There's still time to get the libebook-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/evolution-hackers


Re: [Evolution-hackers] Gnome Evolution installation error

2013-03-09 Thread Matthew Barnes
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 ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Code help required for evolution hung opening meeting invitation

2013-03-04 Thread Matthew Barnes
On Sat, 2013-03-02 at 18:21 +0530, Samarjit Adhikari wrote:
 If you have any intuition  why this problem is happening , do let me
 know. I shall look into the code and try to fix it.

Looks like you're running into a known GObject deadlock.

https://bugzilla.gnome.org/show_bug.cgi?id=674885

We 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


Re: [Evolution-hackers] Isolated unit test status report

2013-02-24 Thread Matthew Barnes
On Sat, 2013-02-23 at 23:38 +0900, Tristan wrote:
 This indicates that somewhere, in the client or server, we
 are leaking references to the GDBusConnections. I've tested
 this in raw GIO (and added a test case there) to ensure it
 is indeed possible to stop/start the GTestDBus between tests,
 the problem is clearly an ugly bug to be fixed in EDS.

I suspect this might be related to the factory proxy object that we
create in the background and leave lying around as a global variable.

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 the GDBusConnection leak (if my guess is right).

I'll prototype this for 3.9.  I think I've pulled enough D-Bus stunts
for one release already.


 This is due to a race condition in e_client_remove_sync(),
 this call is made at the end of a test case.. which results
 in the ESource being removed from the ESourceRegistry server.
 
 What happens when the cache-reaper module is loaded, is that
 the 'test-address-book' source is removed /some time after/
 e_client_remove_sync() completes... sometimes this happens
 right in the middle of the following test case.

Probably another side effect of (A).

In the interim, it might help if the ESource's unique ID were actually
unique for each test case, instead of a static ID for all cases.

Instead of test-address-book use test-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/listinfo/evolution-hackers


Re: [Evolution-hackers] Isolated unit test status report

2013-02-24 Thread Matthew Barnes
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 the GDBusConnection leak (if my guess is right).
 
 I'll prototype this for 3.9.  I think I've pulled enough D-Bus stunts
 for one release already.

Okay I lied.

Prototyped code works fine, it eliminates a good amount of unnecessary
complexity and is embarrassingly obvious in hindsight.

I went ahead and committed it for 3.8.

We'll see if this has any impact on the GDBusConnection leak, but it's
an improvement regardless.

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


Re: [Evolution-hackers] Proposing date for the final 3.6.4 release

2013-02-21 Thread Matthew Barnes
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, which is not yet.
 
 Opinions?

That date sounds good to me.  I'll add it to the wiki.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Might be a generic ESourceExtension useful?

2013-02-05 Thread Matthew Barnes
On Tue, 2013-02-05 at 08:51 +0100, Milan Crha wrote:
 After a little discussion with tristan on IRC, not a generic
 ESourceExtension, but an API added directly to ESource, similar to
 property API on the old source.

Those arbitrary string properties from the old ESource API are precisely
what I wanted to AVOID by introducing ESourceExtensions.

The point of ESourceExtensions was to:

- Break settings into logical groups.

- Document what each setting is for, its data type and default value.

- Keep common settings consistent in name/type/default across backends.

The code duplication 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 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


Re: [Evolution-hackers] ESourceExtension and backends... claimed generic property ?

2013-02-05 Thread Matthew Barnes
On Tue, 2013-02-05 at 17:22 +0900, Tristan Van Berkom wrote:
 Would it make sense to include some property on the base
 ESourceExtension class ?
 
 For instance, an api such as 'e_source_extension_claim()' could
 be introduced and called by the consumer of the given extensions.
 
 I.e. the file addressbook backend would claim the
 ESourceBackendSummarySetup extension... clients (those clients
 which actually created the backend), would then be able
 to read this claimed property back after creating the addressbook.

That seems to me like an awfully obscure corner case to justify adding
APIs 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/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] ESourceExtension and backends... claimed generic property ?

2013-02-05 Thread Matthew Barnes
On Tue, 2013-02-05 at 23:00 +0900, Tristan Van Berkom wrote:
 I know, we've discussed this already a few months ago, it just
 seems like something essential to the extension API, you
 tell the backend to do foo and you just don't know if that
 backend knows about foo (yet) or not.

Seems like that could be mitigated by the backend capabilities property,
which -- at least for static capabilities -- should be reachable through
the factory APIs and not require an actual backend instance.

The static capabilities of a given backend type are the same for all
instances of that type, if I'm not mistaken.  So it would make sense to
be able to query the factory for available backend types and their
respective static capabilities prior to instantiating one.

ESource and its extensions are meant to be just a dumb data container.
It's used for more than just backend configuration.

Mail signatures 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
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Planning for 3.10

2013-02-05 Thread Matthew Barnes
I started a planning page on the wiki for Evolution 3.10.

https://live.gnome.org/Evolution/Planning310

Feel free to pile on.

The feature list is not binding.  It's just to track what we'll have
cooking on the stove during the next development cycle.  If a feature
slips, it slips.  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-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] ESourceExtension and backends... claimed generic property ?

2013-02-05 Thread Matthew Barnes
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
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] ESourceExtension and backends... claimed generic property ?

2013-02-05 Thread Matthew Barnes
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 item, which let evolution's Contacts
 view know that it can do initial search, instead of claiming Search for
 Contacts. I hope it's still doable (I didn't check it), and as such it
 requires an instance of the EBookBackend descendant.

Sure.  It makes sense for backends to continue advertising their own
capabilities -- static and non-static like browsable.

I'm just suggesting a way to peek at a backend's known capabilities
ahead of time without having to instantiate it.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regarding API breakage and lost test cases

2013-01-31 Thread Matthew Barnes
On Thu, 2013-01-31 at 18:25 +0900, Tristan Van Berkom wrote:
 I'm not sure what the solution should be exactly, but we
 should discuss this a bit because the problem space is
 a little bigger than just the source existing in the
 client-side before e_source_registry_commit_source_sync()
 returns.

Note that e_source_registry_commit_source_sync() is just a convenience
wrapper.  If your test cases are just passing scratch sources then what
you're actually calling is e_source_registry_create_sources_sync().
That's the function I fixed in bug 685986.


 So I guess there are 2 potential ways of addressing this problem:

There's a 3rd approach.

If you want an immediate client connection to a newly created address
book, we could have evolution-addressbook-factory create the ESource on
your behalf -- since it too has an ESourceRegistry -- and immediately
instantiate a backend for it.  That would eliminate the race without
resorting to client-side hacks.

It would require a new method on the addressbook and calendar factory
interfaces, but that is easily done now that all our D-Bus interfaces
are generated from XML specifications.  That was the purpose of my
recent rash of commits to master.

Just this week I added e_book_client_connect_sync(), which combines the
now-deprecated e_book_client_new() and e_client_open_sync() functions
into one step.

I could enhance this function to detect whether the given ESource is a
scratch source, and invoke a different factory method which behaves as
described above.  No additional client-side APIs required.


To summarize:

The current addressbook factory D-Bus API looks like this:

   method name=OpenAddressBook
 arg name=source_uid direction=in type=s/
 arg name=object_path direction=out type=s/
   /method

It only works for existing ESources already exported by the registry.

I'm proposing to add a new method that takes the raw key file content
from a scratch ESource in addition to a UID:

   method name=CreateAddressBook
 arg name=source_uid direction=in type=s/
 arg name=source_data direction=in type=s/
 arg name=object_path direction=out type=s/
   /method

Invoked by passing a scratch source to e_book_client_connect_sync().

The factory method would call e_source_registry_commit_source_sync() on
your behalf, and assuming that goes well, return the object path to its
newly-created EBookBackend.

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


Re: [Evolution-hackers] Confusion between EServerSideSource's remote-deletable and removable properties

2013-01-17 Thread Matthew Barnes
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.

Removable is for simply deleting the local key file.  This is handled
directly by the ESourceRegistryServer.

Remote-Deletable is for deleting a remote resource represented by the
ESource.  It requires the ESource be owned by a collection backend, and
only after the remote deletion is successful is the local key file
deleted.

On the client-side we probably should have separate GtkActions for
deleting a local ESource versus permanently deleting a remote resource,
so they can at least be labeled differently (e.g. Delete Calendar vs.
Delete Remote Calendar) since no one reads warning dialogs.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Any experience with GCC code coverage (gcov) for Evolution

2013-01-16 Thread Matthew Barnes
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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Redundant type casts in the evolution* code

2013-01-14 Thread 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.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] What happened to email-factory?

2013-01-05 Thread Matthew Barnes
On Fri, 2013-01-04 at 20:58 +0200, Mehmet Giritli wrote:
 I was looking forward to have the email backend moved into EDS so that I
 can write a proper mail notification UI for gnome. But I noticed that
 the branch here https://github.com/sragavan/e-mail-factory was never
 merged and I can no longer see it among the future plans. So I am a
 little curious what happened to this project? Has it been dropped
 entirely?

Good question.  I'd still like to see it happen, but I haven't heard
from Srini in several months and our architecture has changed greatly
since the last commit on that repo.  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
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Building Evolution Data Server under GNOME 3.4: GWeather requirements

2013-01-04 Thread Matthew Barnes
On Fri, 2013-01-04 at 12:32 +0100, Paul Menzel wrote:
 Matthew stated that it is a goal to ensure that Evolution Data Server
 and Evolution build under GNOME 3.4.
 
 GWeather does not seem an important component, but it would be nice
 anyway, if that would build under GNOME 3.4 too so packages scripts do
 not have to be changed and functionality is on par.

Yes, I resisted requiring the new and at the time unstable GWeather API,
insisting we support both the old and new GWeather APIs for at least one
release cycle.  But the requirement got bumped anyway.  I let it slide
since GWeather 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 options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [PATCH] shell/e-convert-local-mail.c: Pass correct enum `e_account_find_t` to `e_account_list_find()`

2013-01-03 Thread Matthew Barnes
On Thu, 2013-01-03 at 16:15 +0100, Paul Menzel wrote:
 Date: Wed, 2 Jan 2013 12:16:50 +0100
 
 Clang 3.2 reports the following warning.
 
 $ clang --version
 Debian clang version 3.2-9 (tags/RELEASE_32/final) (based on LLVM 3.2)
 $ CC=clang ./autogen.sh
 $ make
   CC evolution-e-convert-local-mail.o
 e-convert-local-mail.c:275:37: warning: implicit conversion from 
 enumeration type 'enum _e_account_item_t' to different enumeration type
   'e_account_find_t' (aka 'enum _e_account_find_t') [-Wconversion]
 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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [Evolution] infrastructure

2012-12-29 Thread Matthew Barnes
Hi Tom,

I'm transferring this topic to the hackers list, so as not to stir up
endless discussion on the user list.


On Sat, 2012-12-29 at 17:11 +, Tom Davies wrote:
 At the moment i get the impression that Evolution gets used on a lot
 more platforms and DE's than just Gnome.

That's always been the case but probably more so nowadays, given how
fragmented the free desktop space has become.  I myself am doing most
of my Evolution development on XFCE, using virtualization as needed.


 Is it technically possible to move the project under a different
 umbrella?

Technically possible, yes.  But a HUGE pain in the ass.  Especially the
bug database.  There's at least 12 years of valuable project history in
there.  I would not want to endure the pain without a compelling reason,
and at the moment I see none.

Our hosting on gnome.org is a marriage of convenience.


 Would it make sense to move to The Document Foundation (TDF)?
 At the moment TDF only have 1 product (LibreOffice (LO)) and
 all the Board and everything is geared only to that.

I dunno, sounds to me like we'd be crashing the party.

Without an invitation from TDF, no it would not make sense.


 Would there be any scope for attracting some of their devs to work on
 Evo rather than some of them just doing a little bit on LO and then
 vanishing off into the ether?

Not sure I understand the question.


 I just wondered if anyone here had thought about repositioning Evo
 strategically?

I guess that would first 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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Move backup/restore to evolution-source-registry?

2012-12-20 Thread Matthew Barnes
As much as I wish we could be rid of it, many Evolution users still rely
on our backup/restore feature for things it was not intended for such as
system upgrades.  So I'll concede the feature is probably here to stay,
at least for the foreseeable future.

It seems not only messy but risky for Evolution to be handling backups
and restores though.  Evolution itself may shut down before initiating
the operation, but the E-D-S services remain running the whole time,
potentially writing to the directories being backed up or restored.

It occurred to me that the backup/restore feature could be made cleaner,
safer and more reliable by converting the implementation in Evolution to
an evolution-source-registry module and exporting a D-Bus interface for
initiating a backup or restore.  (The evolution-backup tool would still
handle the UI bits, just not do any actual work itself.)

When initiating a backup or restore, the registry module could first
unexport all data sources, which would effectively shut down all the
backends since they'll see it as a source-removed signal.

While the backup or restore is running (in-process, not by spawning a
separate tool), the registry server could be placed in a busy state
such that any subsequent D-Bus method invocations would be denied with
a G_IO_ERROR_BUSY response.  Meanwhile, the backup/restore module could
report progress back to the requesting client.

When the backup or restore is finished, the registry server would
immediately reboot 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@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Is it worth customizing the IMAP headers to fetch?

2012-12-20 Thread Matthew Barnes
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 to follow up, in the interest of decommissioning the legacy IMAP
backend in time for 3.8, I've decided not to support the imap-features
plugin in IMAPX.  The plugin will be removed along with the legacy IMAP
backend, and for the time being we'll continue downloading all headers.

Shortening the download time by minimizing the headers is a worthwhile
goal, but I think we first need to better utilize server-side searches.

I'm already working on server-side BODY searches for IMAPX, but I also
think we should utilize server-side HEADER searches.  Then the success
of a search/filter rule that specifies a particular header is decoupled
from the set of headers we choose to cache.  (This can be optimized in
various ways obviously, but the point is to not _depend_ on our cache
for correct results.  Let the server do the heavy lifting.)

Maybe we can do something along these lines for 3.10...

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


Re: [Evolution-hackers] Is it worth customizing the IMAP headers to fetch?

2012-12-15 Thread Matthew Barnes
On Sat, 2012-12-15 at 19:00 +, David Woodhouse wrote:
 The interesting use case, perhaps, is the first run of Evolution on a
 new mail store. That's when the full vs. targeted header fetch is going
 to be most noticeable. 

Right, and since we don't even present these IMAP header options in the
account setup wizard, the user doesn't even have a chance to monkey with
them until the initial fetch begins.  You have to wander back into the
account settings to see that page, and by then your headers are probably
all fetched.


 But even if we conclude that the more specific fetch is worthwhile, I'm
 still not convinced that a separate UI for *choosing* those headers is
 at all sane. If the user sets up filters which *look* at a given header,
 then we damn well ought to fetch that header automatically. The user
 shouldn't be forced to go and find a separate plugin to make their
 filter actually work. Or do I misunderstand how this works?

No you're right, I think that's the sole purpose of the Custom Headers
section.

What I'm taking away is there may be value in fetching specific headers,
but not in it's present form.  So I'm inclined to drop the plugin, but
leave open 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/listinfo/evolution-hackers


Re: [Evolution-hackers] mail migration

2012-12-14 Thread Matthew Barnes
On Fri, 2012-12-14 at 04:54 +0100, Sasa Ostrouska wrote:
 I have about 5Gb of e-mails on my laptop which I use for work, and it
 is still on evolution 2.26.3.
 I would like to migrate now this stuff to evolution 3.6.x
 
 What is the best way to do that ?

Hi Sasa,

While Evolution does try to automatically migrate data when necessary
after upgrading, this is intended more for incremental upgrades, say
from 3.4 to 3.6.

Automatic data migration becomes less tested and therefore more risky
the more versions you skip.  Going from 2.26 to 3.6 is a huge leap!

I recommend breaking the upgrade into at least two steps, particularly
2.26 - 3.0 - 3.6.

Evolution 3.0 was the first version to convert your local mail from mbox
format to Maildir format.  Do that first, and once you verify your local
mail is in tact, proceed to 3.6.

Evolution 3.6 was the first version to convert your account info 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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution library consolidation

2012-12-13 Thread 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 from my point of view. I guess making 
eutil/menus
eutil/table
...
 as static libraries, linked into one libeutil.so would work pretty well
 too, with an advantage of sorted code.

The old partitioning is still reflected in the API documentation.  I
don't see anything messy about having the source files in a flat list.
GTK+ is able to manage its widgets well enough with a similar layout.

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution library consolidation

2012-12-12 Thread Matthew Barnes
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 installation and rebuilding all Evolution-related modules from
scratch to avoid interference from now-defunct libraries.

Also check out the new libeutil API documentation.  I'm still populating
the libeutil-sections.txt file but I hope to complete it by month's end.

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


Re: [Evolution-hackers] Evolution library consolidation

2012-12-09 Thread Matthew Barnes
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-composer branch is not quite as ready to merge as I
thought, and I'd like to get the library consolidation done before it
gets any later in the development cycle, I'm going to proceed with it
now and I'll just adapt Dan's branch to the changes myself.

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.

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


Re: [Evolution-hackers] API considerations for avoiding data loss in race conditions

2012-12-06 Thread Matthew Barnes
On Thu, 2012-12-06 at 16:22 +0100, Christian Hilberg wrote:
 * EClient starts transaction / acquires lock on PIM
   entry
 
 * E-D-S records transaction start / gives away the PIM
   entry lock to the EClient requesting
 
 * EClient dies for any reason
 
 * Started transaction / aquired PIM lock persists in
   E-D-S
 
 What now? Timeout after some time? Welcome back to possible
 raciness (--does not truly solve our problem).

This scenario is easily handled by watching the bus name of the client
process that acquired the lock.  If the bus name vanishes, release the
lock immediately.

But we have no such transaction lock at present, do we?

Matt

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Evolution library consolidation

2012-11-27 Thread Matthew Barnes
I'm currently smoke testing Dan's webkit-composer branch before giving
him the go-ahead to merge it to master.

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.

I'm also going to absorb libedataserverui back into Evolution, since
Evolution is now the only module using it (I've done my due diligence on
other modules that still show a dependency -- in most cases it was just
a historical artifact that could be dropped).  So all the non-deprecated
APIs in libedataserverui will become part of Evolution's new libeutil.

I plan to have this in for Evolution 3.7.3.

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  (new in Dan's branch)
   widgets/menus/libmenus.so
   widgets/table/libetable.so
   widgets/text/libetext.so
   libedataserverui/libedataserverui.so (from E-D-S)

At least, that's the list for starters.  I'd still like to keep things
like libemformat.so, libcomposer.so and libeshell.so separate.  I'm on
the fence about the smime libraries.

Additionally, since almost all the #include paths will need updating
anyway, I'm going to move libeutil to a single-include model like we've
done for Camel and E-D-S.  In addition to convenience, it helps shield
3rd party apps as well as our own extension packages from quite so much
API churn, even though we still make no guarantees about API stability
in Evolution libraries.

The new #include directive for libeutil will be

   #include libeutil/libeutil.h

which will bring in all headers 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 mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution slowing down

2012-11-27 Thread Matthew Barnes
On Tue, 2012-11-27 at 18:59 +, Karl Relton wrote:
 Is it just me, or is evolution 3.6 now really slow. I find opening and
 closing message windows markedly slower than 3.2 on the same hardware.

Probably just you, since I've not seen any such slowdown.  If anything,
rendering is much faster now with the move to WebKit.

One possibility is your mail summary database has accumulated a lot of
cruft and needs garbage collected.  Unfortunately we don't yet run this
automatically so it has to be done manually.  Eventually I'd like to tie
it into Folder - Expunge and File - Empty Trash.

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://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution library consolidation

2012-11-27 Thread Matthew Barnes
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  (new in Dan's branch)
widgets/menus/libmenus.so
widgets/table/libetable.so
widgets/text/libetext.so
libedataserverui/libedataserverui.so (from E-D-S)

Addendum: Forgot to list an obvious and important one:

   widgets/misc/libemiscwidgets.so

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UI interaction from book/calendar backends

2012-11-27 Thread Matthew Barnes
Yes, the gtk_init() issue occurred to me after posting that suggestion.  I 
agree a separate process is the better idea.  Then gtk3 won't taint 
evolution-source-registry.

(Apologies for top-posting.  I'm trying out Dan's webkit-composer branch and it 
seems to have some kinks yet to be worked 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 if
the Tizen folks don't want it, or they want to implement their own
version using Qt.

Hi,
I was thinking of it, and I feel like it's not correct to initialize gtk
within an extension, thus this should be just a new server within eds,
with its default implementation using gtk3, which will be accessed
through DBus (as you suggested), thus will be replaceable by other
implementations.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers




___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Drop or limit ChangeLog files in tarball releases?

2012-11-22 Thread Matthew Barnes
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 we ship is our tarball releases, not
our version control system, so there's an argument to be made that we
should ship a complete log of changes in our product updates.

That said, the GNU Coding Standards were written in an age before
distributed version control, and its relevance is debatable nowadays.
And I agree 'git log' is more practical for researching change history.

We could limit the log to changes since the last major release (3.6.0
currently, then start clean after 3.8.0 ships) to keep the file size
under control, but if you'd strongly prefer dropping it entirely then I
won't complain.

Also, just for the record, the script snippet I'm using to generate the
ChangeLog file comes from https://live.gnome.org/Git/ChangeLog.

Matt


[1] http://www.gnu.org/prep/standards/html_node/Change-Logs.html


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UI interaction from book/calendar backends

2012-11-22 Thread Matthew Barnes
On Thu, 2012-11-22 at 09:13 +0100, Milan Crha wrote:
 What I have on mind is something what Camel already provides [1], the
 camel_session_alert_user() function, which basically provides generic
 dialog facility for asking users. The question is where to put such
 functionality for book/calendar backends, because they are
 client-oriented, not session oriented like providers in Camel. It would
 not work to teach each client, and also user of the client, about this
 interaction, thus I think the right place is evolution-source-registry,
 which already requires gtk. This can be hidden on the backend side by
 some base class function e_backend_alert_user(), and where it'll pass
 the data is up to it. Note this is not used for random errors, for that
 is other e_cal/book_backend_notify_error() function, which will be left.

Actually I don't think evolution-source-registry requires GTK+.  If it's
the password dialog you're thinking of, we only link to gcr-base-3 which
speaks via D-Bus to the process actually showing the password dialog.

I'm not sure if evolution-source-registry is ultimately the right place
for user interfaces, but I can't think of a better solution at present.

I have a few requests, though:

1) Write this as a ESourceRegistryServer extension, and just link to
   GTK+ from the extension module.  That way it's easily removable if
   the Tizen folks don't want it, or they want to implement their own
   version using Qt.

2) Create a new well-known bus name for this.  Perhaps something like

  org.gnome.evolution.dataserver.Prompts

3) Come up with a corresponding D-Bus interface, put the XML spec in
   the private directory and let gdbus-codegen create the GDBus glue.

The idea here is to keep the functionality relocatable, both for the
benefit of Tizen and for ourselves if we think of a better place for
this stuff in the future.

Matt



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded

2012-11-13 Thread Matthew Barnes
On Tue, 2012-11-13 at 11:18 +0100, Christian Hilberg wrote:
 My question now (for documenting the status quo) is whether anyone
 is currently working on getting certificate-based client authentication
 utilizing a TPM flying in Evolution for OpenLDAP+GnuTLS at present
 or whether there are any plans to support this use case in the
 near future.

No one is working on it at the moment, and I don't see it being
supported in the near future without sufficient demand or external
contributors.

I can't speak for Milan, but for me it's more ignorance in this area
than objection or lack of interest.

I will say that I'd like to see Evolution (Camel in particular) stop
talking directly to NSS and defer certificate management to the various
security libraries and APIs in the GNOME platform -- p11-kit, libgck,
GTlsCertificate in libgio, etc.  We haven't even begun to utilize these
libraries yet (except perhaps through libsoup), and I sense there's a
lot of redundancy in our code that could be eliminated by doing so, not
to mention automatically gaining more consistent and probably improved
behavior.  But not yet being very familiar with these libraries, at
present I can only make hand-wavy 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-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] What do I need to add/enable/remove re @GNOME_CODE_COVERAGE_RULES@ so that compilation will not stop on 'Makefile:1097: *** missing separator. Stop.'

2012-11-02 Thread Matthew Barnes
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
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regarding ESource and ESourceExtension

2012-10-08 Thread Matthew Barnes
On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote:
 Is it intended that the frontend must know what extensions are
 supported by a given backend ?

What extensions are you worried about, specifically?  And what's the use
case for configuring them by hand?

This page explains which extensions are typically present in a given
type of key file: https://live.gnome.org/Evolution/ESourceFileFormat

The various config modules in Evolution [1] serve as configuration
backends for the account editor and the New Address Book and New
Calendar dialogs.  Each module knows what extensions 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://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regarding ESource and ESourceExtension

2012-10-08 Thread Matthew Barnes
On Mon, 2012-10-08 at 23:56 +0900, Tristan Van Berkom wrote:
 More specifically, I was under the impression that the
 ESourceExtensions were (at least partially) for the purpose of,
 well, extending the work flow and configurations provided by
 given backends.

Backend-specific settings live in a dedicated extension class for that
backend.  The key file groups are typically named [$FOO Backend].  You
can probably grep your own ~/.config/evolution/sources directory for
examples if you're running Evolution 3.6.0.

Not all backends currently have their own dedicated extension class.
I've been adding them as needed.  The local address book backend does
not yet, but the local calendar backend does:

http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/file/e-source-local.h

So we would add a similar class for the local address book backend to
hold the photo settings you mentioned.  (Some name juggling may have to
take place, since I unfortunately named the local calendar extension
merely Local Backend instead of Local Calendar Backend.)


Also worth noting is backends don't utilize all available extensions.  
Some extensions are only used to hold settings for client-side features,
and are disregarded by backends.  Some examples:

ESourceAlarms -- [Alarms]

  Apart from the configuration UI, this extension is used only by
  evolution-alarm-notify to determine whether to show notifications for
  a particular calendar and to record the timestamp of the most recent
  notification for that calendar.

ESourceAutocomplete -- [Autocomplete]

  Apart from the configuration UI, this extension is used only by the
  ENameSelectorEntry widget to decide whether to query a particular
  address book when attempting to complete a partial email address. 
  This widget is used in the To/Cc/Bcc fields of Evolution's email
  composer.

Another example -- for 3.8 I'd like to introduce per-account new mail
notification options for Evolution by moving the options currently under
Edit - Plugins - Mail Notification to the Account Editor window.  This
will involve introducing a new ESourceNotification extension, which mail
backends would disregard since Evolution itself handles notifications.


Now our configuration UI story is a bit awkward at the moment because
the backend-specific config modules I mentioned previously live in
Evolution.  But because the backend-specific ESourceExtension classes
are not included in libedataserver's public API (that's intentional),
those classes have to be duplicated in Evolution.

In the case of the local calendar backend extension I pointed out above,
that same code also lives in Evolution's cal-config-local module:
http://git.gnome.org/browse/evolution/tree/modules/cal-config-local/e-source-local.h

Obviously this code duplication is suboptimal, but at least there exists
a formal settings API now, whereas under the old GConf XML system it was
just an ad-hoc string dictionary.

I plan to address the code duplication issue by eventually moving the
whole configuration UI framework and all the config modules down to
Evolution-Data-Server.  Then at least the config UI modules and the
backend modules can live together and share the extension classes.

Not sure if this fully addresses your question or not.  I'm 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


Re: [Evolution-hackers] Regarding API breakage and lost test cases

2012-10-05 Thread Matthew Barnes
On Tue, 2012-10-02 at 20:35 +0900, Tristan Van Berkom wrote:
 Ah, this is gold.
 
 I'll be able to readjust things with this.

I've added a new section to the migration guide which covers the basics
of creating a new local address book or calendar:

https://live.gnome.org/Evolution/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/evolution-hackers


Re: [Evolution-hackers] Regarding API breakage and lost test cases

2012-10-05 Thread Matthew Barnes
On Fri, 2012-10-05 at 22:19 +0900, Tristan Van Berkom wrote:
a.) e_source_registry_commit_source_sync() seems not exactly
very sync. I haven't looked into that in detail but
surely the registry server needs to block on something else
before sending the reply.

The issue is on the client side in ESourceRegistry.  I had some pretty
nasty code at one time to deal with this but must have yanked it while
reworking the APIs.

Even after the remote method call completes, ESourceRegistry will still
have to stop and wait for an object-added signal from its internal
GDBusObjectManagerClient, which is running in its own isolated thread.
The object-added signal has the new GDBusObject needed to build the
new ESource instance.  And it can't complete on just any object-added
signal -- it has to be the object-added signal corresponding to the
scratch ESource that was just submitted.

I'll see if I can restore that nastiness again in 3.7.x.


However, the e-source-registry user facing APIs seem to make an
attempt at doing this internally (i.e. it has it's own thread
and mainloop presumably intended to handle the dbus messages as
a convenience to the caller), so... probably just a minor
detail or bug to fix there...

The GDBusObjectManagerClient only emits signals from the GMainContext
that was the thread-default at creation time.  So it's created in its
own dedicated thread to ensure its signal emissions cannot 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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Master branch is now 3.7.1

2012-09-17 Thread 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: https://live.gnome.org/ThreePointFive

Matt


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Master branch is now 3.7.1

2012-09-16 Thread Matthew Barnes
I released Evolution 3.5.92 and co. over the weekend and created
gnome-3-6 branches for the following modules:

gtkhtml
evolution
evolution-data-server
evolution-ews

So 3.7 development is now open on these modules.  Evolution 3.6.0 and
co. will be released from the gnome-3-6 branch.

I defer to Milan and Christian to branch evo-mapi and evo-kolab
respectively when they're ready.

Just a reminder that Milan and I will both be taking personal time off
for the rest of the month starting this week.

I'll still be somewhat reachable on IRC this Monday and Tuesday but
won't 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/evolution-hackers


  1   2   3   4   5   >