Re: [Evolution-hackers] Issue Building Flatpak version

2020-08-10 Thread Milan Crha via evolution-hackers
On Sat, 2020-08-08 at 17:42 -0500, Japhering, Anonymous via evolution-
hackers wrote:
>    flatpak --user remote-add --no-gpg-verify --if-not-exists
> evolution-repo localrepo
>    
> All of which,  appear to function and produce the expected results.
> 
> However,  when I get down to ..
> 
>    flatpak --user update org.gnome.Evolution-stable

Hi,
the application is called org.gnome.Evolution, not
org.gnome.Evolution-stable.

Try: flatpak list

> and if I try 
> 
>    flatpak --user install org.gnome.Evolution-stable

The command is incomplete, read the wiki page carefully. I had never a
problem when I used copy of the commands from that wiki you
referenced.

Try: flatpak remotes

By the way, if you use "continuous" update of your flatpak build, and
if you did it before Martin changes (whom renamed the repos and other
things), then it's possible your repo names do not match. You can check
the old versions/diffs here:
https://wiki.gnome.org/action/info/Apps/Evolution/Flatpak?action=info

Hope it helps,
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


Re: [Evolution-hackers] [PATCH] fix issue #895: "Time" portion of calendar entries not scaling with font

2020-07-27 Thread Milan Crha via evolution-hackers
On Sat, 2020-07-25 at 10:09 +0200, Stefan Paul Noack wrote:
> - fix clipping rectangle height:
>   was hard-coded to 14 before, now row_height is used
> 
> - (flat drawing style) fix clipping rectangle width:
>   text could be drawn outside the event rectangle, now clips
> correctly
> 
> - (rounded drawing style) scale the background pattern that separates
> the time portion from the body of the event:
>   calculation was broken, new method produces the same result
> for
> 96 DPI, but also works for larger values


Hi,
thanks for the patch. You do not need to resend it on multiple places,
attaching it to the bug [1], which you did, is sufficient. It's even
better track there, than here on the mailing list.

Of course, it's easier to be noticed when it's a merge request, but I
agree creating a merge requests adds some burden, which is not needed
for simpler changes. Let's continue in the bug [1].
Bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution/-/issues/895

___
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] Shedding some light on evolution-data-server's #ESourceRegistryWatcher

2020-04-20 Thread Milan Crha via evolution-hackers
On Sun, 2020-04-19 at 14:20 +0200, Juozas Miškinis wrote:
> Hey everyone!
> 
> I've been having some trouble trying to capture the "add/remove task
> list" events in evolution-data-server and I was hoping that you could
> perhaps clear some things up for me.
> 
> 1) Here's a barebone #ESourceRegistryWatcher implementation in gjs
> (returns no errors) which DOESN'T WORK (i.e. _onAppeared and
> _onDisappeared methods aren't executed upon task list
> addition/removal): https://paste.gnome.org/pboxc98jo 
> 2) Here's a similar WORKING approach that combines
> #ESourceRegistryWatcher and ESourceRegistry::source-added signal
> (which captures all types of #ESources): 
> https://paste.gnome.org/phr0crkit
> 
> The reason to combine them here is not clear to me, but without the
> watcher (i.e. if I removed line 27 in 
> https://paste.gnome.org/phr0crkit), registry.connect('source-
> added'...) wouldn't work either.
> 
> Here's my main question: is there anything obviously wrong with what
> I have in #1?

Hi,
I'm sorry I cannot help more, I do not speak gjs-ish, especially how it
works with respect of asynchronous calls, but I have few guesses, like
I'd rather use synchronous calls and make sure the variables you
assigned the instances to are not vanished during garbage collection.
Again, I do not know how gjs works and what it does with the GObject
introspection generated code.

I know that the ESourceRegistryWatcher works properly, it is used by
evolution-alarm-notify and some other parts of Evolution itself.

I'd also try to use C, to see whether it'll work, which may prove the
problem in the gjs code/usage, not in evolution-data-server itself.
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


Re: [Evolution-hackers] A probelm with evolution software 3.28.5-0ubuntu0.18.04.1

2019-12-04 Thread Milan Crha via evolution-hackers
On Wed, 2019-12-04 at 15:16 +0100, Régis Ramel wrote:
> Since I updated my computer from ubuntu 16.04 to ubuntu 18.04 and so
> updated the software evolution

Hi,
this looks like an evolution-list question, rather than
evolution-hackers. Also note, please, that 3.28.5 is very old, the
current upstream supported version series is 3.34.x.

> Appointments displayed on the monthly view of the calendar doesn't
> mention the appointments of the current day. So when you look at
> eleven in the morning for example, you don't see the appointments in
> the afternoon of the current day. You see only appointments beginning
> the day after.

As long as you've there enough space (the month view is very limited in
this regard), then I'd say there is something odd with your time zone.
Or with the timezone conversion between your timezone in
Edit->Preferences->Calendars and Tasks, and the timezone the respective
events are in. When you open for example the Day view, do the events
show properly there, at a correct time? Being it about time zones, I'd
be afraid that the issue might not be only in evolution or
evolution-data-server, but also in libical or tzdata. I cannot tell for
sure (see below).

> It's a regression which is really uncomfortable.
>
> It would be great if you could fix this problem.

It's likely that the current stable version has that fixed. If you can
give it a try somehow, then it'll be appreciated. As I did not notice
this with 3.34.x, I'd guess it is fixed, but more detailed information
is needed to know for sure. The worst case scenario (for you) would be
that the current version has it fixed, in that case you might need to
ask your distribution maintainer to backport relevant patches, because
the upstream doesn't package for all distributions out there, it's done
by respective distribution maintainers.

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


Re: [Evolution-hackers] Upcoming evolution-data-server API changes (libical-glib + more)

2019-09-16 Thread Milan Crha via evolution-hackers
On Sat, 2019-09-14 at 22:23 +0530, Victor Jonathon Calel via evolution-
hackers wrote:
> https://bazaar.launchpad.net/~victor-jon/indicator-datetime/drop-phone-code/view/head:/src/planner-eds.c
> 
> (It's bzr though. I can move into git if required.)

Hi,
no need for git, I only didn't work with bazaar yet, thus if you have a
command to download/checkout the branch, which I'd be able to configure
(using CMake, if I read it correctly) and build, then I can help you
with the port.
Thanks and 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


Re: [Evolution-hackers] [PGP] decrypt into local folder

2019-07-09 Thread Milan Crha via evolution-hackers
On Tue, 2019-07-09 at 12:25 +0200, J T via evolution-hackers wrote:
> I encrypt almost all my emails with PGP. This has several significant
> drawbacks:
> 1. Since I generate new private key every year, I need to keep track
> of all of them to be able to decrypt and look at my old emails. I
> don't like this. I want to archive old keys only for emergency
> purposes and have clean PGP keyring.
> 2. It is impossible to do searches over encrypted emails.
> 
> I think it would be nice to have option or message-filter 'Decrypt
> into (local) folder', where emails are kept decrypted.

Hi,
you can propose new feature requests at:
https://gitlab.gnome.org/GNOME/evolution/issues/new
though for the 1) I'm not sure how the UI would be done. A similar
option to "Send encrypted, but store decrypted in the Sent folder"
would make similar job, as both scenarios void the encryption purpose.

For the 2), there already exists an old report here:
https://bugzilla.gnome.org/show_bug.cgi?id=648774

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


Re: [Evolution-hackers] hang when attaching images (3.32.1-2)

2019-05-29 Thread Milan Crha via evolution-hackers
On Tue, 2019-05-28 at 18:08 +0200, Lukas Pirl wrote:
> Thanks for taking care, Andre. This is what I see for Evolution
> 3.32.2-1 (where the problem persists).

Hi,
it shows [1] that you do not have installed debuginfo packages for
whole evolution (and other related libraries), thus the backtrace is
not that useful as it could be. Nonetheless, it shows that evolution is
waiting for the gnome_desktop_thumbnail_factory_generate_thumbnail() to
finish, which comes from /usr/lib/x86_64-linux-gnu/libgnome-desktop-
3.so.17. Whether the problem is in this library or in the program it
calls to generate the thumbnail (which can eventually be specific to
your settings) I do not know and cannot guess.

> Is discussing traces actually better suited for evolution-list@…? If
> you think so, feel free to reply vie evolution-list@….

There's a bug tracker to discuss issues, it's much better than mailing
lists. It's okay to start discussion on a mailing list, because
sometimes the issues are known or unrelated to evolution itself. I
mean, there's no problem to start initial investigation on the mailing
list and turn it into a bug report later.
Bye,
Milan

[1] For the reference and easier searching, as the pastebin can expire:

Thread 1 (Thread 0x7fa98bc4c200 (LWP 28763)):
#0  0x7fa994fae037 in select () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fa997f05230 in g_spawn_sync () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fa9901fa2cb in gnome_desktop_thumbnail_script_exec () at 
/usr/lib/x86_64-linux-gnu/libgnome-desktop-3.so.17
#3  0x7fa9901e088e in gnome_desktop_thumbnail_factory_generate_thumbnail ()
at /usr/lib/x86_64-linux-gnu/libgnome-desktop-3.so.17
#4  0x7fa9951a9221 in e_icon_factory_create_thumbnail () at 
/usr/lib/evolution/libevolution-util.so.0
#5  0x7fa995138c96 in  () at /usr/lib/evolution/libevolution-util.so.0
#6  0x7fa997ebcdd8 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x7fa997ebd1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7fa997ebd4c2 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7fa998457b15 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x56489140cee4 in main (argc=, argv=) at 
./src/shell/main.c:676

___
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] Upcoming evolution-data-server API changes (libical-glib + more)

2019-05-17 Thread Milan Crha via evolution-hackers
On Fri, 2019-04-12 at 08:47 +0200, Milan Crha via evolution-hackers
wrote:
> this is kind of heads-up e-mail about upcoming API changes in
> evolution-data-server.

Hi,
just a notice that the changes landed for the 3.33.2 development
version. Some more info and history can be found in this [1] thread,
which split to May [2].
Bye,
Milan

[1] https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00016.html
[2] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00085.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] evolution failing on TLSv1.3 after gnutls upgrade

2019-05-16 Thread Milan Crha via evolution-hackers
On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote:
> gnutls Add support for timeouts on GnuTLS pulls
> 
> So if you apply that on top of 2.54.1, the test programme works
> again.

Hi,
do you see from the server logs whether the patched code tried TLS
v1.3, and then v1.2? I'm only wondering.

After re-reading the previous messages in this thread, you found that
the development version 2.55.2 works fine. As it's a development
version, the (usual) distributions may pick the stable version, 2.56.0
or later. Or they can find which patch fixed it between 2.55.1 and
2.55.2 and backport only that one (you referenced that change above).

Thinking of it, maybe it's a nonsense to ask them about the TLS version
downgrade on the fly. My "suggestion" would be over-complicated.

In any case, thank you for your time and help on this.
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


Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade

2019-05-13 Thread Milan Crha via evolution-hackers
On Mon, 2019-05-13 at 07:59 -0700, James Bottomley wrote:
> As for how to apply the fix (assuming we can find it), this is a hard
> one.  Clearly the bug was always present, but the conditions that
> trip it remained untested until people started turning on TLSv1.3.
> I think the best way forward is to open bugs with the distros and see
> what they want to do: Either find and fix the bug or update to 2.55.2.

Hi,
I see. That would work until a new version of the TLS is released and
implemented and advertised by the servers with clients which probably
know about it (due to new enough gnutls being installed, right?), but
its usage in glib-networking failing for whatever reason.

> Just to clarify, the server isn't requiring a particular version,
> it's offering a set of options and we're choosing TLSv1.3 which we
> then can't negotiate successfully, so the bug is client side but
> triggered both by the client going to a gnutls (or probably openssl
> but I can't test that) version that makes 1.3 possible and the server
> offering it as an option.

Oh, you are right, I'm sorry for misinterpreting it.

Maybe the glib-networking can be changed to try a lower version(s)
(when allowed to), when the best it thinks it can use fails with this
error (meaning if the server advertises TLS versions 1.2 and 1.3, the
client can try with 1.3 and if it fails, then retry with 1.2). I'd
expect such naive "solution" would work on the gnutls level
transparently though. I do not know gnutls, nor glib-networking, thus
this is really just a very naive idea.

Consider filling a bug against glib-networking [1] and ask them whether
they can do anything about it. You've a clear view what is going on in
the background, thus you'd be able to explain the problem to them. Feel
free to use the test program to your liking.

By the way, the openssl implementation for glib-networking is very new,
released as part of the 2.60.0, on March 11 [2].
Bye,
Milan

[1] https://gitlab.gnome.org/GNOME/glib-networking/issues/new
[2] https://gitlab.gnome.org/GNOME/glib-networking/blob/2.60.0/NEWS#L1

___
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 failing on TLSv1.3 after gnutls upgrade

2019-05-13 Thread Milan Crha via evolution-hackers
On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution-
hackers wrote:
> On Fri, 2019-05-10 at 23:23 +0200, Sasa Ostrouska via evolution-
> hackers 
> wrote:
> > Hi all, and thanks Milan for the program. I also run an old version
> > of evolution 3.20.x and I get the following:

Hi,
the more important is glib/glib-networking/gnutls version, than
evolution(-data-server) version. Sometimes also the system crypto
policy setting (/etc/crypto-policies/config on Fedora), though it works
the other way, it disables the old algorithms and "forces" use of the
newer, which can break connection against legacy servers.

> > rc@rc-laptop:~/Downloads$ gcc `pkg-config --cflags --libs glib-2.0
> > gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn
> > imap.googlemail.com 993
> > Connected to imap.googlemail.com:993
> > Failed to read data from the server: Error reading data from TLS
> > socket: The specified session has been invalidated for some reason.

The error is returned from gio/glib-networking and I agree it's not
obvious what it is about. Maybe it means that the current code doesn't
have new-enough implementation of the TLS. It looks like that, at
least.

> > I neded to #include  on my slackware linux.
>
> Me too, but it was a trivial update.

Hrm, weird, it might be probably due to that strlen() usage. No idea
what pulled it in here, that it didn't claim any issue on my side. I'm
sorry about that.

> I think the solution is to simply bar glib-networking below 2.55.2
> from using gnutls VERS-TLS1.3 which looks like it can be done
> reasonably well in g_tls_connection_gnutls_init_priorities()

There are some issues with it: a) the function is a private function, I
didn't find it in any of the header files under /usr/include/; b) it's
a very specific function, there's a branch to support also openssl in
glib-networking, where this would do nothing; c) getting such change
into an old evolution-data-server or glib-networking might be tricky,
especially with Long Term Support distributions; d) as Sasa showed (if
I understand it correctly), limiting TLS version may lead to rejected
connections on otherwise working system (it's when the server increases
TLS version requirement, but the "proposed change" would limit what can
be used).

That said, when the server requires recent TLS version, the users need
to update their system to also support such TLS version. It makes sense
(once one knows where the problem is, which I wasn't sure at all at the
beginning). Thank you James for all the testing and finding that out.
It's good to know that glib has it fixed already.
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


Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade

2019-05-10 Thread Milan Crha via evolution-hackers
On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> I can certainly test things out.

Hi,
that's great, thanks.

> To be honest, I've had problems with TLSv1.3 every time it's been
> negotiated, so disabling it is a reasonable thing to do.

I see. If you are still willing to help, then it'll be appreciated.

> I suppose there's no gntuls-cli equivalent for glib-networking?  That
> would be the best way to test it.

I agree, but I'm not aware of anything like that (which doesn't mean it
doesn't exist). I made a little test program as promised, see the
attachment. The first line contains a comment with a command to compile
and run it (against Google's IMAP server). It's only a test program,
mimic-ing what Evolution (or better Camel library from evolution-data-
server) does. You may have installed development packages for glib and,
if split, also for glib's gio, to be able to compile it.

Bye,
Milan

P.S.: The result of the run as is in the file itself is below:


$ ./imap-conn imap.googlemail.com 993

Connected to imap.googlemail.com:993
Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}

Request:  A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST 
CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN 
AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
A01 OK Thats all she wrote! {SOMETOKEN}

Request:  A02 LOGOUT
Response: * BYE Logout Requested {SOMETOKEN}
A02 OK Quoth the raven, nevermore... {SOMETOKEN}

/* gcc `pkg-config --cflags --libs glib-2.0 gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn imap.googlemail.com 993 */

#include 
#include 

static gboolean
read_stream_data (GIOStream *stream)
{
	GInputStream *input;
	gchar buffer[2048 + 1];
	gsize count;
	GError *error = NULL;

	input = g_io_stream_get_input_stream (stream);

	count = g_input_stream_read (input, buffer, G_N_ELEMENTS (buffer) - 1, NULL, );

	if (count == -1) {
		if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_TIMED_OUT)) {
			g_clear_error ();
		} else {
			g_printerr ("Failed to read data from the server: %s\n", error ? error->message : "Unknown error");
			g_clear_error ();
			return FALSE;
		}
	} else {
		buffer[count] = 0;
		g_print ("Response: %s\n", buffer);
	}

	return TRUE;
}

