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 witho
to a API change) or to not run (due to an ABI/soname
change), because it keeps the option open to run some old software
unchanged.
--
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
On Thu, 2014-09-04 at 18:16 +0200, schaarsc wrote:
> Am Mittwoch, den 03.09.2014, 18:14 +0200 schrieb Milan Crha:
> > it sounds like Patrick Ohly's "[Evolution-hackers] custom labels"
> > discussion [1] from this year's spring. That's much more work than
> > just replace custom widgets with a sto
On Wed, 2014-09-03 at 18:14 +0200, Milan Crha wrote:
> On Wed, 2014-09-03 at 12:55 -0300, Tristan Van Berkom wrote:
> > While we're here, do you think it would be a good idea to
> > migrate away from the hard coded list of vcard labels/ids ?
> >
> > If you're going to redo the UI anyway, it might
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 "Ot
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
>
On Fri, 2014-05-02 at 10:51 +0200, Patrick Ohly wrote:
> I'm still undecided. A too complex X-ABLabel property value could be
> simplified to store it in a X-ABLabel parameter, but that'll drop user
> data.
I went ahead with the X-ABLabel as parameter approach. My gut feeling i
On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote:
> The main problem is that the API returns pointers which are part of the
> structure that you ask the value of it - like when you ask for a
> subcomponent of an icalcomponent. If it exists, you get a child of the
> parent component. This makes a
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:
On Thu, 2014-04-24 at 13:51 +, Potrola, MateuszX wrote:
> > On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote:
> > > This is my prerogative and I can accept that it is not shared with the
> > > maintainers of EDS, nevertheless I would still like to caution against
> > > opening up the
On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote:
> This is my prerogative and I can accept that it is not shared with the
> maintainers of EDS, nevertheless I would still like to caution against
> opening up the SQL tables owned by EBookSqlite to be shared with plugins
> (it may take a
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
; which in case of large number of contacts may unnecessarily increase
> memory consumption, especially as you've said that updates happens
> rarely.
This is a valid concern. Both doing the diff inside the EDS backend (as
part of the write) or in S
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 modificati
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 address
item4.X-ABLabel:custom-label
Does anyone have sugg
On Mon, 2014-03-17 at 09:25 +0100, Tomas Popela wrote:
> Regarding the future of WebKit based Evolution composer I'm proposing
> this: merge webkit-composer branch into master when the 3.12 release
> will be branched and continue to work on it in master branch. This will
> hopefully bring more test
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 sim
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 f30ae26320b359666b345c92
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/
___
evol
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...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
good engineering and
will hopefully also turn out to be useful outside of Tizen, which - just
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 - the
ntacts" 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://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
hard-coded 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 unsubsc
us here, while observing
> the sources e-data-book-factory.c, it seems that if the source
> were given an addressbook extension with the intended backend
> name... that it would happily go ahead and create a book.
>
> But, while we do have:
> e_source_get_extension() &a
lain text emails, but I use 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&
R_OBJECT_NOT_FOUND error when the time zone doesn't
exist and fix it to do so. Or we could make the error 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 m
bably untested, or will fail for
some other reason (like 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
cML 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
--
patric
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-linu
om
crashes.
--
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 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 ther
anding, 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, visi
ck back
fixes the problem.
Question: why does the removed comment only mention UID? Isn't any
contact modification detected by checking evc->priv->attributes?
--
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
familiar to anyone?
--
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
> > ope
mentations and mark it as deprecated 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
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
> > &
that any change on the real branch in the meantime
requires redoing 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,
On Fri, 2011-11-18 at 17:27 +0100, Christian Hilberg wrote:
> Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly:
> > On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
> > > > That is the whole point of this mail thread: a vCard UID may have a
> >
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 responsibil
part 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
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
>
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 s
look up contacts (efficiently) by it? In that case we will have
to relax the semantic of the API and accept that some backends still use
their own local ID. "Supports UID" should be defined as a capability of
the backend so that clients can take it into account.
--
B
option). Can you reopen 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 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 o
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
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 with deleting
> > one occur
only works
around 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 c
t found" errors.
Patches here:
https://bugzilla.gnome.org/show_bug.cgi?id=655986
Chenthill, can you review please?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
nt cannot
> deal with that, then the client should fall back to sending binary
> blobs (whether or not there is a staging directory available, clients
> can continue to send photo data as binary blobs reliably anyway).
>
> In the
ite: the old issue 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?
--
s first and
> then look at the staging directory feature separately, seeing
> that this code will very easily scale from:
> a.) "If the incoming photo is a binary blob" to...
> b.) "If the incoming photo is a binary blob or
> a uri inside the staging direc
URI (from staging dir to final location).
> Perhaps the backend needs to claim 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 an
On Fri, 2011-07-08 at 10:42 +0100, Burton, Ross wrote:
> On 7 July 2011 09:48, Patrick Ohly 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&#x
ents get an URI for their *own*
contacts 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 ...
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
--
patrick.o...@gmx.de
http://www.estamos.de/
___
decided,
also for the "request a staging directory" 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 ..
I'm pretty sure this is wrong.
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/
___
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
> > ca
g 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
--
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
ug.cgi?id=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
eful purpose.
SyncEvolution is one, simple tests another. +1 for keeping it and fixing
it so that it really works.
--
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
storage, but that's irrelevant in the context of such
comparisons (unfortunately).
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
--- Begin Message ---
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
> I'll do it as [\n] so that entries without an rid co
Someone please have a look and provide feedback.
--
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.gno
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 righ
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 con
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 dynami
On Di, 2011-05-17 at 13:27 +0100, David Woodhouse wrote:
> On Tue, 2011-05-17 at 14:04 +0200, Patrick Ohly wrote:
> > On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote:
> > > Even if we *didn't* have immediate plans to use other back ends like EWS
> > >
On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote:
> On Thu, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote:
> > As part of wrapping QtContacts around EDS [1] I ran into the same issue
> > that Nokia already encountered in their Maemo 5 [2] backend: EDS uses
> > strings
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 accepta
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
> I'll do it as [\n] 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 rec
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 =
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 in
2011-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 qu
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
> > dele
On Fr, 2011-05-13 at 12:48 +0100, Ross Burton wrote:
> On 12 May 2011 11:44, Patrick Ohly wrote:
> > Can you perhaps comment? You wrote the TODO items below...
> [snip]
> > I can fix these TODOs. Any objections or concerns?
>
> None whatsoever, those are embarrassingly le
but there's
no reply because the D-Bus server is busy.
I tried the LD_PRELOAD=libeatmydata.so workaround suggested in the mail
above and it does avoid the problem.
Is there anyone around who understand libdb well enough to shed some
light on this? What is a proper fix?
--
Bye, P
dead 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
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
>
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
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
thing 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
create 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://mai
_CACHE_DIR
> CAL_BACKEND_PROPERTY_CAPABILITIES
> CAL_BACKEND_PROPERTY_CAL_EMAIL_ADDRESS
> CAL_BACKEND_PROPERTY_ALARM_EMAIL_ADDRESS
> CAL_BACKEND_PROPERTY_DEFAULT_OBJECT
Why duplicate the LOADED/ONLINE/READONLY/CACHE_DIR/CAPABILITIES
properties? They could be define
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 in
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 rethi
this. I'm sorry.
First things first ;-) Let me fix the removal, then look into this
problem here.
--
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
eem to happen.
Before I dig deeper, I'd like to get some feedback on the expected
semantic.
--
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
natural to refer to containers than items, but
> maybe I'm too indoctrinated in Evolution-speak.
Perhaps it is really to ingrained into Evolution already to change it.
Never mind, I'll cope with it either way ;-)
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
_
a default
> behaviour of returning "something changed" and you'll check items in an
> old way, thus no benefit for it.
Even if it only works with a few backends it would be an improvement for
users of those backends and worthwhile in those cases, in particular if
the file backend supports 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
org/meego-middleware/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
Date: Fr
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 EBo
still
on-going) "put C++ MeeGo APIs on top of EDS" work [1]. I rely on this
implementation detail, please don't take it away.
[1] https://meego.gitorious.org/meego-middleware/kcal-eds
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
__
gether.
Are you saying that a soname version bump can and should be done in a
backwards-incompatible way (= code compiled against older 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 Oh
re/planning/evolution-data-server/eds-improvements#quick_check_for_.22data_changed.22
[2] http://lists.meego.com/pipermail/meego-dev/2011-April/482731.html
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers maili
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
32.3
> candidate bugs/patches.
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, Patri
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:
>
> base_uri="local:" readonly="
1 - 100 of 221 matches
Mail list logo
