Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
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 > > > > component, for uid + NULL-rid the master object (which implies also all > > > > generated instances) and keep all detached instances, > > > > > > Okay, then we agree on the desired semantic. > > > > I ran into another oddity: suppose there is a recurring event without > > exceptions and a detached recurrence gets added. The libecal API does > > not support undoing that operation. > > ... > > Hi, > it sounds like you might find useful an addition of a reverse function > for > gboolean e_cal_client_get_object_sync ( > ECalClient *client, > const gchar *uid, const gchar *rid, > icalcomponent **icalcomp, > GCancellable *cancellable, GError **error); > which can return either one component, or a VCALENDAR component. > > I'm thinking of something like: >e_cal_client_replace_object (..., const gchar *uid, > /* const */ icalcomponent *icalcomp, ...); > Note it doesn't take the 'rid' parameter as the get_object function. Yes, there might be cases where that is better than the current API. But I see it as complementary to enhancing the existing, single-event focused APIs. -- 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
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
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 > > > component, for uid + NULL-rid the master object (which implies also all > > > generated instances) and keep all detached instances, > > > > Okay, then we agree on the desired semantic. > > I ran into another oddity: suppose there is a recurring event without > exceptions and a detached recurrence gets added. The libecal API does > not support undoing that operation. > ... Hi, it sounds like you might find useful an addition of a reverse function for gboolean e_cal_client_get_object_sync ( ECalClient *client, const gchar *uid, const gchar *rid, icalcomponent **icalcomp, GCancellable *cancellable, GError **error); which can return either one component, or a VCALENDAR component. I'm thinking of something like: e_cal_client_replace_object (..., const gchar *uid, /* const */ icalcomponent *icalcomp, ...); Note it doesn't take the 'rid' parameter as the get_object function. Its meaning would be "drop whatever you have stored for the component of the given uid and use content of given icalcomp instead", which could be either single component or a VCALENDAR with a list of detached components. There might be some checking that the uid matches uids stored in the icalcomp, but that's a minor thing. Just an idea. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
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 the fact that all this code is so *gratuitously* separate. Because my patch ended up calling get_local_source() three times (for cal/tasks/memos) I was tricked into thinking I'd already covered everything; the fact that that was all still just *calendar* and I hadn't handled the addressbook side had temporarily eluded my feeble mind. > We probably need to add the "create GConf entry for local:system" part > to libebook in the gnome-2-32 branch. Is that something that is still > of interest for Trunk, given that EClient API will obsolete it for > 3.2? It's still relevant for now, so let's do it. We *could* make a case for not bothering, and just fixing it in 3.0 and 2.32 instead. But our policy is to backport only fixes from master, and I prefer not to set a counter-precedent unless I absolutely have to. It doesn't *hurt* to fix it in master first. Do you have a patch? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
On Tue, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote: > > I have tested the patch but it does not seem to help. I don't know > what the reason is yet. It may depend on earlier fixes? Can you show your patch? > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. Please don't post to public mailing lists with this unenforceable nonsense. If you file a ticket with the helpdesk, they will remove it for your outbound mail. (And if they refuse, get a name and contact me in private). -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
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 the fact that all this code is so *gratuitously* > separate. Yeah, me too. 3.2 will be better, but will still have separate libebook/libecal libraries. > > We probably need to add the "create GConf entry for local:system" part > > to libebook in the gnome-2-32 branch. Is that something that is still > > of interest for Trunk, given that EClient API will obsolete it for > > 3.2? > > It's still relevant for now, so let's do it. We *could* make a case for > not bothering, and just fixing it in 3.0 and 2.32 instead. But our > policy is to backport only fixes from master, and I prefer not to set a > counter-precedent unless I absolutely have to. It doesn't *hurt* to fix > it in master first. > > Do you have a patch? Sorry, no. And no time either :-/ -- 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
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
Hello! 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. We probably need to add the "create GConf entry for local:system" part to libebook in the gnome-2-32 branch. Is that something 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 or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
On Di, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote: > I have tested the patch but it does not seem to help. I don't know what the > reason is yet. If you have never run Evolution, there will be no gconf entries for addressbook. The second part of the fix was to have libecal 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://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mon, 2011-05-09 at 12:04 -0400, Matthew Barnes wrote: > On Mon, 2011-05-09 at 17:49 +0200, Milan Crha wrote: > > It's just because of (so called) consistency. With merging common error > > codes into E_CLIENT_ERROR_ "namespace" I realized that checking for > > particular errors will not be that easy as is now, because one might > > have two switches, one for domain E_CLIENT_ERROR and the other for > > E_CAL/BOOK_ERROR. Not a big deal, but still. > > If you're using a switch statement to check for specific GErrors then > you're doing it wrong. You should be using g_error_matches() for each > case, so it doesn't matter if all the error codes are in the same domain > or they're all in different domains. > > I'd like to get rid of the redundancy. OK, done on both server and client sides. Those common properties has macro prefix "CLIENT_", those specific are prefixed with "BOOK_"/"CAL_". Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mon, 2011-05-09 at 17:00 +0200, Milan Crha wrote:
> On Wed, 2011-05-04 at 14:37 +0200, Milan Crha wrote:
> > So here left basically three things,
> >a) merging some API in utils,
Hi,
I committed a change, introducing libedataserverui/e-client-utils.h/.c
It adds new
typedef enum {
E_CLIENT_SOURCE_TYPE_CONTACTS,
E_CLIENT_SOURCE_TYPE_EVENTS,
E_CLIENT_SOURCE_TYPE_MEMOS,
E_CLIENT_SOURCE_TYPE_TASKS
} EClientSourceType;
(I chose this wording, in a sense: EClientSourceType tells you what is
stored behind the ESource. I harmonized this wording with
ECalClientSourceType too.)
The newly added functions are:
e_client_utils_new
e_client_utils_new_from_uri
e_client_utils_new_system
e_client_utils_new_default
e_client_utils_set_default
e_client_utils_set_default_source
e_client_utils_get_sources
The e_client_utils_open_new/_finish is still waiting its addition. Main
reason is that there is no mechanism, at the moment, to distinguish
current backend open mode/state. Right now it can be online and loaded.
It's not much documented, but from its usage I see that:
online - TRUE, if the backend storage/server is reachable; use to be
set in 'open' backend's method or unset on failed
authentication or similar occasions
loaded - TRUE, if the 'open' backend's method was called
What I would need is a signal from the backend, "fully-opened", which
may cover authentication too. (The "fully" prefix is rather redundant,
but self explanatory.)
When you look how the async open method for an addressbook is written,
that located in libedataserverui/e-book-auth-util.c, then after usual
"open" call on the EBook it checks whether the associated ESource has
"auth" set, and if so, then it *forces* the "authenticate_user" method
call. I believe it's not correct, it may wait and respond on backend's
authentication request, but because it's not clear in what state the
backend is, with respect of opening and authenticating, then I
understand there was not many options.
This is the interstate issue Matthew mentioned earlier, in another
thread, (I understand it that way at least), where is hard to
differentiate between open-called, authenticating, fully-opened/ready
for queries.
I propose following changes in the backend:
a) add 'opening' boolean flag, which will be managed automatically. It
will be set during 'open' call, and unset only if the storage/server
will be fully connected, thus if the server will require authentication,
then the backend asks for credentials and keeps this flag to TRUE. The
flag will be automatically unset also for cases when the 'open' method
call finishes with an error. During the opening phase every call to the
backend will deny with Busy error, except of close / cancel /
authenticate_user and similar calls.
b) the backend descendants will notify client about "opened" either
within 'open' call itself, for cases where notification is not needed,
or when it successfully connects to the storage/server (including
authentication), by a call to function like
e_book/cal_backend_notify_opened (backend, const GError *error);
The NULL error is meant for 'success'. This will invoke signal on the
client side with a result. The internal 'opening' flag will be updated
accordingly on the e_..._backend_notify_opened() call, which is supposed
to be called every time.
c) it may not matter if the e_..._backend_notify_opened() will be called
before or after the notification about 'open' method call.
d) a new backend property "opening" will be introduced.
e) the "loaded" property might be replaced with "opened" and will be set
to TRUE only after the backend is successfully opened and authenticated
against its storage/server (basically on e_..._backend_notify_opened()
call with error set to NULL).
f) setting 'online' to FALSE will not result in an opened=FALSE if it
was previously opened, though the backend descendant will be able to
unset the 'opened' flag, by calling the e_..._backend_notify_opened()
with the GError set to a detailed reason why it is not opened.
g) On the client side the EClient::open-changed signal will be
introduced, which will have one argument, the GError from the
e_..._backend_notify_opened(), which will be called on each invocation
from the backend itself.
It'll be easy to do an e_client_utils_open_new() properly with above
changes done, but I would like to know opinions from others whether such
change makes sense and if you'll not see any issue with this approach.
If not, then I'll be more than happy to do this change in the EClient
branch.
Bye,
Milan
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