static gboolean
issue_command (GIOStream *stream,
	   const gchar *command)
{
	GOutputStream *output;
	gsize count, written = 0;
	GError *error = NULL;

	output = g_io_stream_get_output_stream (stream);

	count = strlen (command);
	if (!g_output_stream_write_all (output, command, count, , NULL, )) {
		g_printerr ("Failed to write command to the output stream: %s\n", error ? error->message : "Unknown error");
		g_clear_error ();
		return FALSE;
	}

	if (written != count) {
		g_printerr ("Wrote only %d bytes, instead of %d\n", written, count);
		return FALSE;
	}

	if (!g_output_stream_write_all (output, "\r\n", 2, , NULL, )) {
		g_printerr ("Failed to write command end to the output stream: %s\n", error ? error->message : "Unknown error");
		g_clear_error ();
		return FALSE;
	}

	if (written != 2) {
		g_printerr ("Wrote only %d bytes, instead of %d\n", written, 2);
		return FALSE;
	}

	if (!g_output_stream_flush (output, NULL, )) {
		g_printerr ("Failed to flush output stream\n", error ? error->message : "Unknown error");
		g_clear_error ();
		return FALSE;
	}

	g_print ("Request:  %s\n", command);

	return read_stream_data (stream);
}

static gint
run_connection (const gchar *host,
		gushort port)
{
	GSocketConnectable *connectable;
	GSocketConnection *connection;
	GSocketClient *client;
	gint ret = 0;
	GError *error = NULL;

	connectable = g_object_new (G_TYPE_NETWORK_ADDRESS,
		"scheme", "imap",
		"hostname", host,
		"port", port,
		NULL);

	client = g_socket_client_new ();
	g_socket_client_set_timeout (client, 10);
	g_socket_client_set_tls (client, TRUE);

	connection = g_socket_client_connect (client, connectable, NULL, );

	if (connection) {
		GSocket *socket;
		GIOStream *stream;

		g_print ("Connected to %s:%d\n", host, port);

		socket = g_socket_connection_get_socket (connection);
		if (socket) {
			g_socket_set_timeout (socket, 10);
			g_socket_set_keepalive (socket, TRUE);
		}

		stream = G_IO_STREAM (connection);

		if (!read_stream_data (stream))
			ret = 3;
		else if (!issue_command (stream, "A01 CAPABILITY"))
			ret = 4;
		else if (!issue_command (stream, "A02 LOGOUT"))
			ret = 5;

		if (!g_io_stream_close (stream, NULL, )) {
			if (!ret)
ret = 6;
			g_printerr ("Failed to close connection: %s\n", error ? error->message : "Unknown error");
			g_clear_error ();
		}

		g_object_unref (connection);
	} else {
		g_printerr ("Failed to connect to %s:%d: %s\n", host, port, error ? error->message : "Unknown error");
		g_clear_error ();
		ret = 2;
	}

	g_object_unref (connectable);
	g_object_unref (client);
}

gint
main (gint argc,
  gchar *argv[])
{
	const gchar *host;
	gushort port;

	if (argc != 3) {
		g_printerr ("Requires two 

Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade

2019-05-09 Thread Milan Crha via evolution-hackers
On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution-
hackers wrote:
> On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing
>
> gnutls-3.6.7-lp150.9.1.x86_64
> 
> Lead to evolution failing on my dovecot imap server with
> 
> Error reading data from TLS socket: The specified session has been
> invalidated for some reason

Hi,
dealing with such requests is better either through the user list
(evolution-list), or through bugzilla - see the "bugs" section of:
https://wiki.gnome.org/Apps/Evolution/#Online_Support
not talking that your Evolution it rather old, the current stable
version is 3.32.2.

Nonetheless, I do not expect that Evolution update would help, because
Evolution doesn't use gnutls. It doesn't use it directly. Evolution
relies on glib-networking and on whatever it uses, which is gnutls in
this case. I guess those developers would appreciate any help,
especially if the code is broken for them. If you wish, I can try to
create some simple test program (a .c file), which would open a stream
towards specified server and ask for capabilities or something, which
can be done in an unauthenticated state, on which you can verify:
a) it's really in glib-networking, b) whether more recent version of it
will help.

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] Upcoming evolution-data-server API changes (libical-glib + more)

2019-04-12 Thread Milan Crha via evolution-hackers
Hello,
this is kind of heads-up e-mail about upcoming API changes in
evolution-data-server. I also do not like them, but they are sometimes
necessary.

The first part is about porting the calendar to use libical-glib [1],
instead of libical, in order to finally provide introspection for it.
The change was so huge that it deserved an API bump from 1.2 to 2.0
(libecal-1.2 and libedata-cal-1.2 will become libecal-2.0 and
libedata-cal-2.0). The API around ECalComponent and its structures had
been made introspection friendly too. I took the opportunity and
removed all the deprecated and obsolete stuff from libecal and
libedata-cal. This work depends on the unreleased libical git master,
but there's planned a 3.0.5 release of it with the necessary changes.

The second part was about preparation for passing flags from the client
towards the backend to influence behavior. It was initially meant for
this issue [2], but I extended it to pass also information about
conflict resolution for write operations. This change touched all the
APIs - the client side API, the server side API and the D-Bus API. The
last is probably the most disturbing, at least in case of the Flatpak
applications, which build against some version of the evolution-data-
server, but rely on the host system evolution-data-server (it's
possibly broken on both sides, aka building with new eds, but run with
old, or build with old eds, but run with new). I'd say the best option
for such applications is to run the eds services inside the Flatpak
sandbox, which has the advantage that also the server side fixes are
included in the application, not only the client side fixes. It has a
downside, the downloaded data and configurations are not shared with
the system. I guess it's a downside of Flatpak in general, but that's
only my opinion.

I made the same changes (for the [2]) for libebook, libebook-contacts
and libedata-book, where I also changed some defines (added E_ prefix)
and dropped EDataBookStatus error enum, which had not been really
needed (similarly as I dropped EDataCalCallStatus). It could be
replaced with EClientError and EBookClientError. As with the calendar,
this touched the D-Bus API too. These book changes are quite
straightforward.

All the changes are prepared in this side branch:
https://gitlab.gnome.org/GNOME/evolution-data-server/tree/wip/mcrha/libical-glib
The 'make check' passes without errors.

I already have prepared evolution, evolution-ews and evolution-mapi,
though only as a buildable. The testing is to-be -done, I only didn't
want to block this due to these three projects. Looking into the other
API users, I found these hosted on GNOME:

   almanah
   bijiben
   california
   ekiga
   evolution-activesync
   folks
   glabels
   gnome-calendar
   gnome-contacts
   gnome-phone-manager
   gnome-shell
   gnome-todo

I plan to create 'wip/mcrha/eds-libical-glib' branches in each and help
with porting as much as I can. The idea is that the maintainers will
just merge the branch changes and it'll be all (from the coding point
of view). I know the branch name is inaccurate for the book changes,
but I decided to keep all these things in one branch for simplicity. I
believe it's better to break the API in a single release, instead of
doing that within multiple releases. It will make it easier for the
maintainers of the applications - the porting effort will be done only
once, not multiple times.

I have in my list these additional projects (to be verified whether any
changes are needed there and help with them if yes):

   elementary-calendar
   ffgtk
   libopensync-plugin-evolution2
   libreoffice
   pidgin-chime
   sflphone
   syncevolution
   wingpanel-indicator-datetime

If you know more, then feel free to let me know. I'll be happy to help
with the porting.

With respect of timing, my plan was to have the things prepared for
3.35.1, I expected that the changes will take longer, but it went quite
smoothly (well, actual testing will take some more time). I definitely
want to wait for an official release of libical 3.0.5 with the
necessary changes in its libical-glib part. Then we can decide,
depending in what state respective projects will be. Maybe it'll be
possible for 3.33.2 or shortly after it. I definitely do not want to
push this close to the end of the development phase, I'd rather do this
in the beginning of it, thus any third-party projects have enough time
for porting. That's another reason why I chose 3.35.1 initially.

I know this change will break some GNOME infrastructure, like the GNOME
Continuous effort, thus it's understandable to have the critical
projects prepared/ported first and commit the things (almost) at the
same time. This would need some coordination, which is another reason
for this e-mail.

I do not foresee any additional API changes currently, definitely not
on the D-Bus side, thus once this is done, the API should stay stable
for the next several years, I believe. Of course, everything depends 

Re: [Evolution-hackers] single-key keyboard shortcuts

2019-04-09 Thread Milan Crha via evolution-hackers
On Tue, 2019-04-09 at 09:13 -0600, Zan Lynx wrote:
> This insistence on stupid "Control-]" instead of "n" was one major
> reason.

Hi,
plain ']' and '[' work too here. Not talking about "magic spacebar"
feature [1]. Just that you know.
Bye,
Milan

[1] 
https://help.gnome.org/users/evolution/stable/mail-reading-keyboard-shortcuts.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] single-key keyboard shortcuts

2019-04-09 Thread Milan Crha via evolution-hackers
On Tue, 2019-04-09 at 16:15 +0200, Lukas Pirl wrote:
> I tried ``.config/evolution/accels`` which works in principle but
> introduces the usability flaw that the actions are also triggered
> in input fields

Hi,
what is the evolution version you use, please? Do you have exact steps,
please? I'm pretty sure the search entry is covered by the below
functions. At least the latest 3.32.1 (released only yesterday) should
be fine, I think.

> Can we prevent single-key shortcuts to be triggered in input fields
> generally?

There's a code which does that, but, well, it's buggy "a bit".

> Or can we write a plugin which catches single-key shortcuts
> and triggers therein configured actions? If so, how would such a
> plugin look like code-wise? Are there similar plugins to get
> inspiration from?

No idea how such plugin would look like, neither I'm aware of any
existing plugin of this kind (to add shortcuts). The usual way is to
edit the accels file, as you did.

There's an example module here:
https://wiki.gnome.org/Apps/Evolution/Extensions#Example_Module
with which you can start, if you want to, but I'm afraid I cannot help
you with the accelerators. An EShellWindow has
e_shell_window_get_need_input(), similarly EWebView has
e_web_view_get_need_input(), which is used to not trigger any action
when the widgets need the input.
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


Re: [Evolution-hackers] Icons

2019-02-11 Thread Milan Crha via evolution-hackers
On Mon, 2019-02-11 at 09:08 +0100, Mads Rosendahl via evolution-hackers 
wrote:
> Is there some kind of guide for the toolbar icon lookup?

Hi,
icons provided by Evolution itself should be available always, all the
other are following naming as used by the default Adwaita theme. Many
names are referenced for example from here (note the stock icons are
deprecated, I use this reference only because there are also provided
corresponding icon names for those deprecated):
https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html#GTK-STOCK-ABOUT:CAPS
Where Adwaita/gtk+ took those names I do not know, I'm sorry.
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


Re: [Evolution-hackers] empty folders being created in Evolution

2019-01-30 Thread Milan Crha via evolution-hackers
On Tue, 2019-01-29 at 16:03 -0500, James R. Overstreet via evolution-
hackers wrote:
>   Why are blank / empty folders being created
> in Evolution file structure at:
> 
>   ./local/share/evolution/mail/alphanumeric-folder/cache
> 
>   I think these folders used to be used to store
> old emails that were emptied from trash but looks like
> they are no longer being used for that purpose.

Hi,
could you be a bit more specific, please? Stating what Evolution
version this is about and what account type this is about will help.
Knowing what empty folders you do not like would help as well. Apart of
that, why are empty folders of an internal directory structure of some
software a problem for you, please?
Thanks and 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


Re: [Evolution-hackers] Building the Latest Source of Evolution

2019-01-22 Thread Milan Crha via evolution-hackers
On Tue, 2019-01-22 at 10:09 +0100, Andre Klapper wrote:
> https://packages.ubuntu.com/ allows searching for package names that
> the "Ubuntu" distribution uses. I entered "libecal" on that website
> and it listed "libecal1.2-dev" for development. Is that package
> installed?

Hi,
building evolution-data-server and evolution from sources means using
those built versions, not the system versions, especially when the
system version is not the same as the one being built. Better to not
install development packages for the system packages you are building,
to avoid confusion in the build time (and eventually in the runtime,
but that's harder and doesn't depend on the development packages, but
runtime packages).
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


Re: [Evolution-hackers] Building the Latest Source of Evolution

2019-01-22 Thread Milan Crha via evolution-hackers
On Mon, 2019-01-21 at 22:32 -0500, Dr. Jason Amerson wrote:
> I am trying to build Evolution Data Server and Evolution using the method 
> outlined in the Wiki.

Hi,
I suppose you mean:
https://wiki.gnome.org/Apps/Evolution/Building

> I was able to successfully get through the 
> instructions for Evolution Data Server. I have stalled on the part to 
> configure the build before make && make install. I am being told that the 
> packages libebook-1.2 and libecal-1.2 are not found.

Those are provided by evolution-data-server and installed (as part of
`make install`) to the prefix you specified. Using the steps as they
are written on the Wiki (see above) makes it bullet proof, thus I guess
you made your own modifications, which diverged from the steps.

As the first try, I'd make sure you run `source $HOME/sources/build`,
aka you've properly setup the environment, as outlined here:
https://wiki.gnome.org/Apps/Evolution/Building#Set_up_environment

Maybe consider the flatpak build, which is simpler to run:
https://wiki.gnome.org/Apps/Evolution/Flatpak
or even better install the flatpak Evolution from flathub.org, which
saves you time, because you get working copy without a need to compile
anything.
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


Re: [Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)

2019-01-04 Thread Milan Crha via evolution-hackers
On Fri, 2019-01-04 at 14:07 +0500, Khurshid Alam wrote:
> We can always query org.freedesktop.Notifications for that. Here is
> basic patch that is working.

Hi,
it can be done, but it also means some kind of expectation in the code.
What if the system the glib is running on uses different method for its
GNotification-s? That's why it's more correct to (add and) use glib
API. Imagine the same on MacOS or Windows, I doubt Windows
implementation uses org.freedesktop.Notifications (if GNotification
works there at all, because the developer documentation gives no
guarantees). I'm not against the change, it can be added at least
temporarily, until glib adds the needed API.

> https://paste.ubuntu.com/p/Td4nGvWq2v/

Could you open a bug report against eds and add the patch there,
please? I briefly read it, I didn't compile it, and it has some issues:
a) an error message says "system bus", but you open session bus
b) "to look up" in the error message sounds weird, neither I'm sure
   why you add g_get_user_name() into that error message.
