On Thu, 2011-04-28 at 15:04 -0400, Matthew Barnes wrote:
> On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote:
> > Only the last thing for the enum values, I would personally prefer
> > something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it
> > confusion-able with E_CLIENT_TYPE cons
On Thu, 2011-04-28 at 21:16 +0200, Patrick Ohly wrote:
> Agreed, the library dependency issue is a problem. That could be solved
> by an utility library on top of libecal and libebook which offers the
> unified API.
Or you could just write your own function in EvolutionSync. It's just a
switch st
On Do, 2011-04-28 at 13:07 -0400, Matthew Barnes wrote:
> It hadn't occurred to me the word "calendar" might be ambiguous. I
> blame the iCalendar spec for overloading it. In the real world, one
> does not make a "calendar of tasks", one makes a "list of tasks".
But tasks are shown on calendars
On Do, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
> [please reply to the list only, it makes my life worse when you CC me]
>
> On Thu, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
> > It would mean EClient has to know that ECalClient and EBookClient exist
> > in order to instantiate the righ
On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote:
> Only the last thing for the enum values, I would personally prefer
> something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it
> confusion-able with E_CLIENT_TYPE constant.
Do you mean E_TYPE_CLIENT (for getting EClientClass's GTyp
On Thu, 2011-04-28 at 12:35 -0400, Matthew Barnes wrote:
> This may also be of benefit to Srini and his email-factory branch. I
> can imagine extending the enum to include E_CLIENT_TYPE_MAIL_STORE or
> something similar.
Only the last thing for the enum values, I would personally prefer
something
On Thu, 2011-04-28 at 14:49 +0200, Patrick Ohly wrote:
> Please, let's avoid "E_CLIENT_TYPE_CALENDAR". For people less familiar
> with Evolution terminology it is not clear whether this includes tasks.
> In Evolution, it doesn't, but in other contexts it does. For example,
> Nokia phones store eve
On Thu, 2011-04-28 at 18:11 +0200, Milan Crha wrote:
> Yes, when I was changing server side data-views for book and cal, then
> if turned out that the D-Bus API is exactly the same except of the
> DBUS_PROXY_NAME and book/cal strings in a file.
>
> Thus having type param for both factories too, t
On Thu, 2011-04-28 at 11:59 -0400, Matthew Barnes wrote:
> On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
> > You obviously face of a circular dependency, so it's not doable in a
> > clean way. Also because EClient is in libedataserver, EBookClient in
> > addressbook/libebook and similarly E
On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
> You obviously face of a circular dependency, so it's not doable in a
> clean way. Also because EClient is in libedataserver, EBookClient in
> addressbook/libebook and similarly ECalClient in calendar/libecal. Both
> descendants link to libedat
On Thu, 2011-04-28 at 16:37 +0200, Milan Crha wrote:
> On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
> > * "32 bit IDs" - check whether (read) or ensure that (write) IDs
> > are 32 bit integers instead of strings, simplifies
> > QtContacts-EDS [2]; I have a patch whic
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
> * "32 bit IDs" - check whether (read) or ensure that (write) IDs
> are 32 bit integers instead of strings, simplifies
> QtContacts-EDS [2]; I have a patch which reduces the size of
> IDs
> from 64 bit to 32 in th
[please reply to the list only, it makes my life worse when you CC me]
On Thu, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
> It would mean EClient has to know that ECalClient and EBookClient exist
> in order to instantiate the right one for a given enum value. Normally
> in class design you
Hello!
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 as ID, QtContacts 32 bit integers.
Nokia solved that by setting up an in-memory hash which maps the UID
string to its CRC-16. I don't see an
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.
>
On Thu, 2011-04-28 at 13:12 +0100, David Woodhouse wrote:
> As I understand it, an soname bump (from libfoo.so.5 to libfoo.so.6)
> should *only* be used for backwards-incompatible changes.
Correct. One such example of a backwards-incompatible change is
increasing the size of a public GObject cla
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.
>
> Opening and listing databases don't have to be separate. Turn
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
> 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. Pl
On Di, 2011-04-19 at 10:57 -0400, Matthew Barnes wrote:
> On Tue, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
> > As icaltimezone is the main timezone for calendar in
> > evolution-data-server, and will be as long as libical will be used
> > there, then what about having e_cal_client_set_default_
On Di, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
> On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
> > There's a couple other simple things I forgot to mention yesterday.
> >
> > * We should add some padding to all the public class structs so we can
> > add new class methods in the f
On Mo, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
> I just created a new branch 'eclient' in eds [1] where is added my work
> on the new API which will deprecate EBook/ECal. It is following glib/gio
> async pattern and, I believe, makes things more coherent.
First of all, +1 for rethinking the A
21 matches
Mail list logo
