From b32d5bdc1994a9c0e4aa53c5ee6a492e4b36dba3 Mon Sep 17 00:00:00 2001 From: nobody Date: Mon, 6 Nov 2000 21:40:14 +0000 Subject: This commit was manufactured by cvs2svn to create tag 'BALSA_1_0_0'. svn path=/tags/BALSA_1_0_0/; revision=6429 --- doc/devel/calendar/cal-client/tmpl/cal-client.sgml | 294 --------------------- 1 file changed, 294 deletions(-) delete mode 100644 doc/devel/calendar/cal-client/tmpl/cal-client.sgml (limited to 'doc/devel/calendar/cal-client/tmpl/cal-client.sgml') diff --git a/doc/devel/calendar/cal-client/tmpl/cal-client.sgml b/doc/devel/calendar/cal-client/tmpl/cal-client.sgml deleted file mode 100644 index 06469ff3ee..0000000000 --- a/doc/devel/calendar/cal-client/tmpl/cal-client.sgml +++ /dev/null @@ -1,294 +0,0 @@ - -CalClient - - -GTK+ object for communication with personal calendar server. - - - - The #CalClient object provides a nice GTK+ wrapper for the CORBA - interfaces that are used to communicate between calendar clients - and the personal calendar server in the user's Wombat daemon. The - CORBA interfaces transfer calendar components in RFC 2445 text - format; the #CalClient object automatically converts these into - #CalComponent structures that are easier to handle. - - - - After a #CalClient object is created with cal_client_new(), it - should be asked to send a request to the personal calendar server - to load or create a calendar based on its URI. The server will - asynchronously notify the client about completion of the request, - and will return an appropriate result code; this should be noted - by the client with the cal_loaded signal. - - - - When a client asks the server to update or delete a calendar - component from the storage, the server will do so and then notify - all the clients about the update or removal. This is the core of - the model/view split between calendar clients and the storage in - the personal calendar server. Clients should watch the obj_updated and obj_removed signals on the - CalClient objects they create so that they can be notified about - changes in the storage. - - - - - #CalComponent - - - - - Casts a #GtkObject to a #CalClient. - - -@obj: A GTK+ object. - - - - - These values describe the status of a calendar load or create - request. After asking a calendar factory to load or create a - calendar, the provided listener will get notification about the - result in asynchronous fashion. Such notification is represented - by one of these enumeration values. For values other than - #CAL_CLIENT_LOAD_SUCCESS, the #CalClient object will not accept - any other operations on the calendar and it should just be - destroyed. - - -@CAL_CLIENT_LOAD_SUCCESS: Indicates a successful load or create - operation; the corresponding calendar is ready for use. -@CAL_CLIENT_LOAD_ERROR: Indicates an error while loading or creating - the calendar. -@CAL_CLIENT_LOAD_IN_USE: Indicates that a create request failed - because the specified calendar was already being used by another - client. -@CAL_CLIENT_LOAD_METHOD_NOT_SUPPORTED: Indicates an error due to - trying to load a calendar for which a backend type is not present. - - - - These values describe the result of the cal_client_get_object() - function. - - -@CAL_CLIENT_GET_SUCCESS: Indicates a successful get operation. -@CAL_CLIENT_GET_NOT_FOUND: Indicates that the requested object was - not found. -@CAL_CLIENT_GET_SYNTAX_ERROR: Indicates a syntax error when parsing - the requested object. This could indicate a bug in the calendar - client libraries or in the Wombat server. - - - - - - -@Returns: - - - - - - - -@client: -@str_uri: -@Returns: - - - - - - - -@client: -@str_uri: -@Returns: - - - - - - - -@client: -@type: -@Returns: - - - - - - - -@client: -@uid: -@comp: -@Returns: - -@ico: - - - - - - - -@client: -@type: -@start: -@end: -@Returns: - - - - - - - -@client: -@type: -@start: -@end: -@cb: -@cb_data: - - - - - - - -@client: -@pilot_id: -@uid: -@Returns: - - - - - - - -@client: -@uid: -@pilot_id: -@pilot_status: - - - - - - - -@client: -@type: -@Returns: - - - - - - - -@client: -@start: -@end: -@Returns: - - - - - - - -@client: -@uid: -@start: -@end: -@alarms: -@Returns: - - - - - - - -@client: -@comp: -@Returns: - -@ico: - - - - - - - -@client: -@uid: -@Returns: - - - - - This signal is emitted some time after the calendar clients sends - a load or create request to the personal calendar server. The - server will notify the client asynchronously of the completion of - the request. The @status parameter indicates the status of the - request. - - -@calclient: the object which received the signal. -@arg1: - -@client: Calendar client which received the notification. -@status: Status of the request. See the description of - #CalClientLoadStatus for more details. - - - - This signal is emitted when the calendar clients receives - notification of a calendar component's data being changed in the - personal calendar server. Graphical clients may want to get the - new version of the object and update their display, for example. - - -@calclient: the object which received the signal. -@arg1: - -@client: Calendar client which received the notification. -@uid: Unique identifier of the calendar component that changed in the - personal calendar server's storage. - - - - This signal is emitted when the calendar client receives - notification for a calendar component being removed from the - storage in the personal calendar server. Graphical clients may - want to delete the corresponding object from their display, for - example. - - -@calclient: the object which received the signal. -@arg1: - -@client: Calendar client which received the notification. -@uid: Unique identifier of the calendar component that was removed - from the personal calendar server's storage. - - - -- cgit v1.2.3