c) I'd prefer to use g_strcmp0() and g_clear_error() with
   changed 'error->message' to 'error ? error->message :
   "Unknown error"', just in case
d) the code introduces a compiler warning (variables defined in
   the middle of the code block)
e) the 'str' can leak
f) the 'bus' can leak
g) ideally call this only once and remember the result; it's highly
   unlikely that the notification server will change its capabilities
   in runtime, at least from my point of view, and D-Bus calls can
   cause delays.
Having opened a related glib bug is also required, thus they can be
linked together. Well, liked in a sense of gitlab, not the real linking
with all the notifications and such as bugzilla used to do.

> By default it doesn't add action if server doesn't support it, but it
> can be made to do it.

The default is fine.

> This probably can't go in upstream since indicator-messages is not in
> debian, but ayatana-indicator-messages is.

Right, I'd like to avoid desktop environment specific code as much as
possible. Also because that can require desktop specific libraries,
which can limit the places where the code can be developed (as you
enabled the MM in the DISTCONFIGURE parameters). Not talking that such
code makes it harder to test properly (more code paths to verify by the
testers and/or builtin tests).

I'm thinking whether it would be helpful to make EAlarmNotify an
extensible. In that case you could write an extension for it (instead
of patching upstream code), that could live in your repositories. I'm
not sure whether it might make things easier or worse for you, though.
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


Re: [Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)

2019-01-02 Thread Milan Crha via evolution-hackers
On Wed, 2018-12-19 at 13:21 +0500, Khurshid Alam wrote:
> Hi Milan,

Hi,
I hope you know you address a mailing list with many subscribed users.
It's fine by me (better than private email), but not everyone here is
named 'Milan'. :)

> In unity we also set notify-with-tray to false, so both dialog is
> appearing at the same time. For the time being I set notify-with-tray 
> to true.

Once GNOME Shell's #155 is closed/fixed, you won't use that. It had
been expected (by me) to be in 3.30, but it didn't happen.

> Will it be possible to check notification server capabilities before
> adding an action ? 

There's used GNotification and after a brief look I do not see any glib
API which would allow to verify whether the notifications can have
actions or not. That might be a call to them, to add such API, then
evolution-data-server (eds) can use it. The eds doesn't use libnotify
directly intentionally (it has less dependencies, especially when the
same/similar API is provided by glib).

> But now since it is in eds I think it's better that we drop
> notification related code fr om indicator-datettime. There is no
> point replicating entire EReminderWatcher code into into it.

I'm afraid it's not a question for me. You can disable evolution-alarm-
notify autostart in its .desktop file for Unity and have things working
as before, regardless whether users have installed also Evolution or
not. At least for the time being, until that GNOME Shell's #155 is
done.

> For 2) I have a prototype code, it can be patched in eds or we can do
> it from indicator-datetime or patch downstream.

What would you exactly change on the eds side?

> 3) Is there bus signal we can watch when a notification-tray appears
> ? I am watching "notify" signal from  ca.desrt.dconf.Writer and
> checking 'reminder-past' in 'org.gnome.evolution-data-
> server.calendar', but that's not very productive.

I think the GNotification works on D-Bus, thus look there. Whether
you'd be able to distinguish between notifications sent by evolution-
alarm-notify and other notifications I do not know. Alarm notify itself
doesn't send any special D-Bus signals. Again, all your work and time
spent on this is only due to GNOME Shell's #155 not being fixed yet
(well, as long as Unity derives from GNOME Shell).

I think, if you've everything already implemented in Unity, then the
easiest would be to just disable evolution-alarm-notify in Unity and
avoid all the trouble pretty easily.

Hope it helps.
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


Re: [Evolution-hackers] Automatically start services from install path

2018-12-16 Thread Milan Crha via evolution-hackers
On Thu, 2018-12-13 at 02:47 +0100, Marek Howard via evolution-hackers
wrote:
> Is there any way to build evolution to make it automatically start
> the required services from correct installed path on startup, just like the
> system installed Evolution does?

Hi,
it's not about Evolution build, it's about setting D-Bus to search for
the built services, not for system services. The text in the referenced
wiki page didn't want to come into too much detail in this regard,
there are better articles how to setup D-Bus with it. The .service
files are installed into $PREFIX/share/dbus-1/services/, which is the
path you want to tell D-Bus to look for the services first. That D-Bus
doesn't know about these .service files is the reason why it starts
system-installed services when you run built Evolution. There can be
some differences when also systemd files are involved, but I'm not sure
what to do with it off head, I'd search the same as you might search
the web, if you (or the system-installed evolution-data-server) use
systemd.
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


Re: [Evolution-hackers] Latest Evolution version on Windows 10

2018-11-12 Thread Milan Crha via evolution-hackers
On Mon, 2018-11-12 at 12:55 +, Leonardo Costa Fiorini via
evolution-hackers wrote:
> But I use Windows 10 in a corporate environment and
> therefore this is not possible, unless somebody here knows something
> about any recent packages designed to work on Windows 10.

Hi,
if there is anything precompiled for Windows out there I do not know,
I'm sorry.

Evolution itself cannot be compiled for Windows at the moment, because
it depends on WebKitGTK+ and its usage of WebKit2, which does not
compile on Windows right now [1]. Having it done the rest will "just
work". That is, either you install some sort of Linux emulator to get
to the latest version of Evolution [2][3], or you would use a virtual
machine with installed Linux and eventually also precompiled Evolution.

Bye,
Milan

[1] https://bugs.webkit.org/show_bug.cgi?id=137488
[2] https://wiki.gnome.org/Apps/Evolution/Building
[3] https://wiki.gnome.org/Apps/Evolution/Flatpak

___
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] Request for help on hacking evolution composer

2018-10-22 Thread Milan Crha via evolution-hackers
On Sun, 2018-10-21 at 20:44 -0400, John Wiseman wrote:
> I am running Evolution 2.32 on RHel 6.9 so this is a bit older
> version.

Hi,
it's not "a bit older" version, it's an ancient version. The current
stable version series is 3.30.x.

In your version, if I'm not mistaken, the code you are looking for is
in gtkhtml3, not in evolution itself. The code moved to evolution when
it had been ported to WebKitGTK+ years later.
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


Re: [Evolution-hackers] Markdown support in evolution's message composer

2018-08-20 Thread Milan Crha via evolution-hackers
Hi,

On Tue, 2018-08-14 at 17:21 +0200, Thomas Flori via evolution-hackers
wrote:
> I presume that every developer knows the markdown syntax

I'm afraid I'm the one whom doesn't, thus not every, really.
Furthermore, Evolution as such targets wider audience than only
developers, somehow.

> It does not compete with the client design

This is questionable, isn't it? First of all, which client do you mean?
That which composes the message, or that which receives the message?
That which composes needs additional functions, if it is supposed to
convert the markdown into HTML, as you suggested below. That means you
do touch the client design. Without conversion it's different, it can
be just a Plain Text document and the understanding of the markdown
might be moved to the receiving side, which also means to add some
design changes on that side.

> It can be viewed as text without being unreadable

Right, so it suggests you do not want to use HTML, but you want
Evolution to convert it into HTML, as written below. This it might be
still HTML at the end, hence this markdown advantage is void here.

> It can be written faster and without using the mouse

I can write HTML code without mouse too, I do not remember when I used
mouse to write HTML code in a notepad the last time, the most when
selecting some portion of the text, which doesn't have anything to do
with the HTML code as such. Regarding the Evolution composer itself
(where one doesn't write direct HTML code), you are right that some
functions are easier accessible with the mouse, but most of them have
short-cuts and/or are accessible through menu, thus also without a need
of the mouse. You might also compare the same set of functions/formats,
when comparing the two methods (like when switching for example bold,
then you simply press Ctrl+B in Evolution and that all).

> The idea is to write in markdown. In the message compose options you
> choose "WYSIWYG" or "MarkDown" and when you write a message you just
> get a text box (above the quoted emails). When you send the message
> the message gets converted to html before it gets send.
> ...
> I would really prefer to write my emails with markdown in evolution.

You can always write an enhancement request for Evolution at its issue
tracker:
https://gitlab.gnome.org/GNOME/evolution/issues/new
I didn't find anything for "markdown" in the old 
https://bugzilla.gnome.org for the evolution product.

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


Re: [Evolution-hackers] Fetching S/MIME Certificates from LDAP

2018-06-20 Thread Milan Crha via evolution-hackers
On Wed, 2018-06-20 at 11:35 -0400, Vincent Lucarelli via evolution-
hackers wrote:
> Trying to figure out if it should work and I have something wrong, or
> if support for this feature never made it into the stable release.

Hi,
unfortunately, it's still not in the sources. Watch this bug [1] for
any further progress (maybe it'll be included in 3.30.x, but no
promises).
Bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=704246
It also blocks a bug which specifically talks about certificates
in LDAP address books.
___
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] Why X-Mailer instead of User-Agent?

2018-06-14 Thread Milan Crha
On Tue, 2018-05-29 at 10:10 +0200, Milan Crha wrote:
> ... thus it's probably because nobody noticed.

Hi,
just a note, Evolution 3.30.0+ will use User-Agent instead of X-Mailer
header when sending messages:
https://gitlab.gnome.org/GNOME/evolution/commit/dd8c825956

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


Re: [Evolution-hackers] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?

2018-05-30 Thread Milan Crha
On Wed, 2018-05-30 at 12:04 +0200, Garreau, Alexandre wrote:
> > Right, it's part of the development version. To be released in
> > 3.30.0+.
> 
> Oh ok, I’m still under Debian stable so I probably don’t have access
> to it… 

Hi,
the 3.30.0 stable version of evolution is to-be-released later this
year.

> What does it do?

It lets you reply with a different style than you use otherwise, aka
you can override global/account settings for reply function with it.
https://bugzilla.gnome.org/show_bug.cgi?id=602612

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


Re: [Evolution-hackers] Thread Stealing (Was: Re: Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?)

2018-05-30 Thread Milan Crha
On Wed, 2018-05-30 at 01:43 +0200, Garreau, Alexandre wrote:
> If you inspect the In-Reply-To headers you’ll see none of these is
> marked as an answer to another, yet References mark them because some
> of them do reference the other ones.

Hi,
I highly doubt any regular user even knows anything about the
internals. They care of the result. And what you did has the result as
shown in the attachment.

That's a very good habit to discuss one issue in one thread (or even
bug report), though I agree it's not always possible. While you think
the things are related, then the X-Mailer has nothing to do with Reply-
to-List (it just happened that you wrote both messages), still if I'm
not interested in the X-Mailer thread then when I collapse it (or mark
it to be ignored) I lost track of the other threads.

I also expect that you did put some effort to have the References
header filled in the other messages, which just shows that even you can
do that manually, regular users will not do it, unless they have tools
for it.

Anyway, we diverged from the subject from my point of view, we just
discuss our habits and preferences, which obviously differ. Each has
its pros and cons, I'm not questioning that. My personal past
experience is that changing someone habits is pretty hard (near to
impossible), no matter what any document can suggest as the best
practice. Again, consider regular users, corporate environments (top
posting), incorrect quoting, when people cannot distinguish between
instant messaging and e-mail (they try to use instant messaging habits
in e-mails, huh) and so on.
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


Re: [Evolution-hackers] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?

2018-05-30 Thread Milan Crha
Hi,

On Wed, 2018-05-30 at 03:04 +0200, Garreau, Alexandre wrote:
> Should we cross-post to evolution-list

Cross-posting is considered bad too. You can just start new
conversation there.

> ...to that private mailing list from the outside, ...

Right, private and public mailing lists can have different rules.

> I didn’t understand… you receive the message then, right?

Yes, but not from the list.

> Though contrarily to Evolution, the later
> differentiate between “To:” and “Cc:” header (Evolution puts
> everything in “To:”

Hmm, as far as I can tell, Evolution preserves the CC header content.

> and all the rest (that were in the “To:”, “Cc:” and “Bcc:”) in the
> “Cc:”.

I do not agree, there is a reason why there are people in Bcc. They
should not be exposed in To or CC.

> What’s the difference between Group Reply, Reply to all and Reply to
> list then?

You can configure what Group Reply does, according to your
preferences/habits.

> Alternative Reply?

Right, it's part of the development version. To be released in 3.30.0+.

> “Complicated” doesn’t mean complete, complex or big, and “Evolution”
> may metonymically refers to its UI as well.

There had been a criticism that the menus are too long already. I refer
just to that.

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


Re: [Evolution-hackers] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?

2018-05-29 Thread Milan Crha
On Tue, 2018-05-29 at 02:48 +0200, Garreau, Alexandre wrote:
> (not the same thing as a thread may change
> topic by having one of its participant changing its subject line)

Hi
off topic:
a) I'm replying intentionally to the list
b) I'm talking to you, the person written at the very first line
   of this mail, because "Garreau, Alexandre wrote:"
c) I do not know how much intentionally you did it, but you wrote
   three different topics here, in a way that there is one thread
   which covers all three topics in a very sad way. They use to
   call it "thread stealing".

Yours "writing privately to the list" is a nonsense (I'm sorry, I'd use
a softer term if I knew such), the mailing list is a public place, not
private. I do not know what your use case or work flow is that you
notice messages where you are in To/Cc better than messages directed
only to the list where you are subscribed (I'd guess as long as they
are directed to the list too they end at the same folder), but okay.
That only proves that different people have different habits and use
cases. To be honest, I hate when people reply to all in the lists. It
breaks reply to the list, because I receive messages directed only to
the list (when I'm not in To/CC, there's a setting in mailman for it,
which avoids duplicate mails), that means that reply to all makes
things worse for someone. It makes sense to reply to the list, it's the
place where the thread begun, thus it should stay there, in the public.
As Ángel said, if you are not subscribed, then you can say so and
people will keep you in the loop. Doing it "only because you can" (like
by adding such notice into your signature regardless of actual state)
might not be ideal. Again, different people, different habits,
different preferences. People using reply-to-all, because either they
do not know reply-to-list or their mail client doesn't offer it to them
is no argument to keep using reply-to-all, just the opposite.

Back to the matter, Edit->Preferences->Composer Preferences->General
tab->[x] Group Reply goes only to mailing list, if possible. That's
probably the option you are looking for. With that off the Ctrl+L still
goes to the list only, but the Group Reply goes to all.

For me, there's Reply to Sender, Reply to All, Reply to List, Group
Reply and now also Alternative Reply. Adding another reply kind, maybe
with a short cut, especially in a world where there's a tendency to
make things simpler, rather than more complicated (there are complaints
that Evolution it already too complicated, you repeated that several
times too), could not add to the thing. I also do not understand how
you'd recognize when to use reply-to-all instead of reply-to-list-and-
From. There can be people in the To/CC whom are not subscribed to the
list, thus you'd just remove them from the loop, which is wrong (I
know, you wanted to reply to the list and the To addresses, but that's
not correct, because the To can be the mailing list and all the other
people in the loop could be in CC, while you are replying to the person
in the From header).

By the way, this particular question belongs to evolution-list, rather
than to evolution-hackers. The later is for coders, while you are
discussing user functions. Not a big deal, just saying.
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


Re: [Evolution-hackers] Why X-Mailer instead of User-Agent?

2018-05-29 Thread Milan Crha
On Mon, 2018-05-28 at 19:45 +0200, Garreau, Alexandre wrote:
> In both occurence I noted the usage of, non-standard as far as I
> understood, “X-Mailer” header rather than the, standard as far as I
> understood, “User-Agent” one [1].

Hi,
as your link says, it's non-standard but standardized header for this
information.

> Why so?  Is there a reason, or did just this stayed this way since
> 2009?

Yes, I believe it's it, it just stayed such and either nobody noticed
or nobody had time to change it or anything like that. I didn't find a
bug report for it, thus it's probably because nobody noticed.
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


