About XfconfChannel Object (Brian J. Tarricone)

[Stephan Arts]

On Sun, Sep 21, 2008 at 3:25 PM, ali abdallah <ali.slackware at gmail.com> wrote:
>
>
>> Message: 4
>> Date: Sat, 20 Sep 2008 15:54:10 -0700
>> From: "Brian J. Tarricone" <bjt23 at cornell.edu>
>> Subject: Re: About XfconfChannel Object (Brian J. Tarricone)
>> To: xfce4-dev at xfce.org
>> Message-ID: <20080920155410.1cd9a786 at kepler>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Sat, 20 Sep 2008 23:07:11 +0200 ali abdallah wrote:
>>
>> > > On Sat, 20 Sep 2008 13:42:12 +0200 ali abdallah wrote:
>> > >
>> > > > On Sat, Sep 20, 2008 at 12:32 PM, Brian Tarricone wrote:
>> > > > > ali abdallah wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > Why the XfconfChannel and XfconfChannelClass are defined in
>> > > > > > the xfconf-channel.c, i'm asking this question since i
>> > > > > > couldn't derive an object
>> > > > > > from the XfconfChannel object!
>> > > > >
>> > > > > Er, why do you want to?  I assumed no one would.
>> > > > >
>> > > > > Not saying you don't have a valid use-case, but I'd rather not
>> > > > > go and change things without a reason.
>> > > > >
>> > > > I wanted to have an object wish is derived from XfconfChannel
>> > > > object and contains more data and functions to be used in my
>> > > > application, then i can call the *channel_get* and *channel_set*
>> > > > functions by casting the object to XfconfChannel type, just like
>> > > > a GtkWidget and GtkButton for example.
>> > >
>> > > So are you actually *extending* the XfconfChannel type?  I mean, are
>> > > you actually adding settings-related functionality to it, or are you
>> > > just using subclassing as a quick-and-dirty shortcut to avoid
>> > > having to carry around an extra pointer?
>> > >
>> > > If you're actually extending the object, I'd consider making the
>> > > class struct public, but otherwise you should just be using
>> > > g_object_set_data() to carry around a pointer to the XfconfChannel,
>> > > or stuffing it in a struct that has other data you're passing
>> > > around.
>> > >
>> >
>> > Yes actually i'm extending the object and i want to add some
>> > functions to it, it's not really
>> > mandatory since the second solution that you are proposing is always
>> > valid, but well having to work
>> > with the GObject system for a long time now, i thought it is kind of
>> > standard the
>> > declaration of the GObjects.
>>
>> What kind of functions do you want to add?  If you want to add normal
>> functions that operate on an XfconfChannel object, you don't need to
>> subclass it.  If you want to add *virtual* functions to
>> XfconfChannelClass (or rather, subclass it and add vfuncs), then yeah,
>> you need to subclass, but I can't think of a reason why you need to.
>>
>> Really, I'm perfectly willing to make the XfconfChannel and
>> XfconfChannelClass structs public, and if you have a good use case,
>> please do let me know.  This is the perfect time to do it, before we
>> have a 'real' release of the library... if there's good reason.
>
> Well, my idea was to have let's say a conf object derived from the
> XfconfChannel object,
> and has a callbacks for "property-changed" with the property and the new
> value.
> i simply didn't want to have the XfconfChannel object in the private data of
> the conf
> object, since from outside to call *channel_set* and *channel_get*  i have
> to provide
> the XfconfChannel and i don't like to have anything in the conf public
> struct
> other than the parent and priv.
>

just to be clear on this: you have heard of xfconf's bind functions, right?!

-
Stephan