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
.
--
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 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
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 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-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-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 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-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
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
.
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
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
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
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
.
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
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
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
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
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
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
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
, 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
?
--
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 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
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
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
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
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 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
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
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-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
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
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
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
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
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
.
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
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
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
=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
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
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
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 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
Hello Ross!
Can you perhaps comment? You wrote the TODO items below...
On Di, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote:
I also wonder about the objects-removed signal in ECalView. If there
are two events, one with RRULE and one with RECURRENCE-RULE, and both
get removed, should
code that was
never used and tested?
I don't need this feature, I just wonder.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
On Di, 2011-05-10 at 10:23 +0200, Milan Crha wrote:
On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote:
On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
I would expect that with CALOBJ_MOD_THIS it may remove only exact
this
entry when creating a new system address book.
--
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
that is still of
interest for Trunk, given that EClient API will obsolete it for 3.2?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
On Di, 2011-05-10 at 09:34 +0100, David Woodhouse wrote:
On Tue, 2011-05-10 at 10:19 +0200, Patrick Ohly wrote:
It seems that a similar problem exists in libebook if no address books
were created already by Evolution. Chris is seeing such an issue with
2.32.3 in MeeGo.
Oh, tits. I hate
CAL_BACKEND_PROPERTY_DEFAULT_OBJECT
Why duplicate the LOADED/ONLINE/READONLY/CACHE_DIR/CAPABILITIES
properties? They could be defined as common E_CLIENT_BACKEND_
properties.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de
. If there
are two events, one with RRULE and one with RECURRENCE-RULE, and both
get removed, should there be two entries in objects-removed?
I've no idea on this. I'm sorry.
First things first ;-) Let me fix the removal, then look into this
problem here.
--
Bye, Patrick Ohly
--
patrick.o
On Mi, 2011-05-04 at 14:37 +0200, Milan Crha wrote:
Hi,
I'm getting slightly lost what is left and what is under discussion,
thus please let me summarize things here:
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest
On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
I would expect that with CALOBJ_MOD_THIS it may remove only exact
component, for uid + NULL-rid the master object (which implies also all
generated instances) and keep all detached
. If there
are two events, one with RRULE and one with RECURRENCE-RULE, and both
get removed, should there be two entries in objects-removed?
I might be misreading my debug logging, but that doesn't seem to happen.
Before I dig deeper, I'd like to get some feedback on the expected
semantic.
--
Bye, Patrick
/pipermail/meego-dev/2011-April/482731.html
--
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
version no
longer works with new lib)? That's a major pain for people trying to
support multiple distros. Please avoid it whenever possible.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution
On Do, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest that
besides modernizing the API we also take this opportunity to move more
of EBook/ECal into a common core
/qtcontacts-eds
[2]
https://www.qt.gitorious.org/qt-mobility/contacts/trees/master/plugins/contacts/maemo5
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
From 65438bd3c4b706535f83304d94b3c018c8899a5d Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Fri, 18
On Fr, 2011-04-08 at 16:31 +0100, David Woodhouse wrote:
On Fri, 2011-04-08 at 15:31 +0200, Patrick Ohly wrote:
On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote:
Once this passes muster, I'll push these patches (probably *without* the
NTLM bits, if you're looking closely at what I
.
Please consider backporting the fixes for e_cal_new_system_*(). They are
unusable in 2.32.x but I intended to use them soon in MeeGo.
I'm not sure which fixed from the master branch are all needed, I hope
Matthew and Milan can provide a list.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http
for this issue, and how should it be fixed?
--
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
On Do, 2011-04-07 at 10:47 +0200, Patrick Ohly wrote:
Hello!
I noticed that in 2.32/MeeGo, e_cal_new_system_calendar() always creates
a new calendar, although there is already one.
It is defined in gconf as:
group uid=1300454894.7178.0@pohly-mobl1 name=On This Computer
base_uri=local
On Di, 2011-04-05 at 16:26 +0530, Chenthill Palanisamy wrote:
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote:
On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote:
On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly patrick.o...@gmx.de wrote:
Hello!
I have
be good (and probably better) to look into the proposal also here where
the upstream EDS developers hang out.
Comments and help welcome ;-}
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution
file change had been done such that a single = 3.0 check
is enough I wouldn't mind, but it doesn't seem like 3.0 has a libebook.h
(picking just one example).
Is there a chance to add the headers to 3.0 before it gets released?
If not, then I'd prefer to not make this change.
--
Bye, Patrick Ohly
On Mi, 2011-03-23 at 09:05 -0400, Matthew Barnes wrote:
On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote:
How much of a problem is that in practice?
It's getting to be a problem. Seemingly innocent changes to header
files break builds in unexpected ways. Here's a common scenario
whether that is suitable for the tasks that I have in mind
(primarily bug triaging/fixing and updates to track upstream).
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
Hello,
update after chatting with Matthew...
On Mi, 2011-02-16 at 16:59 +0100, Patrick Ohly wrote:
On Mi, 2011-02-16 at 10:40 -0500, Matthew Barnes wrote:
Unfortunately these keys are stuffed with XML blobs which are
difficult
to read in Configuration Editor, but if you scroll
0x77191eb5 in g_main_loop_run () from /lib/libglib-2.0.so.0
#13 0x77ffc51f in main (argc=value optimized out, argv=value
optimized out) at e-data-book-factory.c:619
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution
to the home dir before the migration and try
again. Anything that I should watch out for?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options
at a location chose by the user
(file://path uri in the current API)
Is all of that still going to be possible? How?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
-and-time-zones/
--
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
/calendar/gui/alarm-notify where I would expect it to be used
if it was meant to apply to all appointments.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change
working on right now.
Will that break libebook and libecal APIs? The issue only mentions
backends, but the subject of your emails includes EBook and ECal.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote:
On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote:
Will that break libebook and libecal APIs? The issue only mentions
backends, but the subject of your emails includes EBook and ECal.
Hi,
for EBook it is, all the async API
:
excellent choice, sir ;-)
Thanks for bringing this up and taking the feedback into account.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman
On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote:
On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly patrick.o...@gmx.de wrote:
On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote:
On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote:
On Wed, 2009-12-16 at 01:16 +0530, Chenthill
On Wed, 2009-12-16 at 07:50 -0500, Matthew Barnes wrote:
On Wed, 2009-12-16 at 13:18 +0100, Patrick Ohly wrote:
We are debating the merits of the actual mail storage, not the summary
data. I have wiped out folders.db often enough that I won't use
Evolution when it switches to storing
personal Linux installation.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
code:
https://bugzilla.gnome.org/show_bug.cgi?id=562028
Fixed by the Scalix developers recently, available in libical 0.44.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
Hello!
Let's pick up this discussion again. When we agree on the API changes,
then I'll try to follow up with an implementation for the file backend.
On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
Hello Suman!
I forgot to ask: do you agree in general with the plan to do atomic
manually. Without further mangling
of the git format-patch output mails are then send with the send time
stamp equal to the time when the patch was committed to git, which
confuses recipients who sort by time. I made this mistake once and then
switched to git send-email instead.
--
Bye, Patrick Ohly
).
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
1 - 100 of 160 matches
Mail list logo