Re: [Evolution-hackers] MH backend for storing mail

2018-05-29 Thread Milan Crha
On Mon, 2018-05-28 at 20:24 +0200, Garreau, Alexandre wrote:
> I’d like to know where did you find a good enough specification of
> “exmh .folder” format (except evidently exmh’s source code itself)

Hi,
I'm afraid it's a question for original authors of the code, whom do
not work on the project anymore. How much the binary format is usable
between different projects is another good question.
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


Re: [Evolution-hackers] Preformat by default

2018-04-09 Thread Milan Crha
On Sat, 2018-04-07 at 23:03 +0200, Marek Howard wrote:
> I'd like to change Evolution composer in plain text to use Preformat
> block format by default. Below you can see what I did but the default
> block format is still set to Normal/Paragraph in new messages.

Hi,
it's because you changed the variables, but not the HTML structure,
which these variables modify. You can verify what the message structure
is when you press Ctrl+Shift+I when the composer body is focused, which
  will open a WebKit inspector (you might have
org.gnome.evolution.shell webkit-developer-mode set to true). I recall
something about an issue with cursor positioning around HTML tags, thus
even if the structure will be fine, the cursor can be slightly off the
proper place. In any case, I'd try to call the method of the
EContentEditor, which in this case is not to do this:
>-   ACTION (STYLE_NORMAL), "current-value",
>+   ACTION (STYLE_PRE), "current-value",
but do rather this:
   e_content_editor_set_block_format (cnt_editor,
   E_CONTENT_EDITOR_BLOCK_FORMAT_PRE);

> I'm not that used to mailing list etiquette. Is the way I attached
> the patch proper?

I think it depends on the community. While some communities prefer
patches inline, it's not the case of this mailing list (you know, you
didn't attach it by any means). But as long as you do not want to
upstream the change it doesn't matter.

By the way, you would be able to do this as a module, without touching
evolution code at all. You can use the example module as a starter:
https://wiki.gnome.org/Apps/Evolution/Extensions#Example_Module
only its MMsgComposerExtension, and change the code to your liking,
would be the end of the m_msg_composer_extension_constructed()
function, definitely after the call to parent's constructed() method.
The advantage is that you won't touch evolution code, thus you'd be
able to use stock evolution, only rebuild your module from time to time
(supposing you have write access to the module directory).

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


Re: [Evolution-hackers] lookup S/Mime encryption certificates over LDAP

2018-02-12 Thread Milan Crha
On Mon, 2018-02-12 at 09:28 +0100, Horst Weber wrote:
> Is there a plan for fixing this issue?

Hi,
you are right, neither the current stable 3.26 nor your ancient 3.18.5
support that, but the bug exists for it. The older one:
https://bugzilla.gnome.org/show_bug.cgi?id=203251
is specific for LDAP, but I expect it to be fixed with a newer:
https://bugzilla.gnome.org/show_bug.cgi?id=704246
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


Re: [Evolution-hackers] Support alternative concepts to organise mail communication?

2018-01-19 Thread Milan Crha
On Fri, 2018-01-19 at 08:12 -0500, Adam Tauno Williams wrote:
> > - Send later
> 
> Send @ [time] would be somewhat useful.  Sounds complicate to
> implement though.

Hi,
there is something in-between. In Edit->Preferences->Composer
Preferences one can set Evolution to send messages through Outbox (the
only one related is On This Computer/Outbox). A suboption contains
Immediately, Keep in Outbox and Send after 5 minutes. It's not the same
as "@ [time]", I know, but it's close to it.

Anna, I think you would get more opinion on the subject when sending to
evolution-list, which is the list for the users, thus you can get more
information from people whom use and care of Evolution (I do not mean
hackers do not care of Evolution, errr, I hope you know what I mean). :)
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


Re: [Evolution-hackers] Support for Autocrypt?

2018-01-03 Thread Milan Crha
On Mon, 2017-12-18 at 21:25 +0100, Anna Marei wrote:
> What about Evoulution?

Hi,
just for the record, there's filled:
https://bugzilla.gnome.org/show_bug.cgi?id=792045
for it.

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


Re: [Evolution-hackers] Support for Autocrypt?

2018-01-02 Thread Milan Crha
On Tue, 2018-01-02 at 16:32 +0100, Tobias Mueller wrote:
> How feasible is it, though, to implement this as a plugin to
> Evolution?
> AFAIU it would need to be able to get the context in terms of what
> headers the currently replied-to email has.

Hi,
I read the project page only briefly, and one thing there was that the
client stores the GPG keys somewhere once they are received and any
further communication is done encrypted (it implies to me that really
any further communication, not only that single thread, but I can be
wrong).

Adding the header to to-be-send message is particularly easy, the
composer has a signal emitted before sending. Checking which message
had been replied to is tricky, that may eventually require some
changes. Passing custom keys into GPG through CamelGpgContext is not
doable at the moment, neither extracting the key from the key ID (there
is saved only the key ID in the account preferences). The context
relies on keys stored within gpg itself.

Thus, rather than a plugin, it might be done directly in evolution(-
data-server).
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


Re: [Evolution-hackers] Support for Autocrypt?

2018-01-02 Thread Milan Crha
On Tue, 2018-01-02 at 10:12 -0500, Martin Owens wrote:
> On Tue, 2018-01-02 at 13:45 +0100, Milan Crha wrote:
> > thus there's a problem with interoperability (at the moment)
> > and basically no use for it in corporate environments (read: with
> > Outlook users), thus definitely no high priority for me. Once you
> > have
> > a feature request filled you can also convince someone to work on
> > it
> > and provide patches.
> 
> This is off-topic slightly, but isn't letting outlook define the
> feature set of evolution like letting IE 6 define the features of
> firefox?

Hi,
I definitely didn't want to sound that way, I swear. My idea behind the
mentioning of the Outlook was rather meant to be an example of other
client which does not have it (yet), but many people are still using
it. The thing is that the current man power on the evolution(-data-
server) is very limited, thus it's better to focus on things affecting
majority, rather than minority, of the users (that's a subjective
measure, I'm sorry).

That's the reason why I mentioned that patches are welcome, because I'm
not against the idea, I'd only prefer to review patches, than work on
it myself.
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


Re: [Evolution-hackers] Recent modofication with eds cache (3.25.91)

2017-09-01 Thread Milan Crha
On Fri, 2017-09-01 at 11:45 +0500, Khurshid Alam wrote:
> When I tried evolution 3.25.91, I noticed it doesn't dump online
> calendars as ical in  ~/.cache/evolution/calendar/
> anymore. Instead it creates a database called "cache.db" in it?
> What kind of database is it?

Hi,
yes, it's an sqlite database.

> We, at Credence, so far, have been using a python client to sync
> other machines in lan which do not have internet.
> We simply pick "calendar.ics" from eds cache and sync it with other
> machine using syncevolution.
> 
> This recent change will definitely break our script. Is there any way
> you would keep the old behaviour along with new one? 

No. That would mean double disk storage and/or other complications,
which doesn't worth it considering you are touching internal eds files.

> Although it is still possible to parse "cache.db" (assuming it's
> sqlite), but I do not want to resort to such crude method.

You do not need to parse. See the attached script. Run it as:
   $ cache-to-ics.sh ~/.cache/evolution/calendar//cache.db
and it'll create calendar.ics in the current directory containing
the data from the cache. The resulting file can have issue with CRLF,
but libraries like libical can parse it anyway.

> But I would rather use proper backend, but it seems gobject-
> introspection bindings for ecal is also missing. I me an there is
> binding for ebook but not for ecal. Why is that?

It's due to libical, which can be compiled with some introspection
bits, but they are not good, especially for older versions of libical.
There is a plan to port libecal to use libical-glib instead, which will
make introspection for libecal possible and fairly easy.
The libical-glib is merged into libical upstream (it begun as a
separate project), thus when it's released and distributions pick it
and there will be time to dive to such a large change on the eds side
(and anything connecting to libecal and/or providing a calendar
backend), then the plan will move forward.
Bye,
Milan

cache-to-ics.sh
Description: application/shellscript
___
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] Looking how to contribute to Evolution email client

2017-08-31 Thread Milan Crha
On Wed, 2017-08-30 at 13:39 -0400, Manny B wrote:
> I would like to know how I can contribute to the evolution project. I
> have become very interested with the evolution as I love outlook on
> windows. Coming to you all to see where I can help.

Hello,
thank you for your interest in Evolution. You can see some of the
information on the Evolution wiki page:
https://wiki.gnome.org/Apps/Evolution
which contains a subsection for developers:
https://wiki.gnome.org/Apps/Evolution#Developer_Resources

Please note that Evolution doesn't mean only the evolution project, it
depends on evolution-data-server too, thus some changes can mean
touching either or both of them.

I suggest to search GNOME bugzilla for opened bug reports and pick
some. As the subsection for developers shows, there are some bugs
marked for new comers, which not necessarily mean they are suitable for
them, but it seemed to the developers that they are good to start with
for someone not knowing the project much. It's the "easy-to-fix bugs"
link on the wiki page.
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


Re: [Evolution-hackers] Taskwarrior plugin for evolution

2017-05-23 Thread Milan Crha
On Tue, 2017-05-23 at 12:22 +0100, Ankur Sinha wrote:
> I was wondering if someone could give me a few tips on whether it
> would be possible to integrate taskwarrior with evolution's tasks?

Hi,
you might want to write a Tasks backend for evolution-data-server and a
configuration extension for evolution. The closest is probably the
Google Tasks backend, which resides here:
https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/backends/gtasks
while you would need all except the e-gdata-oauth2-authorizer.* files.

The configuration extension is here:
https://git.gnome.org/browse/evolution/tree/src/modules/cal-config-google/e-cal-config-gtasks.c

I suggest to target 3.25.2+ version, thus the current development,
where evolution-data-server contains ECalMetaBackend, which hides all
the boring stuff about evolution(-data-server) internals and lets you
focus on the important parts, like getting events from the server,
saving them to the server, remove them, convert from/to iCalendar
structures (if needed) and so on [1]. The Google Tasks backend already
derives from it.

If you'd like to propose it as a feature request and have it included
in evolution-data-server and evolution, then I do not see any issue
with it.

Bye,
Milan

[1] 
https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/libedata-cal/e-cal-meta-backend.h?h=wip/offline-cache#n98
___
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] Using an ECalObjModType enum as a property

2017-02-10 Thread Milan Crha
On Thu, 2017-02-09 at 21:51 +0100, Iñigo Martínez wrote:
>    g_object_class_install_property (object_class,
>   PROP_MOD_TYPE,
>   g_param_spec_enum ("mod-type",
>  "Modification type",
>  "The modification type of the event",
>  ECalObjModType,
>  E_CAL_OBJ_MOD_THIS,
>  G_PARAM_READWRITE));

Hi,
check the documentation of the g_param_spec_enum(), the parameter is
meant to be a GType, but you pass it an enum name instead. The proper
value comes from e-cal-enum-types.h (included through
libecal/libecal.h, in this case E_TYPE_CAL_OBJ_MOD_TYPE.

By the way, why do you want an object property "mod-type"? It's usually
used as a function argument, not much useful as the object property,
from my point of view. Or you use it as some sort of default?
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


Re: [Evolution-hackers] Labels when using Evolution EWS

2017-01-09 Thread Milan Crha
On Sat, 2017-01-07 at 10:56 +0100, Andrew Seguin wrote:
> I used your tip regarding the SQL query, it was helpful to get a
> clean list of labels as Evolution saw them (which was identical to
> how Outlook saw them, but I had forgotten to add a couple).

Hi,
I made some changes the last Friday for the 3.24.0 Evolution (will be
part of the 3.23.4 development release), where the Folder Properties
dialog has added a Labels tab, where users can see all available labels
as advertised by the server and create/edit/delete the Labels for the
evolution as needed. That will avoid the sqlite completely and make it
more user friendly.

> This leaves me wondering if this is expected or not? What little of
> the Evolution-EWS code I read that was closely working with the
> labels, I don't see that it should have influenced the case, so - is
> it Evolution or the Web services interface Exchange that might be the
> one changing the case?

As far as I can tell, the evolution-ews sends the labels as they are
stored locally, the only change it does is to rename the standard
labels [1]. It's the evolution itself lower-casing the tag when
creating a new label, for compatibility with the Thunderbird [2]. The
added functionality for 3.24.0 doesn't change case of the label tag
when creating a new label for an existing tag.

Your tests suggest that the Outlook itself treats Categories (the EWS
name for the Labels) case insensitively, only the Outlook Web Access
(OWA) interface treats it wrong. I'd say it's a bug in the OWA.
Evolution itself also treats label tags case insensitively.
Bye,
Milan

[1] 
https://git.gnome.org/browse/evolution-ews/tree/src/camel/camel-ews-utils.c#n381
[2] 
https://git.gnome.org/browse/evolution/tree/src/mail/e-mail-label-list-store.c#n77
___
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] Labels when using Evolution EWS

2017-01-05 Thread Milan Crha
On Thu, 2017-01-05 at 15:55 +0100, Andrew Seguin wrote:
> I tried creating labels in Evolution with the same names as those
> used in Outlook, without any difference in Behavior.

Hi,
right, that's the way it works. The Labels column in the message list
shows only those labels which are known to the evolution. There is
currently no way to show all known labels, or which are set up on a
particular message, in the UI.

Going very low level, as you indicated that you can read the code,
search your
   ~/.cache/evolution/mail/
folder for the one which contains a folder-tree file, that's for your
EWS account. Beside this folder-tree file is a folders.db file, where
is stored the information you can see in the message list, including
the labels. Open this folders.db file and check what the 'labels'
column in respective tables contain. You can do also something like:

   $ sqlite3 folders.db "SELECT labels FROM inbox WHERE labels NOT LIKE ''"

The labels are separated by a space. Once you've defined the same in
the evolution then it should start to recognize them. There are issues
with encoding and spaces/underscores, though your examples seem to be
simple ASCII letters only.

Hope it helps,
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


Re: [Evolution-hackers] ? change in how delayed send functions ?

2016-12-06 Thread Milan Crha
On Mon, 2016-12-05 at 21:08 +, Reid Thompson wrote:
> Was this change intentional?

Hi,
nope, it's a bug. Please file it in GNOME's bugzilla.

Right-clicking the Outbox folder and picking "Flush Outbox" still
works.
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


Re: [Evolution-hackers] custom address book backend

2016-11-28 Thread Milan Crha
On Sun, 2016-11-27 at 23:38 +, Carlos Prado wrote:
> I would like to write a custom backend for icloud addressbook and
> calendar for evolution data server

Hi,
the iCloud supports CardDAV and CalDAV, thus any client which uses
these standard protocols can connect to the servers. At least SRV
record on the icloud.com site advertises for the two:
   caldavs: caldav.icloud.com:443 priority:0 weight:0
   carddavs: contacts.icloud.com:443 priority:0 weight:0

The evolution-data-server can handle both protocols already, thus I'm
wondering whether it would make sense to write the backends "again".

What is actually missing is a complete setup for the iCloud services,
like is offered for GMail, Exchange Web Services, MAPI and such, but
that is far from the place you ask about.

> Where can I start?

Check current backends in the evolution-data-server sources, eventually
one of the 3rd-party connectors, like evolution-ews.

https://git.gnome.org/browse/evolution-data-server/tree/src/addressbook/backends
https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/backends
https://git.gnome.org/browse/evolution-ews/tree/src/

> Do you have any manual, article or wiki for this?

I do not know whether there is anything specifically for the two, but
there is always a developer documentation:
https://developer.gnome.org/eds/stable/backend.html
https://wiki.gnome.org/Apps/Evolution

The developer.gnome.org doesn't have the reference for the eds on its
main page for some reason, I do not know why. The WiKi page has some
valid information, but also as it mentions, there can be outdated info
as well.

