On Mo, 2011-05-16 at 08:11 +0200, Milan Crha wrote:
On Fri, 2011-05-13 at 15:44 +0200, Patrick Ohly wrote:
In libebook, I get a Timeout was reached because the asynchronous
operation doesn't complete quickly enough. Same for the attempt to
delete the contacts. The gError-code is 24, which
-05-16 at 11:12 +0200, Patrick Ohly wrote:
It might be easier to set DB_INIT_CDB, which enforces multiple
reads/single writer access without deadlocks. I'll give that a try.
And it works beautifully. One word added to the source code and the
stress test passes reliably and quickly :-)
Patch
On Mo, 2011-05-16 at 13:05 +0200, Milan Crha wrote:
On Mon, 2011-05-16 at 11:35 +0200, Patrick Ohly wrote:
And it works beautifully. One word added to the source code and the
stress test passes reliably and quickly :-)
Patch attached. Okay to submit into master (not tested there, though
On Do, 2011-05-12 at 13:17 +0200, Milan Crha wrote:
On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote:
I found this in e-data-cal-view.c notify_remove():
280 /* TODO: store ECalComponentId instead of just uid*/
281 uid = g_strdup (id-uid);
282
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
I'll do it as uid[\nrid] so that entries without an rid continue to
look exactly like the current ones.
Looks good. I ran my KCal-EDS test program which adds, modifies and
removes events, including parent and child (= detached recurrence
On Do, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote:
Attached the resulting patch. Note that with the patch applied, all new
contacts in a Berkley DB get the simpler IDs, unconditionally. Older
contacts continue to use their existing IDs. Would something like this
be acceptable upstream?
Any
On Di, 2011-05-17 at 18:49 +0530, Chenthill wrote:
On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote:
| Further work if you agree in principle:
| * let clients query whether all contacts have the simplified ID -
|could be done with the dynamic capabilities that I mentioned
On Di, 2011-05-17 at 16:25 +0200, Milan Crha wrote:
On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote:
I'm not sure if I got it right, but such workarounds are just wrong from
my point of view. You cannot force servers to use certain types of IDs
because of constraints given by application
On Mi, 2011-05-18 at 07:34 +0200, Milan Crha wrote:
On Tue, 2011-05-17 at 17:19 +0200, Patrick Ohly wrote:
On Di, 2011-05-17 at 16:25 +0200, Milan Crha wrote:
On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote:
I'm not sure if I got it right, but such workarounds are just
wrong from
irrelevant in the context of such
comparisons (unfortunately).
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
---BeginMessage---
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
I'll do it as uid[\nrid] so that entries without an rid continue to
look exactly like
the corresponding D-Bus signal is not delivered
(seen in older EDS releases, not sure how relevant it is on master).
As Alexander said, the synchronous API serves a useful purpose.
SyncEvolution is one, simple tests another. +1 for keeping it and fixing
it so that it really works.
--
Bye, Patrick Ohly
=651970
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
once is acceptable. Whether it is in 3.2 or 3.4 I don't really
care.
But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So
if the account handling doesn't land in 3.2, then please let's keep the
current (EDS 3.0) APIs officially supported in 3.2.
--
Bye, Patrick Ohly
On Di, 2011-06-14 at 07:38 -0400, Matthew Barnes wrote:
On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote:
My two cents as a user of these APIs: having to deal with a major API
change once is acceptable. Whether it is in 3.2 or 3.4 I don't really
care.
But having to rewrite code
.
Upstream libical used to have a bug around that. It should be fixed in
0.44. I don't know whether Evolution itself still has it wrong
somewhere.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
part.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
apps who want
to do that.
Well... perhaps we should just swallow the ugly race and do nothing
about it and say that:
a uri might be invalid from time to time directly before your view
receives notification of the removal ?
Would that be acceptable ?
Yes.
--
Bye, Patrick Ohly
even if those had inline data.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman
On Fri, 2011-07-08 at 10:42 +0100, Burton, Ross wrote:
On 7 July 2011 09:48, Patrick Ohly patrick.o...@gmx.de wrote:
At any rate, if it's judged that the performance gain of using
a staging directory is worth the added complexity then let's do it.
I'd like to hear some other opinions
that it supports a list of
protocols for staging data (such as 'file','http','ftp' etc) ?
The staging dir would be, by definition, local. I don't think we should
support anything else.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
blob to...
b.) If the incoming photo is a binary blob or
a uri inside the staging directory...
I agree. We can always do another iteration if the D-Bus overhead for
storing photos becomes important.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de
was related to broken comma handling in
libical, which caused two categories to be stored as
CATEGORIES:abc\,xyz
although the RFC specifies a simple comma as separator.
Later libical was changed, which now seems to cause the current problem.
Has anyone noticed this before?
--
Patrick Ohly
is supported
and to upload data.
Perhaps this is not so very complex after all ?
I think it is doable.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list
the real problem. The real problem is more likely to be in the
matching against RECURRENCE-ID.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list
On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote:
On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote:
On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote:
Milan, can you shed some light on why the patch solves #655253? I fail
to see what e_cal_backend_file_modify_object() has to do
On Di, 2011-09-13 at 17:59 +0200, Patrick Ohly wrote:
On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote:
On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote:
On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote:
Milan, can you shed some light on why the patch solves #655253? I fail
it?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote:
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend.
Is it also possible for other backends? Or are some unable to store
the UID
On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote:
Hi everyone,
Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha:
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend
of it, even if it is just for experiments.
For more details, see the TODOs on ad-hoc synchronization in
http://syncevolution.org/blogs/pohly/2011/state-union-version-12
On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly:
On Di
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly:
Hello!
[...]
On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
If a new UID is to be created, it is the responsibility of the Kolab
client to
assign
the merge or accepting some kind of unreviewed merging
again: merge A+B = C gets reviewed, A' + C does not, which might be okay
if the delta between A and A' is small and does not lead to further
conflicts with C.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de
On Mon, 2011-11-28 at 10:59 +0100, Milan Crha wrote:
On Mon, 2011-11-28 at 10:15 +0100, Patrick Ohly wrote:
On Mon, 2011-11-28 at 08:27 +0100, Milan Crha wrote:
Hi,
I just realized a very sad thing, the history of certain files is gone
after the merge of wip/gsettings branch
in
the APIs.
Or do I miss something?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman
On Tue, 2012-02-14 at 08:45 +0100, Milan Crha wrote:
On Mon, 2012-02-13 at 21:52 +0100, Patrick Ohly wrote:
* A second invocation of SyncEvolution finds the definition of the
system address book via e_book_get_addressbooks() and tries to
open it with e_book_open(only_if_exists
?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
, of course I intend to fix the bug in the Synthesis
engine.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http
On Sat, 2012-03-03 at 13:26 +0100, Patrick Ohly wrote:
It removes the check for evc-priv-attributes. Adding that check back
fixes the problem.
Attached is the patch. I must admit that I'm not up-to-date about
release plans. From Matthew's email I gathered that there will be a
release on Monday
On Tue, 2012-03-06 at 14:33 +0100, Patrick Ohly wrote:
Hello!
Checking the EDS daemons from master under valgrind found this:
# ==23596== Conditional jump or move depends on uninitialised value(s)
# ==23596==at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596
peers (client or server).
But note that the current code is in C++ and depends on additional
libraries that are not currently part of the GNOME stack (libsynthesis,
libneon for offline CalDAV/CardDAV). Rewriting it in pure C+GNOME would
be a lot of work.
--
Bye, Patrick Ohly
--
patrick.o
the one you found). I rather install into a
directory that I can wipe out entirely, or use checkinstall.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list
check in
e_cal_client_tzlookup() more liberal and ignore all E_CAL_CLIENT_ERRORs.
The latter might be easier, in particular considering that multiple
different calendar backends might need fixing to reliably return
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
these formatting helps
from Evolution, including saving of drafts with this markup.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized
.
But, while we do have:
e_source_get_extension() e_source_has_extension()
I'm not seeing:
e_source_add_extension()
_get_extension() adds the extension implicitly.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de
list
of capabilities - will be difficult to keep up-to-date
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit
of contacts parameter. Without sorting, that value is useless
because is not predictable which contacts will be included in the
result. With sorting, it becomes possible to populate a fixed-size view
without having to receive all results.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http
to avoid any confusion - does not use EDS at the moment and might never
do. I'm bringing it up as an example of a distro where compiling EDS is
hard at the moment because of the GTK dependency - there might be other,
similiary limited platforms.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http
.
For example, in an early draft of vCard 4.0 the set of characters which
needed quoting was defined differently than in 3.0. This was reverted
back to the rules from 3.0 later on to enhance backward compatibility,
but it might as well have stayed in the spec.
--
Bye, Patrick Ohly
--
patrick.o
breaks.
Matthew, can you elaborate what that break is?
I've looked at a diff of the header files, but most of it is just
reformatting. If there is an API break in there, then I missed it.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de
On Thu, 2014-01-02 at 08:22 -0500, Matthew Barnes wrote:
On Thu, 2014-01-02 at 11:30 +0100, Patrick Ohly wrote:
I just noticed that libecal bumped its soname to libecal-1.2.so.16 in
EDS 3.10. The corresponding commit is:
commit f30ae26320b359666b345c92405bf87f3f43250a
Author: Matthew
On Wed, 2014-02-12 at 15:27 +, Potrola, MateuszX wrote:
Hi,
Regarding your specific issue - it's probably working the same way in
master as in the branch - my guess is that this is due to D-Bus property
changes being delayed until the main loop is hit.
It may be that a simple call
On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote:
In my project I’m using EDS as backend for storing contacts
synchronized using Syncevolution.
I would like to have ability to receive some kind of notifications (or
store information in some additional database) about modifications
On Wed, 2014-04-16 at 12:23 +0200, Milan Crha wrote:
On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote:
I would like to have ability to receive some kind of notifications (or
store information in some additional database) about modifications
made to contacts database during
On Fri, 2014-04-11 at 12:18 +0200, Patrick Ohly wrote:
Hello!
Both Google and Apple support custom labels for basically all of a
contacts properties (telephone, email, address, instant messaging, etc).
They use group tags to associate the extra label with the property:
item4.ADR:;;custom
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote:
Hello,
maybe you noticed that we have a GSoC project for this year, to enable
introspection for calendar part of evolution-data-server (libecal),
which will make it usable for other languages as well.
As said already, doing this as
On Fri, 2014-05-23 at 15:58 +0200, Milan Crha wrote:
On Fri, 2014-05-23 at 14:56 +0200, Patrick Ohly wrote:
I went ahead with the X-ABLabel as parameter approach.
Hi,
I'm sorry you didn't get any answer for this thread. I always forgot of
it, also due to not having much opinion
On Mon, 2014-05-26 at 07:38 +0200, Milan Crha wrote:
On Sun, 2014-05-25 at 21:41 +0200, Patrick Ohly wrote:
Instead if just the pre-defined Work, Home, Other, etc., the user
can also enter arbitrary text. For example, instead of Other Tel: foo
the user can enter Vacation Tel: bar
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote:
On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote:
What I would prefer instead of the additional int parameter is a
string-variant hash with a list of keys which can be extended in
the future without breaking the API. Old clients
101 - 160 of 160 matches
Mail list logo
