About XfconfChannel Object (Brian J. Tarricone)
ali.slackware at gmail.com
Sun Sep 21 15:25:06 CEST 2008
> 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
and has a callbacks for "property-changed" with the property and the new
i simply didn't want to have the XfconfChannel object in the private data of
object, since from outside to call *channel_set* and *channel_get* i have
the XfconfChannel and i don't like to have anything in the conf public
other than the parent and priv.
I hope that i made myself clear.
> P.S. Subclassing using GObject actually isn't done all that often
> unless there's a decent benefit... In a language like C++, you'd
> probably subclass a lot more often since it's trivial. But with all
> the work it takes to subclass a GObject in C, it's not done unless
> there are clear benefits to doing so, in general. (I remember when I
> used to write Qt2 apps, it was common practice to always subclass
> QWindow for your app's main window... but that's probably not so common
> to do with GtkWindow in straight C, though admittedly I do it
Even when i write using C++ my code looks like C, the only one difference is
i hate C++.
Many thanks for answering my questions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xfce4-dev