> This is the correct way for adding new online services to gnome
> platform?

Sure, we can discuss your ideas here, then you'd be able to focus in
the way which will fit your needs the best. We can even switch to
GNOME's bugzilla at some point.
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


Re: [Evolution-hackers] Head-up: Evolution-Data-Server Camel API changes to land next week

2016-11-08 Thread Milan Crha
On Mon, 2016-10-31 at 18:05 +0100, Milan Crha wrote:
> I plan to merge the evolution-data-server changes on Tuesday,
> November 8th (the next week), and as soon as possible also the
> changes in evolution, evolution-ews, evolution-mapi, evolution-rss
> and evolution-activesync, thus the GNOME Continuous builds are not
> broken for long.

Hello,
this is a notice that the changes from wip/camel-more-gobject branches
in respective modules are committed into the master branches, namely:

https://git.gnome.org/browse/evolution-data-server/commit/?id=9af0c834e
https://git.gnome.org/browse/evolution/commit/?id=8b74f9146
https://git.gnome.org/browse/evolution-ews/commit/?id=e4dcf633b
https://git.gnome.org/browse/evolution-mapi/commit/?id=341a2f4ea
https://git.gnome.org/browse/evolution-rss/commit/?id=c78ce3988
https://git.gnome.org/browse/evolution-activesync/commit/?id=f093b09e0

The bug 764065 contains patches for evolution-rspam and
mail-notification projects:
https://bugzilla.gnome.org/show_bug.cgi?id=764065

The changes will be released as 3.23.2 of the evolution-data-server
(and the other evolution core products).

If anything would go wrong, please let me know (ideally through
bugzilla).
Thanks and 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


Re: [Evolution-hackers] Head-up: Evolution-Data-Server Camel API changes to land next week

2016-11-01 Thread Milan Crha
On Mon, 2016-10-31 at 20:43 +, Zisu Andrei wrote:
> I had some patches for the SPECIAL-USE flags, but I haven't had time
> to deal with them over summer, should I also try to get those merged
> before the window closed?

Hi,
I suppose you mean
https://bugzilla.gnome.org/show_bug.cgi?id=767821

It'll be nice to have that part of 3.23.2, yes. If I recall correctly,
the current aim is to not change current API, only add new symbols
(without a need for the migration), which won't need a soname version
bump ideally. It's still a 3.23.x material.

Thus if you have time, please update the patch at that bug report and
we can continue there.
Thanks and 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


Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

2016-10-31 Thread Milan Crha
On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote:
> On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋 <lant...@gmail.com> wrote:
> > 於 週三,2016-10-05 於 09:33 +0200,Milan Crha 提到:
> > Can we have a common way to enable GTK-Doc installation in modules
> > using CMake? In modules using Autotools, we have --enable-gtk-doc
> > which is recognized by every module supporting generating
> > documentation with GTK-Doc . However, we have two important modules
> > using CMake, Evolution (including Evolution-Data-Server) and
> > WebKitGTK+, but they require different options to enable GTK-Doc.

Hi,
I agree that the consistency is "good to have". I chose the name to
stay as close to the one from autotools as possible. Similarly with
other offered configure options.

> gtk-doc now ships a CMake module upstream:
> <https://git.gnome.org/browse/gtk-doc/tree/cmake>.
> 
> I adapted this from existing code in the Firtree project:
> <https://github.com/rjw57/firtree/tree/master/cmake/Modules>
> 
> It would be nice if Evo and WebKitGTK+ could switch to using that. It
> may need some improvements; I used it successfully in a couple of
> projects (proprietary ones, sadly) but I don't know how much use it
> has had elsewhere.

Unfortunately, I do not recall what failed for me when I tried to use
it in the time I've been adding the functionality into the libical.
It's couple months ago, it's likely that the things changed on the
GtkDoc side meanwhile, I really didn't give it a try any time recently.

Similarly to WebKit, I currently do not plan to bump GtkDoc dependency,
but it doesn't mean I'm against it. As I begun above, the consistency
is good to have.
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


Re: [Evolution-hackers] Documentation Issue? Leaving messages on server indefinitely

2016-10-31 Thread Milan Crha
On Thu, 2016-10-27 at 20:10 +0200, Mario Wenzel wrote:
> Sadly the documentation doesn't state whether this is possible. If it
> isn't, then this is basically a feature request and I'll file it as
> one. If I can just set 0, I'll file it as a documentation issue. I
> don't know which.

Hi,
the "Delete after [  0 ] day(s)" works like "Leave messages on the
server forever". I use it here too.

By the way, you would get sooner response, if you write to the
evolution-list. Your question is user centric, from my point of view,
thus it would make perfect sense to ask the users, whom would know too.
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


Re: [Evolution-hackers] Feature request: filter out messages from known senders

2016-10-26 Thread Milan Crha
On Tue, 2016-10-25 at 21:23 +0200, Jarek wrote:
> I'd like to have a filter condition, selecting messages from
> senders from address book.
> I'd like to create folder for unknown senders.

Hi,
that might be pretty slow, at least according to the past experience,
where a similar thing is done with "Load remote content only for
messages from contacts". This feature did cause slowness. I cannot
imagine that the rule would check all the senders in my mailing list
folder which currently has more that 162.000 messages (not unique
senders, luckily). Imagine you've like 10.000 different senders, that
would be a flood on the address books lookup. Count to it remote
address books, like WebDAV, Exchange, and so on. I even do not want to
think of the consequences when the search folder would be updated due
to whatever reason. In other words, the performance would be the main
problem.

By the way, this list is not meant to be used for feature requests,
there is the GNOME bugzilla for it:
https://bugzilla.gnome.org/enter_bug.cgi?product=evolution

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


Re: [Evolution-hackers] contacts sync from eds to idevice.

2016-10-13 Thread Milan Crha
On Thu, 2016-10-13 at 09:36 +1100, Timothy Ward wrote:
> The updated gtk3 eds-to-idevice code is on github at
> 
> https://github.com/gitsop01/eds-to-idevice



> Any advise on the idea or code or what would be required to
> have it included in eds as a sync backend to an idevice would be
> appreciated.

Hi,
okay, so I opened the github page and checked the configure.ac and it
claims at the end these dependencies:
   libimobiledevice-1.0
   libplist
   glib-2.0
   gtk+-3.0

The glib-2.0 is no problem, it's used by the evolution-data-server
(eds). The gtk+ is an optional dependency for the eds. The other two
libraries are completely new for the eds.

You said it's a command line tool, which makes me wonder why you want a
gtk+, when the command line is meant to run without any display.

As you claimed that to have full functionality the build requires some
recent code from the github (maybe unreleased?), then I hesitate to
take this into such core GNOME product as eds is. It could be included,
but disabled by default, which degrades its usage heavily (the
packagers would not notice it exists, when it'll be disabled by
default).

The other part of the deal would be the maintenance of the code. I'm
surely not able to give any maintenance to the code, I even cannot test
whether it does what it is supposed to do, because of missing any Apple
device here. In that case, who will take care of the code? And for how
long? This is nothing personal, we do not know each other, I've just
pretty bad experience in this regard; people promised me many things to
get where they wanted to be, but then forgot of the deal quite quickly
afterwards.
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


Re: [Evolution-hackers] contacts sync from eds to idevice.

2016-10-12 Thread Milan Crha
On Thu, 2016-10-13 at 05:06 +1100, Timothy Ward wrote:
> gtk3 eds-to-idevice code exists to sync contact information between
> eds and an idevice. It is coded as a commandline utility at the
> moment, and was a git project that I updated earlier this year
> from the original author.
> 
> As evolution does not have the capability at the moment
> to sync contacts to an idevice, I was wondering if this would be 
> a worthwhile project to add to evolution.

Hi,
it sounds interesting. I'm wondering, is it anything what for example
syncevolution [1] cannot do? I understand the syncevolution as a pretty
complete solution to move contacts/event/memos/tasks between the
evolution-data-server and the servers (and/or devices, if I'm not
mistaken). That is, maybe it'll make more sense to include it there, to
have all of such functionality at one place. That doesn't mean it
couldn't be part of the evolution-data-server, I'm only unsure how to
test and maintain the code, because I do not have any idevice (or I do,
but I'm not aware of it; it depends what you understand behind that
name). By the way, what would be the new dependencies to be able to
compile your code?
Thanks and bye,
Milan

[1] https://syncevolution.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] Switching from Autotools to CMake for core evolution products

2016-10-10 Thread Milan Crha
On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
> I plan to merge the changes the next Monday, October 10th, some time
> after the 3.22.1 release. This way there will be enough time to catch
> any issues before the 3.23.1 release.

Hi,
this is a notice that the changes had been committed to git master of
the modules and some after-commit fixes had been done as well already.
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


Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

2016-10-10 Thread Milan Crha
On Fri, 2016-10-07 at 09:39 +0200, Gilles Dartiguelongue wrote:
> Also, does CMake support make distcheck yet ? As a downstream
> maintainer, I find many packages with errors in distributed sources
> would have been caught by make distcheck when releasing.

Hi,
CMake doesn't "support" it by default, but I have there custom targets
named "dist", "distcheck" and "disttest", the same as "check". Note
that the 'dist*' targets create the tarball from a git clone first,
thus it won't work with the tarball sources. It didn't work well with
the autotools too, I think, where you better build the sources and run
'make check' only.
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


Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

2016-10-05 Thread Milan Crha
On Wed, 2016-10-05 at 12:28 +0100, Philip Withnall wrote:
> Out of interest, why?

Hi,
seems to be better than autotools, gives more freedom and easily allows
the sources to be built much faster than with autotools (it builds here
in ~1/3 of the time which uses autotools, still using "Unix
Makefiles"). I know it's caused mostly by not having one giant
Makefile.am, but this way it's easier (at least for me).

With the "gives more freedom" I think of different generators, which
CMake offers quite many [1].
Bye,
Milan

[1] https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html
Note it's for version 3.6, while the required CMake version is 3.0
___
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] Switching from Autotools to CMake for core evolution products

2016-10-05 Thread Milan Crha
Hello,
this is a heads up that the evolution-data-server, evolution,
evolution-ews and evolution-mapi products will switch from Autotools to
CMake for the 3.23.1 release. Each of them has created a wip/cmake
branch, which builds and even runs. I tried to keep things as close as
they were with the Autotools, but I made some cleanup changes here and
there (the evolution installs more shared libraries, evolution-ews and
evolution-mapi have some installed libraries renamed and/or added;
header and pkg-config files for the evolution-ews and evolution-mapi
are not provided any more), thus some tweaks in packaging (apart of
calling CMake instead of autotools) will be required.

The build with CMake is straightforward, if you already got in touch
with it. Similar to Autotools, if some feature is enabled and its
dependency cannot be found, then an error is printed with a notice how
to disable the feature if needed. At the end of the configuration phase
are printed all the available options which can be used to tweak the
builds, to both know with what options the project had been configured
and to know what options are available in general.

I plan to merge the changes the next Monday, October 10th, some time
after the 3.22.1 release. This way there will be enough time to catch
any issues before the 3.23.1 release.

I also plan to clean up the source tree a bit, like adding src/
directory into the evolution-data-server and evolution, but I do not
expect it would have any impact on the installed bits. Any custom
distribution patches would need update, of course. I may do some other
miscellaneous changes here and there before and after the merge as
needed.

You can give a try to it already with a snapshot of the wip/cmake
branches [1], if you'd like to. I'd prefer to hear about any issues on
the evolution-hackers@gnome.org list only (I'm not subscribed on the
distributor-list, but on the other two lists I am).

Thanks and bye,
Milan

[1] 
https://git.gnome.org/browse/evolution-data-server/snapshot/evolution-data-server-wip/cmake.tar.xz
https://git.gnome.org/browse/evolution/snapshot/evolution-wip/cmake.tar.xz

https://git.gnome.org/browse/evolution-ews/snapshot/evolution-ews-wip/cmake.tar.xz

https://git.gnome.org/browse/evolution-mapi/snapshot/evolution-mapi-wip/cmake.tar.xz

___
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 display width too large

2016-10-04 Thread Milan Crha
On Tue, 2016-10-04 at 14:46 +0200, Tom wrote:
> sorry for cross posting (if it really is) but I have two addresses
> for the hackers stored here.

Hi,
I noticed your query on the evolution-list [1], where Andre already
replied to it. I can extend his explanation, if you prefer, but I'll
rather do it there, to not reference the two threads between mailing
lists.
Bye,
Milan

[1] https://mail.gnome.org/archives/evolution-list/2016-October/msg00022.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


[Evolution-hackers] Heads-up: Evolution-Data-Server and Evolution to depend on WebKit2 since 3.21.90

2016-08-10 Thread Milan Crha
Hello all,
this is just a little heads-up that the evolution-data-server's
libedataserverui sub-library and the evolution itself will depend on
WebKit2 since the upcoming 3.21.90 release, unless anything really bad
would rise till the release Monday.

Big kudos to Tomas Popela, whom led this effort.

Anything what links against libedataserverui or the evolution libraries
should not use WebKit1, only WebKit2 (or no WebKit, of course), because
these two cannot be mixed in runtime. That was the reason why
the evolution-data-server wasn't ported yet, because the evolution was
still using WebKit1 and it links against libedataserverui.

The evolution-data-server dependency on WebKit is optional, it can be
avoided in the configure time by using --disable-google-auth configure
option, though it's better to have the option enabled, because it adds
some functionality for the evolution and other clients of the
evolution-data-server.
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


Re: [Evolution-hackers] Thread-conversation view

2016-08-01 Thread Milan Crha
On Fri, 2016-07-22 at 09:54 +0200, Éloi Rivard wrote:
> I am curious of your interest in the thread-conversation view
> (#258233), that appears in the evolution TODOs. Is there any plan to
> work on it soon, or is there any blockers that prevents you to?

Hi,
mostly lack of time (more important things to be done) and lack of man
power is blocking any such enhancement requests. Patches are always
welcome, of course, thus if you find anyone willing to spend a time on
it, then it'll be great. Just attach the patch into the bug report you
gave a link to and wait for the review.
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


Re: [Evolution-hackers] help me!!

2016-05-12 Thread Milan Crha
On Wed, 2016-05-11 at 14:50 -0400, Ronny Montano Martinez wrote:
> Hello, I write because I am developing an application in Python. Here
> I need to add new events to the calendar application evolution, but
> will not let me, when I try to import or ECalClient ECal displays a
> message in error, I hope your help as soon as possible, thanks

Hello,
I would like to help, but you didn't give enough information to be able
to do that. Could you clarify these things first, please?

a) what is the exact version of the evolution-data-server and
   evolution you are using

b) do you want to add the event from the python code, or from
   the evolution itself

c) where, in which calendar, do you want to import the event

d) what is the exact error message you receive; if you run evolution
   in a non-English locale, then ideally run it as:
   $ LANG=C evolution
   Also check the evolution console, whether it shows anything useful.
   It can be that the background processes will claim errors in
   the other locale, thus you might want to run it similarly:
   $ LANG=C /usr/libexec/evolution-calendar-factory -w
   and only then run the evolution from another terminal. The exact
   location of the calendar factory executable depends on
   the distribution you are using.

e) could you share a test event you are trying to import, which fails

Thanks and 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


Re: [Evolution-hackers] [PATCH] evolution-data-server: the language for the day of the week in quoted messages should match the message language

2016-04-15 Thread Milan Crha
On Fri, 2016-04-15 at 17:07 +0200, Guido Trentalancia wrote:
> When quoting a message in a reply, make sure that the language for the
> day of the week matches the language of the quoting text generated by
> evolution.
> 

Hi,
please, do not send patches here, the team uses GNOME bugzilla for this
purpose. You already have opened a bug for this [1], thus please stick
with it. It's time consuming even for you, doing all the work twice,
once here and one in the bugzilla.
Thanks and bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=765112
___
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] vCard test suite

