About XfconfChannel Object (Brian J. Tarricone)

[Brian J. Tarricone]

On Sun, 21 Sep 2008 15:37:56 +0200 Stephan Arts wrote:

> 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?!

And... you do know about the property-changed signal on XfconfChannel,
right?

	-brian