Re: ORBit2 and async stuff



Michael Meeks <michael ximian com> writes:

> Hi Martin,
> 
> On 25 May 2001, Martin Baulig wrote:
> > how does the following API look ?
> 
> 	I don't quite understand what problem you are trying to solve
> with this API. Personaly I would implement a file selector without a new
> interface, simply using a selector control and a set of standard
> properties such as 'selector:mode' == MULTI / SINGLE, selector:selection
> = a sequence<string> and the event source to notify of changes in the
> selection [ if the user is in fact interested in this - which often they
> arn't ], selector:mime_filters = sequence<string>

You don't understand the beauty of this interface :-)

Documentation is coming shortly ....

> > The CORBA API (ClientID is unique per GNOME::Selector object, AsyncID
> > is set by the client to
> 
> 	Why have a unique ID per GNOME::Selector object when you have the
> unique CORBA_Object reference ?

You get a ClientID by calling GNOME::Selector::getClientID() and you'll get
a different number each time you call this function. Unique means that each
client will get a different ID; it's used by the clients to identify "their"
events in the BonoboEventSource.

> > 	Bonobo::Control getControl ();
> 
> 	If we have a getControl, we should have a setControl too, but I'm
> not quite understanding how this should work.

That'd be evil. A GNOME::Selector is a Bonobo::Control, more or less. We just
cannot use queryInterface("Bonobo/Control") on the GNOME::Selector (according
to the docu, you must not call bonobo_object_add_interface() after the object
has been exposed to the outside, but the control cannot be created before the
selector is fully constructed). So for the moment there's a getControl() method
even if it's basically doable by QI.

> > 	string getEntryText ();
> > 	void setEntryText (in string text);
> 
> 	This would strike me as an ideal property.
> 
> > 	string getURI ();
> > 	void setURI (in string uri,
> > 		     in AsyncData async_data);

This cannot be a property since it's an async operation.

> 	As would this - but then I don't understand the async_data.

This is the ugly part of the CORBA API which is needed due to the async
stuff.

In the C API, it's more clear:

===
void
gnome_selector_client_set_uri               (GnomeSelectorClient   *client,
                                             GnomeAsyncHandle     **handle_return,
                                             const gchar           *uri,
                                             guint                  timeout_msec,
                                             GnomeAsyncFunc         async_func,
                                             gpointer               user_data);
===

This is an async operations (since it could, for instance, load an image over the network and then
display it in the selector) - you'll get a `GnomeAsyncHandle *' which you can use to abort it and
the `async_func' will be called exactly once (on succes or error).

Here's a short example:

===
static void
selector_demo_async_cb (GnomeAsyncContext *context,
			GnomeAsyncHandle *async_handle,
			GnomeAsyncType async_type,
			GObject *object,
			const gchar *uri, const gchar *error,
			gboolean success, gpointer user_data)
{
    g_message (G_STRLOC ": %d - `%s'", success, uri);
}

somewhere_in_the_application (GnomeIconSelector *iselector)
{
    gnome_selector_client_set_uri (GNOME_SELECTOR_CLIENT (iselector), NULL,
				   "/home/martin/erlangen-pics/Jennifer_Lopez.jpg", 0,
				   selector_demo_async_cb, NULL);
}
===

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]