2016-04-05 Thread Milan Crha
On Tue, 2016-04-05 at 20:44 +0200, Ángel González wrote:
> On 2016-04-05 at 08:52 +0100, Philip Withnall wrote:
> > I don’t think I explained clearly enough, sorry. All three options
> > are
> > proposing to keep vcard-test-suite as a separate project, which EDS
> > depends on in some way (either as a test-time dependency, a git
> > submodule, or a build-time dependency).
> 
> I don't think it should be a build-time dependency. If the dependency
> is not fulfilled, you should still be able to build and run eds
> (except
> for running those tests, of course).
> 

Hi,
I agree with Ángel, build time dependency is out of question. Also
because soft dependencies are easy to overlook, thus one might easily
not even notice the new test suit.

I'm not sure how you'd like to have done the test-time dependency. If
the files would not be available, will the whole test suit be skipped,
or the test will fail with an error? The first option is similar to
build time dependency (being it a soft dependency). The second option
might be a bit limiting, no?

That lefts us with a git submodule. What is the difference between the
git submodule and direct inclusion in the sources? If you want to cover
more than vCard tests for the evolution-data-server (like testing also
other vCard parsers, from other libraries), then it seems to me that
the cleanest solution would be to provide installed-tests from the git
repo as you have it, just define different "targets". I mean, I miss a
gain in the inclusion of the project as a git submodule in the
evolution-data-server. It's possible I'm overlooking something though.
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


Re: [Evolution-hackers] vCard test suite

2016-04-04 Thread Milan Crha
On Sun, 2016-04-03 at 22:13 +0100, Philip Withnall wrote:
> How would it be best to include this in the EDS test suite? The
> options
> I see are:
>  • Install the vCards on the system in the installed-tests prefix,
> for
> use by unit tests installed by EDS.
>  • Import them as a git submodule into EDS.
>  • Keep vcard-test-suite separate and have it install its own unit
> test
> for EDS[1].
> 
> I think the first option might be the best, but I would appreciate
> others’ input.
> 

Hi,
if the Collabora is fine to copy/move the data and the code in the
evolution-data-server sources, then I do not see any issue with it.

I would also prefer to make it part of the installed-tests for the
evolution-data-server, together with the binary which will process all
those files (install data and do not use them looks incorrect). The
source code for that binary needs a little coding-style changes to
conform the style being used in the evolution-data-server, but that's
only a minor things (apart of the "blah" string there).
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


Re: [Evolution-hackers] Making an email-moving plugin

2016-04-04 Thread Milan Crha
On Sun, 2016-04-03 at 22:28 +0200, Ángel González wrote:
> Where should I begin dealing with it? I have looked at those at the
> plugins folder, but none of them seem to do any of the steps I need.

Hi,
the plugins are sort of an outdated technology in the code, what you
want to do is an EExtension, which are stored in modules/ directory.
You read the CamelFolder and the set of selected messages from an
EMailReader, then you do whatever you want using the CamelFolder API.
In your case of moving the messages between folders you
call camel_folder_transfer_messages_to() or its _sync() variant. You
might want to read the messages first too, to check the headers, which
you can do using camel_folder_get_message().

One of the close changes, regarding message move to other folder, was
done in this [1] commit. You might be interested in the .ui file
changes and in the e-mail-reader.c changes. It is not a module, it's
inside the code, but it shows at least how to easily move messages
between folders and how to get to the list of selected messages.

I do not know which evolution version you target this for, but also
consider using e_shell_view_submit_thread_job(), which helps to run
jobs asynchronously and reports errors to UI, together with a possible
feedback and cancellation capabilities (the used cancallable is a
CamelOperation, through which you can pass the feedback and progress).

With respect of what to extend, one possible type is a MessageList,
though you cannot get directly to the EMailReader from it. You can use
an EMailBrowser type as the extensible target, which is the separate
window showing the message (it also implements the EMailReader
interface), and also EMailPanedView type, which is the one in the Mail
view. You can extend also other types and add your UI elements into the
EMailReader related parts (like shown in [1]), and all of that will be
propagated to all EMailReader descendants/implementations, without you
knowing whom they are at all.

Hope it helps,
Milan

[1] https://git.gnome.org/browse/evolution/commit/?id=f6c0c822
___
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] EClient Functions

2016-03-29 Thread Milan Crha
On Mon, 2016-03-28 at 07:33 +1100, Timothy Ward wrote:
> The EbookClient functions such as:
> 
> 1) e_book_client_connect_sync and
> 2) e_book_client_connect_direct_sync etc
> 
> are Declared as EClient * functions but return an EbookClient
> 
> Does this means that the returned EbookClient must be type casted to
> a EbookClient to stop the Compliler warnings about the mismatch in
> declaration of the function and what the function returns. or am I
> missing the point here.

Hi,
to be honest, I do not know why it is done this way. Maybe for a
similarity with gtk+, where the "new" functions also return GtkWidget,
not the respective type the function created.

> What is the correct code to type cast for an EbookClient.

It depends on your language. If it's C, then:
   EBookClient *book_client;
   EClient *client;

   client = ...;

   /* check for errors and such (for example client can be NULL) */
   ...

   book_client = E_BOOK_CLIENT (client);

That's pretty common way of doing these things with GLib.

> When using these functions with evolution-data-server can a new glib
> main loop be started for bdus operation or does it have to started
> in another way for an application that wishes to retrieve all contact
> info for the available addressbooks. A good example is gnome-
> contacts.

Check the backtrace, there is a book_client_dbus_thread() thread which
is for D-Bus things about the EBookClient. In any case, whenever you
call a ..._sync() function, you should know that such function can
block and thus eventually freeze the application if it's run in the
main (GUI) thread. Either use the asynchronous variants of the
functions or run your own thread where you'll do the synchronous calls,
possibly incorporating structures like GTask.

> 
> 1) Is the only two methods of getting all contacts fields in an
> EWSaddressbook is either to iterate over a list or hash table of
> all  known fields of a contact,  or
> 
> 2) Use the vcard functions to get all the known fields.

This has not much to do with the EWS backend, the EBookClient tries to
not expose where exactly you get the data from, it gives you the data
in the same way for any backend. If you want to get the information
from the EContact, which is the descendant of EVCard, then you can:
1) have a list of all possible fields in the EVCard and check whether
   your EContact contains them
2) ask the EBookClient for supported fields and check only for those
3) finally, if you care of performance, then use the EVCard functions
   to get list of actually stored attributes on the EContact and use
   only those you know about.
Do not feel confused to use EVCard functions, the EContact provides
only a "proxy" structure which makes it easier to work with certain
attributes, by internally calling EVCard functions anyway.
Hope it helps,
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


Re: [Evolution-hackers] Account autoconfiguration/autodiscover

2016-03-01 Thread Milan Crha
On Tue, 2016-03-01 at 09:22 +0100, Tobias Mueller wrote:
> Hm. GSoC is 12 weeks or so. And the intern would probably be
> completely unaware of Evolution's codebase.  Do you think that's
> feasible, still?

Hi,
I'd be afraid a bit. See below.

> How about a separate tool that will then set up your evolution
> accounts..?

The only difference would be that you run a separate application,
instead of an integrated tool within the application. Thus the way you
call the "function". All the rest would be the same. Thus no win to
write a separate application, instead of a built-in code. Of course, it
can start as a separate application, but would end in the evolution
code base anyway.

> Could anybody mentor such a project at all?

I guess so, but honestly, the current main priority for 3.22 is to port
evolution to webkit2. It's a huge change and I expect some fallouts of
it. I could be a mentor, but I cannot promise a full focus on it, which
it might need. Thus I'd prefer to postpone the work on the
autodiscover. I also have other things which I'd like to do before it,
which I have in my todo pile longer that this. Maybe the webkit2 port
will not be a big issue, but I prefer to not have tight schedules and
so on.

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


Re: [Evolution-hackers] Account autoconfiguration/autodiscover

2016-02-24 Thread Milan Crha
On Wed, 2016-02-24 at 10:34 +0100, Tobias Mueller wrote:
> Do you think it would be something for the upcoming Summer of Code or
> Outreachy rounds?

Hi,
it depends. It's not a large change, but not a tiny too. It also
depends how one would solve this.

My not so simple idea on this is:
a) using File->New->Mail Account to create "corporate-like" accounts
   doesn't feel right, even the addons like evolution-ews and
   evolution-mapi do that
b) a better option would be to add a new Edit->Server Accounts (the
   wording is awful, I know), where you fill only User name and E-Mail
   (or server domain, if not email), and then the wizard will check
   what that domain offers based on the SVR records, well-known HTTPs
   entry points and so on and offers to add all sources it'll find
   for the user, thus you gen not only Mail, but also Contacts,
   Calendar, Memos and Tasks, if the server supports it. Furthermore,
   users will be able to manage which sources should be visible in
   the UI (offered to other evolution-data-server clients) here, not
   like it is done currently, where you get all or nothing.

Having a working prototype would not be that hard, but fine tune it
will be harder. Part of the fine-tuning will be also the extensibility
of the new Server Account dialog, to be able to attach custom
autodiscovery methods to it.
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


Re: [Evolution-hackers] Account autoconfiguration/autodiscover

2016-02-24 Thread Milan Crha
On Wed, 2016-02-24 at 08:51 +0100, Narcis Garcia wrote:
> I have many users with Evolution 3.10.4 in Ubuntu 14.04

Hi,
the current Evolution (also the development version 3.19.90) doesn't
support any kind of this autodiscover thing for mail accounts. The
settings lookup is read from static tables on a GNOME server.

On the other hand, you can prepare set of .source files, located at
   ~/.config/evolution/sources
with preconfigured settings and distribute these to your users. I know
it's not the same, but it can help to admins, at least a bit.

The only piece software which uses some autodiscovery is evolution-ews
(eventually also evolution-activesync), but that is strictly used for
Microsoft Exchange servers, not for any random.

Similar things had been discussed recently.
Related bug reports in GNOME's bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=640598
https://bugzilla.gnome.org/show_bug.cgi?id=720603
https://bugzilla.gnome.org/show_bug.cgi?id=750564

If you could create a new bug report (or find an existing) and add
there a reference to any developer documentation which describes how
your server autodiscover settings exactly work, then it can be added to
the pool of these bugs.
Thanks and 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


Re: [Evolution-hackers] Query Evolution's Calendar Data storage location

