On Mon, 2016-03-28 at 07:33 +1100, Timothy Ward wrote:
> The EbookClient functions such as:
>
> 1) e_book_client_connect_sync and
> 2) e_book_client_connect_direct_sync etc
>
> are Declared as EClient * functions but return an EbookClient
>
> Does this means that the returned EbookClient must be type casted to
> a EbookClient to stop the Compliler warnings about the mismatch in
> declaration of the function and what the function returns. or am I
> missing the point here.
Hi,
to be honest, I do not know why it is done this way. Maybe for a
similarity with gtk+, where the "new" functions also return GtkWidget,
not the respective type the function created.
> What is the correct code to type cast for an EbookClient.
It depends on your language. If it's C, then:
EBookClient *book_client;
EClient *client;
client = ...;
/* check for errors and such (for example client can be NULL) */
...
book_client = E_BOOK_CLIENT (client);
That's pretty common way of doing these things with GLib.
> When using these functions with evolution-data-server can a new glib
> main loop be started for bdus operation or does it have to started
> in another way for an application that wishes to retrieve all contact
> info for the available addressbooks. A good example is gnome-
> contacts.
Check the backtrace, there is a book_client_dbus_thread() thread which
is for D-Bus things about the EBookClient. In any case, whenever you
call a ..._sync() function, you should know that such function can
block and thus eventually freeze the application if it's run in the
main (GUI) thread. Either use the asynchronous variants of the
functions or run your own thread where you'll do the synchronous calls,
possibly incorporating structures like GTask.
>
> 1) Is the only two methods of getting all contacts fields in an
> EWS addressbook is either to iterate over a list or hash table of
> all known fields of a contact, or
>
> 2) Use the vcard functions to get all the known fields.
This has not much to do with the EWS backend, the EBookClient tries to
not expose where exactly you get the data from, it gives you the data
in the same way for any backend. If you want to get the information
from the EContact, which is the descendant of EVCard, then you can:
1) have a list of all possible fields in the EVCard and check whether
your EContact contains them
2) ask the EBookClient for supported fields and check only for those
3) finally, if you care of performance, then use the EVCard functions
to get list of actually stored attributes on the EContact and use
only those you know about.
Do not feel confused to use EVCard functions, the EContact provides
only a "proxy" structure which makes it easier to work with certain
attributes, by internally calling EVCard functions anyway.
Hope it helps,
Milan
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
