About XfconfChannel Object (Brian J. Tarricone)

[ali abdallah]

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.

I hope that i made myself clear.



>
>        -brian
>
> 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
> sometimes.)


Even when i write using C++ my code looks like C, the only one difference is
the compiler.
i hate C++.

Many thanks for answering my questions.

Best Regards,
Ali.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20080921/5bbeb8fc/attachment.html>