Re: Interfaces and properties, signals
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Cc: timj gtk org
- Subject: Re: Interfaces and properties, signals
- Date: 12 Mar 2001 15:55:15 -0500
Bill Haneman <bill haneman ireland sun com> writes:
> Hi Tim:
>
> I've come across a use case with GTypeInterface that I can't seem to
> find an example of, and wonder if you could answer a couple of
> questions.
>
> We have two properties ("accessible_text" and "caret") and a signal
> ("caret_moved") that we'd like to associate with implementors of a
> particular interface (AtkTextIface).
>
> Two questions come to mind:
>
> 1) Is it possible to register properties and signals on interface
> classes?
> 2) Is there a clean way of doing it ;-)
>
>
> Perhaps we should be registering the properties and signal somewhere
> else, but I don't think we should register them on a base class of the
> implementors since implementors of AtkTextIface are not guaranteed to
> have a common base class (other than GObject, I guess).
>
> gtkoldeditable.c seems to do this, but using the old-style args.
>
> (The reason we are not using an existing property is that we don't know
> that all implementors of this interface will support a given
> pre-existing property, like "text_position". We will of course end up
> connecting our property notification to that of legacy widget
> properties, inside the implementation(s) of AtkTextIface).
Currently there is support for signals on interfaces (see
GtkTreeModel.)
We don't have support for properties on interfaces. It's not
an unreasonable feature - I noticed the lack when implementing
GtkEditable; but it would add a fair bit of complexity, and
it isn't completely clear exactly how it would work.
There are two basic approaches you can take to get around
the lack:
- Declare by convention that all implementors of a interface
must implement a property with a given name.
(This is how GtkEditable works.)
- Avoid using properties, and instead have a ::foo_changed
signal and a getter/setter pair in the interface.
There is some confusion here is basically between the two views of
properties:
1) Configuring an object for GUI builds
2) Encapsulating get/set pairs in an interface
COM/Bonobo are solidly in the 1) category with the concept
of a "PropertyBag" interface. CORBA is only 2).
GObject to some extent tries to be both, though not as
comprehensively as, say, C#/.NET.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]