2016-02-23 Thread Milan Crha
On Sun, 2016-01-03 at 16:53 +0100, Tom wrote:
> Sorry, Milan, but what I'm looking for is a "quick & dirty" solution
> for my home use, no time to get into C programming :-(

Hi,
I'm sorry for a late reply, I tend to forget of this for such long. 

Evolution doesn't provide anything like this on its own. It has an
evolution-addressbook-export for address books, but nothing for
calendars.

> Any inspirations for existing tools (no GUI needed) to handle the ICS
> format ?

I'm afraid I cannot help here, I do not use any such tool myself.
Neither I'm aware of any which can connect to the evolution-data-
server, though as you said you use only the On This Computer calendars,
then you can grab any tool which operates on the .ics files directly. 

Ask Google, that may give you some hints. I would try something like
"ical2csv" or "ics2csv" or even "save calendar as spreadsheet", which
gives some pointers to Google calendars too.

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


Re: [Evolution-hackers] Additions required to the AppData file

2015-11-30 Thread Milan Crha
On Fri, 2015-11-27 at 06:28 -0800, Richard Hughes (semi-automated)
wrote:
> So, what do I want you to do? Basically, I would like you to:
> 
> Add the following data into evolution-spamassassin
> Add the following data into evolution-bogofilter
> Add the following data into evolution.appdata.xml

Hi,
I committed those as:
https://git.gnome.org/browse/evolution/commit/?id=30e6ffc

I added also UserDocs into the Evolution's appdata file,
because it has a user documentation.

What about the RecentRelease, it applies to the evolution
products (they follow GNOME release cadence), but I dind't get from
your document whether it's just one of the kudos which the distribution
sets, not the software itself.

> Add the following data into evolution-mapi
https://git.gnome.org/browse/evolution-mapi/commit/?id=c54b87c

> Add the following data into evolution-ews
https://git.gnome.org/browse/evolution-ews/commit/?id=bd6bbce

I'm wondering whether that "ModernToolkit" is relevant for the addons,
because those addons cannot run without the evolution (or other
client). I added them anyway.

I also tried the `appstream-util validate` on the result files, and the
evolution's appdata file has missing  and , but as
neither gedit has them, I didn't add them. I also noticed with this
tool that it doesn't like LGPL. I do
not understand why or what it expects there for the LGPL. I tried
`licensecheck` on the evolution-data-server/camel and it reports plain
LGPL there too, thus I'd expect that the `appstream-util validate`
would understand it as well. This is with libappstream-glib-0.5.1-
2.fc23.x86_64.

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


Re: [Evolution-hackers] Need help debugging owncloud caldav problem

2015-11-26 Thread Milan Crha
On Thu, 2015-11-26 at 08:01 +0300, James Bottomley wrote:
> I'm thinking currently the fix might be in libical.  Both the issues:
> converting VALUE= to VALUE=x and adding it to the TZID look to be
> bugs in that library.

Hi,
what is your libical version, please? As I said in the previous email,
mine version, 1.0.1, doesn't add quotes around the value. It only makes
the VALUE=X from VALUE=. I tried that on a local calendar (On This
Computer), which pointed to a custom file, where I did all the "raw"
editing.
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


Re: [Evolution-hackers] Need help debugging owncloud caldav problem

2015-11-25 Thread Milan Crha
On Wed, 2015-11-25 at 12:21 +0300, James Bottomley wrote:
> On Tue, 2015-11-24 at 18:32 +0100, Milan Crha wrote:
> > On Tue, 2015-11-24 at 15:17 +0300, James Bottomley wrote:
> > > DTSTART;TZID=America/Los_Angeles:20131024T18
> > > DTEND;TZID="America/Los_Angeles;VALUE=":20131024T20
> > > 
>
> However, this doesn't excuse evolution's handling of it,

Hi,
it depends.

> because every other caldav implementation silently ignores this

How do they ignore it? Do they convert the time into a floating time?
That means that they interpret the end time of the event as being in
the timezone the view is set for. Thus, if you've set your view's
(UI's) timezone to America/Los_Angeles, then you won't notice any
difference, the event will be on 2013-10-24 between 18:00 and 20:00. If
you've view's timezone set to UTC, then the time with the floating
interpretation is from 2013-10-25 02:00 to 2013-10-24 20:00. That means
the start of the event is _after_ its end. It's precisely what the
evolution's day view told you:
> (evolution:19872): calendar-gui-CRITICAL **: e_day_view_add_event:
> assertion 'start <= end' failed

> whereas we mangle it into a potentially unreadable timezone and then
> drop the event. The mangling seems to occur as part of the back end
> caching and is likely the fault of libical.

Right, I'd like to know which part added the quotes. I tried to read
the same event without the quotes and save it locally and the result
was:
   DTEND;VALUE=X;TZID=America/Los_Angeles:20151125T19
that means the libical didn't add there the quotes. At least the 1.0.1
version doesn't do that.

I also tried what the evolution's UI will do when I change my view's
timezone to America/Los_Angeles and set the DTENT to the quoted TZID,
as you found it, and the result is that the evolution showed the event
properly. As soon as I changed to another timezone, like a
Europe/Prague, the event disappeared from the view and the evolution
console contained runtime warnings, though different from that yours:
>> e_day_view_add_event: assertion 'start < add_event_data->day_view
>> ->upper' failed

Interestingly, a change of the view's timeozne to Pacific/Midway didn't
make the event longer. I would expect it to happen.

> I'll see if I can work out how to fix it.

Thanks, I appreciate it. Just consider that trying to workaround other
software's fault, especially such specific, is likely not to happen.
It's because the only correct fix is the fix of the broken software
(aka your opened ticket against ownCloud).

Thanks and 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


Re: [Evolution-hackers] Need help debugging owncloud caldav problem

2015-11-24 Thread Milan Crha
On Tue, 2015-11-24 at 15:17 +0300, James Bottomley wrote:
> DTSTART;TZID=America/Los_Angeles:20131024T18
> DTEND;TZID="America/Los_Angeles;VALUE=":20131024T20
> 
> Removing the quotes and the spurious ;VALUE= for the DTEND TZID causes
> the event to become visible when evolution is restarted.  So, it looks
> like something in the caldav connector is adding bogus data to the TZID
> information.

Hi,
I agree with you, the empty VALUE= should not be there. How the quotes
got around it is another question.

I suppose you are trying to figure out which of the clients made the
change on the event that garbled its DTEND, right? It can be the
evolution too, with its libical. If I'd guess, I'd try to change an all
day event into an event which is within one day. The all day events
created by the evolution are with VALUE=DATE, which made me wondering
about this possibility.
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


Re: [Evolution-hackers] Need help debugging owncloud caldav problem

2015-11-17 Thread Milan Crha
On Tue, 2015-11-17 at 09:42 -0800, James Bottomley wrote:
> Shows they're all present, including the ones evolution is not
> displaying.  I suspect there's some issue somewhere in the ical file
> that's causing a parse problem ... so my question, how do I debug
> this? Is there a magic debug option to show parsing of ical events?

Hi,
there is no magic option to debug parsing of the iCalendar object, the
only CalDAV related debugging option you already found and used
properly.

I would double-check that you do not have any filters set in the
Evolution's UI, then pick one of those missing events and enter a
similar one into the CalDAV calendar. Then compare the two objects in
the local cache and see the differences. Compare also UID and
RECURRENCE-ID properties of the components, the later is there for
recurring events only.

It would be also interesting if you could share one of the missing
events, with sanitized values like the Summary, Description and any
e-mail addresses and such - anything you consider private.

By the way, what evolution(-data-server) version are you using, please?
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


Re: [Evolution-hackers] https://bugzilla.gnome.org/show_bug.cgi?id=756707 alculations of lineno and offset for external editor gvim component is broken

2015-10-20 Thread Milan Crha
On Fri, 2015-10-16 at 13:25 -0400, Reid Thompson wrote:
> this has been an issue for a while, I finally took a few minutes to look
> at it.  If someone can point me to documentation that would explain to a
> webkitgtk novice how things work, i can attempt to generate a patch.
> I've not been able to find docs that would allow me to understand 
> 
>   get_caret_position (EHTMLEditorView *view)

Hi,
just a note that this is not forgotten, we follow-up with this in the
Reid's bug report [1].
Bye,
Milan

[1] copied from the Subject:
    https://bugzilla.gnome.org/show_bug.cgi?id=756707
___
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] EMsgComposer API support for "Send and Archive"

2015-10-08 Thread Milan Crha
On Thu, 2015-10-08 at 10:34 -0500, lib...@acm.org wrote:
> I'm certainly open the idea of contributing this feature
> to Evolution proper, though.  How would we explore this option
> further?

Hi,
simply file an enhancement request against evolution's Composer
component at https://bugzilla.gnome.org and attach your patch against
git master checkout of the evolution there, then it'll be reviewed and
either iterated upon it or just committed into the sources. One common
thing for the new contributors, please follow the used coding style,
thus other contributors can read the code "easily".
Thanks and 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


Re: [Evolution-hackers] EMsgComposer API support for "Send and Archive"

2015-10-07 Thread Milan Crha
On Tue, 2015-10-06 at 23:01 -0500, Ben Liblit wrote:
> I've tested fetching the send activity from the action bar as
> outlined in my earlier message.  It works well, feels clean, and
> requires no changes to Evolution itself.  I'm going to proceed using
> this approach.

Hi,
you are welcome.

By the way, how do you plan to "distribute" your plugin/module? Maybe
it could be part of the evolution sources, a "core" module, or even
better being fully integrated in the composer as a standard
functionality. Maybe.
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


Re: [Evolution-hackers] 5 single backup methods wanted

2015-10-05 Thread Milan Crha
On Mon, 2015-10-05 at 23:07 +0200, rbre gmx wrote:
> I am a meber from evolution-l...@gnome.org where I often asked for:

Hi Ralph,
such questions are user oriented, not suitable for this list. I do not
know why you re-iterate with them here, even in a different form.

> How can I make an single e-Mail export and re import
> How can I make an single Notes export and re import
> How can I make an single contact export and re import
> How can I make an single calendar export and re import
> How can I make an single birthday export and re import

General rule: select set of objects, right-click the selection, pick
"Save as xxx..." option. Other than Mail view offers also context menus
on Books/Calendars/..., where is also "Save as...", which saves
everything in that Book/Calendar/... into a file. This method requires
running evolution. Then import it with File->Import->Single file->

> I want to move the e-mail data by hand
> I copied the mail folders manually
> I copied the folders.db manually
> but it does not appear
> is there an API or a way to make it by hand

I think this had been answered on the evolution-list. It appears from
time to time repeatedly there, just search the archive for more
detailed response. The short answer is: Create a new mail account of
the correct type (Maildir, mbox, ... I do not know what you moved
manually), then point that new account to that backup folder with the
messages and then copy the messages from one account to the other. As
always, playing with internal evolution files is not a good idea,
unless you really know what you are doing - thus the message copy/move
is suggested from within the evolution.

In any case, please do not follow this here, move to the
evolution-list, where you can get better answers from users whom might
be in a similar situation as you are, thus they can give you real life
answers.
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


Re: [Evolution-hackers] EMsgComposer API support for "Send and Archive"

2015-10-05 Thread Milan Crha
On Mon, 2015-10-05 at 20:10 -0500, Ben Liblit wrote:
> Is there any possible race condition under which the activity might
> complete/cancel and go away before I have an opportunity to grab it
> like this?  Or is there a race condition under which some *other*
> activity might be set as the activity bar's current activity before I
> can grab this one?

Hi,
I'm not aware of any such race condition off head. As the composer and
the related parts are widgets, they operate these changes in the main
(UI) thread, which gives a thread safety.

> I like this!  Unless you think there's a race lurking in my code to
> fetch the current EActivity, this seems to give me everything I need
> with *no* API changes at all.

I also think it is fine, and the direct get of the activity as you
outlined above is even nicer than checking with notification signal on
the activity bar.

> I don't quite understand your "double asked" concern.

I thought of not copying the e_msg_composer_send() yourself, but just
emitting the "presend" signal to check whether the message will be send
or not. Forget it, maintaining the copy of that function is not a good
option, it's just an option :)

> I agree that we should not ask existing callers to g_object_unref() a
> return value that they previously did not expect to see at all.  If
> we believe that ignoring this return value will be the common case,
> is it reasonable to return the EActivity *without* increasing its
> reference count accordingly?

Yes, I'm just used to thread safety issues with references, though it
doesn't apply here (see above the note about the main (UI) thread).

> That would work for me provided we have some strong guarantee that no
> other send can appear in the middle, as in:

The send within one composer cannot interleave, because the composer
disables most of the UI while processing the send.

The solution with added signal is the clean way of achieving what you
want. All the above is doable, but a little hacky. If you are fine with
the current way, then even better, otherwise I can add the signal and
you can use it conditionally (using g_signal_lookup()), or create your
plugin only for 3.20+.
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


Re: [Evolution-hackers] EMsgComposer API support for "Send and Archive"

2015-10-05 Thread Milan Crha
On Sat, 2015-10-03 at 17:21 -0500, Ben Liblit wrote:
> (A good start might be for e_msg_composer_send()
> to return the EActivity it creates: this exactly represents the
> current send attempt and could be monitored for status changes.)

Hi,
you are right, there is no good (and direct) API to achieve what you
want right now. There is an indirect API. The EMsgComposer::busy
property gives a status whether the composer is doing anything. Looking
into the implementation of the busy state change, the code relies on
the EActivityBar notifications, which gets to the EActivity.

Your "Send & Archive" method might look like this (pseudo-code):

static void
action_send_and_archive_cb (GtkAction *action,
    EMsgComposer *composer)
{
html_editor = e_msg_composer_get_editor (composer);

activity_bar = e_html_editor_get_activity_bar (editor);
g_signal_connect (
activity_bar, "notify::activity",
G_CALLBACK (composer_sent_and_archive_notify_activity_cb), 
composer);
e_msg_composer_send (composer);
}

Where in the composer_sent_and_archive_notify_activity_cb() you'd get
to the activity and you'd disconnect from the "notify::activity"
signal.

It's still not good, because the e_msg_composer_send() can finish
without running any activity, and it can wait for a user confirmation
for an unknown time.

The only current feasible way seems to me the code duplication, copy
the implementation of the e_msg_composer_send() into your plugin (with
other necessary parts) and call that, instead of calling
e_msg_composer_send(). You cannot invoke EMsgComposer::presend signal
before calling e_msg_composer_send() to verify whether the message will
be send or not, because, if any signal listener asks users for
anything, that could be double asked.

I do not think returning an EActivity from e_msg_composer_send() is a
good idea. The reason is that it's an API change. The thing is that the
returned pointer should be referenced, thus each call would need to
unref it. That means adding more responsibilities to the caller and
other overheads.

What about adding a "postsend" signal? The round trip of signals would
be:
   presend
   send
   postsend
where the postsend will be called always after the send is complete,
successfully or failed. That will also mean an API (ABI) change (the
EMsgComposerClass structure will be larger), but it'll not add any
additional requirements for the callers.

What do you think?
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


Re: [Evolution-hackers] Query Evolution's Calendar Data storage location

2015-09-14 Thread Milan Crha
On Sun, 2015-09-13 at 16:41 +0200, Tom wrote:
> I need any method to query Evolution data.

Hi,
okay. Do you need it from within the Evolution or from a 3rd-party
application?

> I assume that using the Evolution 3.x series, I happen to find the
> calendar data in ~/.local/share/evolution/calendar/system ?
> Is the calendar.ics file all that's containing data ?
> Should I be able to find and filter calendar data there ?

Well, all the above depends on the calendar type. In any case, you
shouldn't access those files directly, rather connect to the calendar
through the evolution-data-server interface. The structure you are
looking for is the ECalClient.

> Is here anyone aware of a method to query the calendar data for some
> kind of result to 'select all entries where category=studienkreis' or
> 'select all entries where summary contains / is like "thisname"' ?

Again, from within the Evolution, or from a 3rd-party application? 

Within the Evolution, choose menu Search->Edit saved searches and add
there the search you are interested in. Then just pick it from the
Search menu and you'll get the result. Note there is always applied a
time constraint, but you can search forward and backward with the top-
right arrows beside the Search field above the calendar view.

In case of a 3rd-party application, you can get some inspiration with
these source tests:
https://git.gnome.org/browse/evolution-data-server/tree/tests/libecal/c
lient/test-cal-client-get-object-list.c

https://git.gnome.org/browse/evolution-data-server/tree/tests/libecal/c
lient/test-cal-client-get-view.c

The difference between one-time query with get_object_list() and the
view is that the view is a live view, aka if the calendar receives a
new event which is part of the view then you'll be notified with
certain signal, the same for removal from the view (when it doesn't
conform to the given filter anymore) and for event modifications.

> It needs to be run on more than 1 PC, so please don't ask for
> Evolution version, there are many from 3.2 to 3.actual I guess.

The availability of the above search arrows depends on the Evolution
version, somehow. And it's possible that some changes meantime (the gap
between 3.2 and 3.16/3.18 is really huge) may make your filters work
better with newer version.
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


Re: [Evolution-hackers] [PATCH evolution-data-server] build-sys: bump minimum sqlite version to 3.7.17

2015-08-04 Thread Milan Crha
On Tue, 2015-08-04 at 11:30 +0300, Tanu Kaskinen wrote:
 -m4_define([sqlite_minimum_version], [3.5])
 +m4_define([sqlite_minimum_version], [3.7.17])

Hi,
thanks for the patch. That's a nice catch. Even I prefer patches as
attachments, the best in GNOME's bugzilla, then this one is trivial
enough to be committed.

Created commit 3780eff in eds master (3.17.90+) [1]
Created commit 8b2c2b8 in eds gnome-3-16 (3.16.5+) [2]

Bye,
Milan

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=3780eff
[2] https://git.gnome.org/browse/evolution-data-server/commit/?id=8b2c2b8
___
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: WebDAV] Get list of all calendars for user

2015-05-14 Thread Milan Crha
On Thu, 2015-05-14 at 13:31 +0200, Alexis Maiquez Murcia wrote:
 -Is there any way to retrieve a calendars list with libedataserver
 for WebDAV-based users?

Hi,
there was added this very recently in the code [1], only the
development version contains it, thus it'll be part of the
evolution-data-server 3.18.0.

There is one special issue with the Google server related to shared
calendars added by the user in the Google's Web UI. To have them
advertised also with the WebDAV discovery the users should enable them
for it first. Erick, a gnome-calendar developer, found this here:
http://stackoverflow.com/questions/25669144/google-caldav-access-to-shared-calendars
which mentions a direct URL for the setting here:
https://www.google.com/calendar/syncselect

Please note that it's a special behaviour of Google, it has nothing to
do with evolution-data-server or any other client using WebDAV/CalDAV.
Of course, Google's API doesn't need any such setting.

 -Is there any specific way to connect to Google Calendar through 
 libedataserver and sync those calendars too? (the WebDAV method is 
 considered insecure by google)

I'd not say they consider the CalDAV method insecure, it's the
authentication type, plain/password, which they consider insecure and
may abandon in the future. Evolution-data-server's CalDAV calendar
backend can use OAuth2 token, but evolution itself doesn't know how to
get to them in other way than by asking GNOME Online Accounts for it.
That means, if your application will be able to provide OAuth2 token to
the evolution-data-server, then you can use it and it'll work. I'm only
afraid that you'd need to write some external module for evolution
-source-registry, similar to [2], to be able to do it.

The CalDAV URL also changes when using the OAuth2 token, it's located at:
  apidata.googleusercontent.com/caldav/v2/user-email/events/
instead of
  google.com/calendar/dav/user-email/events/

Hope it helps,
Milan

[1] 
https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-webdav-discover.h

https://git.gnome.org/browse/evolution-data-server/tree/libedataserverui/e-webdav-discover-widget.h
[2] 
https://git.gnome.org/browse/evolution-data-server/tree/modules/google-backend

https://git.gnome.org/browse/evolution-data-server/tree/modules/gnome-online-accounts
___
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] Memory usage

2015-03-25 Thread Milan Crha
On Tue, 2015-03-24 at 22:53 +, David Woodhouse wrote:
 Is there a decent way to reliably track *all* memory usage within a
 GNOME application? Am I doing something wrong?

Hi,
I'm afraid that might be better to ask on a general mailing list, I do 
not think many people here know much about the internals. Or at least I
do not know.

 Hm, I note that I'm up to 9 WebKitDOMRange objects now I've 
 almost finished typing this...

I guess that's the main difference from the 3.12.x. The 3.12.x still 
uses a GtkHTML in the composer, while the 3.16.x uses WebKit there. 
The WebKitGTK+ itself is supposed to free some of the objects on its 
own when it is destroyed, aka when the composer is closed. Till then 
the objects are kept in their cache. You know the WebKit bug [1], from 
yours [2]. Try to convince them to backport the changes into WebKit1 
and do a release, though I was told that the plan is to make a release 
within the next few weeks, together with the backport.

Tomas may look in the composer code and check the usage of the 
WebKitDOMRange objects, whether they are properly freed, and whether 
they should be freed (there are cases where the leak fixes in 
evolution caused issues due to freeing objects which should be left 
around in the WebKit's DOM object cache). There are those CSS objects 
too, the second item in your .png, which looks suspicious too.

I really do not think we can do anything more on the Evolution side, 
all (most of) that is on the WebKit side. The port to WebKit2 can make 
a difference in some way, especially due to the related leak fixes 
being already there, but porting Evolution to WebKit2 is not a trivial 
task.
Bye,
Milan

[1] https://bugs.webkit.org/show_bug.cgi?id=118788
[2] https://bugzilla.gnome.org/show_bug.cgi?id=744401
___
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] Back on 6-months release cycle and sync version with GNOME 3.16

2015-02-19 Thread Milan Crha
Hello,
the Evolution (and evolution-data-server, evolution-ews, evolution-mapi)
made their 3.12.x/3.13.x as a year release cycle and they got out of 
sync with the GNOME versioning as well. It was good for the major 
Evolution change, the movement to WebKit-based composer. I believe
the extra months (the change landed in time of 3.13.3) helped to polish
the composer and make it even more usable than it was in the initial 
commit time.

The last development release version was 3.13.90, together with
GNOME 3.15.90. The release schedule is currently in sync with GNOME 
and, after couple discussions, I'd like to return back to versioning 
of GNOME, the same as to the same release schedule. There still can be 
done extra stable releases like in time of the Evolution 3.12.x. A 
monthly release cadence seemed to be good for users too.

That said, Evolution core products will completely skip 3.14.x version 
series and will jump straight to 3.16.x. The next development release 
was planned to be 3.13.91, but it'll be the same as GNOME,
thus 3.15.91. The stable branches will follow the previous pattern, 
that is gnome-3-16 for the 3.16 version (Evolution 3.12 series used 
evolution-3-12 stable branch).

It doesn't mean there are not planned any other significant changes, 
they just might not be that huge like the WebKit-based composer.

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


Re: [Evolution-hackers] Address book merging

2015-02-19 Thread Milan Crha
On Thu, 2015-02-19 at 12:49 -0300, Renato Araujo wrote:
 I have a small backend[1] with only the constructor function 
 implemented where I try to start a view from others sources to 
 confirm the problem. Should I report a bug or I am doing something 
 wrong on my code?

Hi,
please do not top-post, and trim the reply as appropriate here. Thanks.

I briefly read your e-book-backend-aggregator.c and I do not see 
anything obviously odd there. The best step forward would be to 
install debuginfo package for evolution-data-server and reproduce the 
block of the e_book_client_view_start(), then get a backtrace of the 
running (currently blocked) evolution-addressbook-factory process, to 
see where it got stock and eventually figure out why. One way of 
getting the backtrace is for example with this command:
   $ gdb --batch --ex t a a bt -pid=PID bt.txt
where PID can be `pidof evolution-addressbook-factory`

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


Re: [Evolution-hackers] Address book merging

2015-02-18 Thread Milan Crha
On Wed, 2015-02-18 at 16:30 -0300, Renato Araujo wrote:
 Could you guys help me with that? 

Hi,
I wasn't sure what kind of merge you have on mind. I can think of a 
real contact merge, like when adding a new contact to an address book 
and searching for a similar contact (like based on e-mail) and 
eventually ask a user to merge the newly added contact with an already 
existing. Or, the other merge kind, is to gather contacts from 
multiple books and show them all in one long list (I have configured 
really many books, and some contains thousands of contacts, thus your 
application should count with it; there are also company books with 
hundreds of thousands of contacts).

I then realized, after reading your email, that you most likely need 
to do the second kind of the merge, provide contacts from multiple 
books in once source.

 Is this idea too crazy?

No, it isn't.

 Do you have any other idea to have contact from different address-
 book merged in EDS? 

It's what the ENameSelector from evolution does. It's used for auto-
completion and it picks all books configured to be part of the auto-
completion and searches for available contacts in all these books at 
once. Check the ENameSelectorEntry [1] and EContactStore [2], the 
later is that what gathers contacts from the books.

 Is possible to use client API inside of the backend implementation?  
 (How?)

Yes, it is. Check the Birthdays  Anniversaries calendar code [3], it 
also uses books. It can be a little issue to ask for clients in the 
server side which provides those clients (you ask to open a book in a 
book backend, which wants to talk to the book factory, thus to 
itself). You might be also careful which thread you block with your 
client open. If you block the main thread of the factory, then any 
attempt to contact it, by any client, will cause timeouts.

 Which is the best solution to get access to others addressbook from 
 my backend implemation?
 

See the answer for the previous question.

Hope it helps,
Milan

[1] https://git.gnome.org/browse/evolution/tree/e-util/e-name-selector-entry.c
[2] https://git.gnome.org/browse/evolution/tree/e-util/e-contact-store.c
[3] 
https://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/contacts/e-cal-backend-contacts.c
___
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] Presumed bug in parsing attached files

2015-02-10 Thread Milan Crha
On Sun, 2015-02-08 at 10:28 +0100, Nico Rikken wrote:
 I came across a set of e-mails in which an xml-file was attached, 
 and although it was recognised by Mailman (only for subscribers) and 
 was available in the sourcecode of the email (base64-encode), 
 Evolution 3.12.9 in Evolution testing wasn't able to extract the 
 attachment, although it did mark the emails with an attachment-icon.

Hi,
it looks to me like [1], which was fixed just yesterday [2] for the 
3.13.90 development version. More details on the links.
Bye,
Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1187327
[2] https://git.gnome.org/browse/evolution/commit/?id=a4af2d6aeef

___
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 3.12.x series is over

2015-02-09 Thread Milan Crha

Hello,
I'd like to inform you that the Evolution 3.12.x series is over. That 
means, I do not plan to do any further releases from evolution-data-
server-3-12, evolution-3-12, evolution-ews-3-12 and evolution-mapi-3-
12 branches of the respective modules after the final (today's) release
of 3.12.11.

I noticed that there are still changed translations and such, thus 
take this as a heads-up to not waste your time on these (now) 
effectively dead branches and focus on the master branches instead.
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


Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)

2015-02-05 Thread Milan Crha
On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote:
 The other follow-up work will be to adapt any clients and 
 libraries which might be affected by this change.

Hi,
I've only a little note, I wrote proposed changes for gnome-contacts 
to enable client-side authentication in it at [1]. A similar change 
can be used in any client which wants to answer authentication 
requests. As the gnome-contacts uses only address books, then the 
authentication requests are enabled only for them and their parent 
(credential) sources (search for E_SOURCE_EXTENSION_ADDRESS_BOOK in 
the patch), all the other sources' authentication requests are ignored.

I hope this will make things easier for others.
Bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=743979#c0
___
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 authentication of backends back to the client (3.13.90)

2015-02-02 Thread Milan Crha
Hello,
I just committed a change, for 3.13.90 development version, into 
evolution-data-server [1], evolution [2], evolution-ews [3] and 
evolution-mapi [4], which moves authentication back to the clients. 
That is, any credentials (password) prompts are done fully 
asynchronously on the backend side, and the clients are responsible to 
provide the credentials. There is one exception, if the credentials 
are already saved, then they are used first, without any communication 
between the backend and the clients.

This is done in a very similar way as it used to be couple years ago, 
except the notifications about credentials requests and 
authentications responses are handled on top of ESource objects. I 
chose the ESource object, because it already manages password saving 
and because some backends, those on the source registry side, cannot 
be accessed in any different way. There is also a proxy in EBackend, 
which works on top of the ESource methods and signals, making things 
easier for the backend implementators. The backend proxy also makes 
couple things for free, based on the existence of certain ESource 
extensions, which are updated accordingly during the authentication 
process. The extensions are E_SOURCE_EXTENSION_AUTHENTICATION and 
E_SOURCE_EXTENSION_WEBDAV_BACKEND. The first is updated when the 
received credentials contain also user name, the second is updated 
with a trust prompt results, which are also passed into the backend as 
part of the credentials. That's required, because the change on the 
ESource can be propagated to backends too late, due to the round-trip 
from the client to evolution-source-registry, and only then to the 
factory, while the client talks to the factory directly.

The backend open and the authentication process currently looks like:

client-side| D-Bus |backend-side
---
 e_client_open()   |  | ECal/BookBackend::open() 
is called:
   |   | a) either set 
ESource::connection-status to CONNECTED
   |   | b) or try to connect to 
the server without credentials
   |   |and use 
e_backend_credentials_required/_sync() or
   |  |
e_backend_schedule_credentials_required() to broadcast
   |   |a request for 
credentials to any client listening
   |   |
 listener of ESource::credentials-requ |   |
 ired signal can ask for actual|   |
 credentials a user and send them back |   |
 with e_source_invoke_authenticate()   |   |
   |  | implement 
EBackendClass::authenticate_sync() to receive
   |   | and use the provided 
credentials. Based on the result
   |   | of this function is 
updated ESource::connection-status
   |   | automatically and the 
output arguments are used to
   |   | iterate with 
e_backend_credentials_required() again
   |   |

The main differences from the pre-this-change behaviour are:
a) the backend can open without being connected to the destination
   (possibly remote) data store
b) the ESource::credentials-required signal is delivered to all
   current listeners of evolution-source-registry, not only to the one
   which requested the open of the backend
c) the backend works with the new ESource::connection-status in its
   open() implementation only, as long as it uses the provided proxy
   functions on the EBackend master class.

As mentioned above, the credentials-required reasons also contain an 
SSL failures (aka when the destination server certificate checking 
fails for some reason), which allows to tight the Trust Prompts to the 
clients as well, thus they are not shown out of blue in the system 
anymore.

I re-introduces libedataserverui library, which holds structures to 
handle credential prompts and show the trust prompts directly in the 
application's UI. The library is built conditionally, only when the 
GTK+ is available.

The easiest way to implement credential prompt in an application is to 
create an ECredentialsPrompter and let it live for a whole time of the 
application. It listens for ESource::credentials-required signal and 
responds only to REQUIRED and REJECTED reasons. There can be disabled 
this auto-prompt, either globally or for respective sources. This 
credential prompter also listens for ESource::connection-status 
changes and cancels any ongoing prompts when it changes. That's one of 
the reasons why the 

Re: [Evolution-hackers] Unable access to online reference manuals

2014-12-21 Thread Milan Crha
On Sun, 2014-12-21 at 19:22 -0500, Phil (list) wrote:
 I was digging around the Evolution wiki (
 https://wiki.gnome.org/Apps/Evolution/) and am not able to access 
 any of the links under 'Reference Manuals' (Forbidden)... a 
 configuration problem for these pages?
 

Hi,
thanks for the notice. You are right, the links are incorrect. It 
seems to me that the developer documentation stopped generating 
unstable docs, which made the links unavailable. For example the
   http://developer.gnome.org/camel/unstable
may point to one of the subpages of
   https://developer.gnome.org/camel/
I will let it point to this navigation page, rather than update the 
links each major release. I would forget of it for sure.
Thanks again and 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


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

2014-10-29 Thread Milan Crha
On Mon, 2014-10-27 at 10:00 -0700, James Bottomley wrote:
 OK, I reopened it as incomplete.  You can't close it as FIXED when it
 isn't upstream in the gnome tree because that's going to cause 
 massive
 confusion: a package maintainer reading the bugzilla list is going to
 think they're getting the fix from the 3.10 branch when, in fact,
 they're not.  If there's some reason not to incorporate the distro 
 patch
 into the 3.10 fixes branch, then close it as WONTFIX with reference 
 to
 the distro patch.
 

Hi,
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.
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


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

2014-10-27 Thread Milan Crha
On Sat, 2014-10-25 at 11:53 -0700, James Bottomley wrote:
 It looks like the recently released openssl 1.0.1j breaks evolution 
 by
 causing it to have no overlapping cyphersuites.  I've created a bug 
 for
 it here:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=739179
 
 But it needs fixing as a matter of urgency, since this is the version
 most desktop distros ship and with heartbleed it won't take long for 
 all
 the imap clients to be upgraded to this version.
 

Hi,
I closed the bug, the fix is referenced from:
https://mail.gnome.org/archives/evolution-list/2014-October/msg00113.html

As I wrote in the bug, you should ask the evolution-data-server 
maintainers in your distribution to include the fix.

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


Re: [Evolution-hackers] Evolution Has Regressed Considerably

2014-10-27 Thread Milan Crha
On Sat, 2014-10-25 at 06:09 +0100, Onyeibo Oku wrote:
 Hi
 
 I'm running Fedora Rawhide with Evolution 3.13.6-1.fc22
 
 Is it just me or has Evolution regressed to a point that its almost 
 unusable  (especially with mobile broadband)?

Hi,
it depends on the actual backtrace of the running/stuck evolution.
I guess you face this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=712392
also because there really didn't change much in this regard in 
evolution between 3.13.5 and 3.13.6. The fix is included in today's 
3.13.7 release, together with other semi-related fixes. It'll be 
available in Fedora's rawhide within the next few hours.

 I see lots of progress notifications at the status bar in Evolution. 
  They grow, ... and grow until there's no space to contain the new 
 notifications.  The clutter is disheartening.  The newest bizarre 
 status is the Unknown background operation.  What is that?

Unknown is unknown, the operation didn't identify itself yet. 
Backtrace matters here, but I'd guess this is related to server 
address resolutions (it uses to be), thus also related to the above 
bug.

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


Re: [Evolution-hackers] evo build problems

2014-10-13 Thread Milan Crha
On Sat, 2014-10-11 at 19:51 +0200, schaarsc wrote:
 Hello,
 
 in case someone else has missing symbols (floor, gnome_canvas...)
 
 I was able to work around the issue with
 

Hi,
thanks for the heads up. I'd like to know the different flags your 
distro/build is using that these things are easy-to-get there. In any 
case, I committed something similar to your proposed change here:
https://git.gnome.org/browse/evolution/commit/?id=c20c593

Thanks again and 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


Re: [Evolution-hackers] lookup S/Mime encryption certificates over LDAP?

2014-10-09 Thread Milan Crha
On Thu, 2014-10-09 at 13:48 +0200, RHE wrote:
 Sounds great! Just found the code - it was submitted @ Sept. 2...
 ...based on your experience as GnomeDev, how quick can we expect to 
 have this module released within the application? (devel || stable) 
 ...based on wiki info you have a monthly release schedule - or do 
 you might have NightlyBuilds on this already?

Hi,
the monthly release is correct. I'm not aware of any nightly builds, 
they are not done by the Evolution team for sure. I'm not sure whether 
this will reach 3.12.x (stable), but it should reach the development 
version (3.13.x) soon. If I'm not mistaken, then the merge is awaiting 
for some fixes on the EWS side and then on a final review from dwmw2.

 I guess Yumma or Dwmw are members of this list too, aren't they? 


The should be, but just in case I added them to CC now.

 Whats the current status?
 Would be happy to test this in my Employers secure mail 
 environment...

   Is there any eMail/Groupware client for Linux systems out there 
   that
   supports Exchange-EWS Connectivity and S/Mime incl. certificate
   (PublicKey) lookup from LDAP..?
  
  When using EWS, evolution connects to the addressbook also with 
  EWS,
  not with LDAP, but as I said above, it doesn't matter much, because
  Yumma's module searches in all [1] configured address books.
  Bye,
  Milan
  
  [1] I didn't touch the code myself, neither review it, but I guess
  it's all configured books with enabled autocompletion or 
  something
  like that.

 I expect it that way... for my case its important to be able to get
 certificates from an additional LDAP Adressbook (besides those coming
 from Exchange over EWS).


You might check whether evolution-data-server reads the certificate 
from your LDAP server. I briefly looked into the code and it seems 
like it should read the information from a userCertificate LDAP 
attribute.
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


  1   2   3   4   5   >