[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gksu 1.1.0, new API

From: Filip Van Raemdonck
Subject: Re: gksu 1.1.0, new API
Date: Tue, 3 Feb 2004 01:18:13 +0100
User-agent: Mutt/1.3.28i


On Mon, Feb 02, 2004 at 04:38:48PM -0200, Gustavo Noronha Silva wrote:
> Em Sat, 31 Jan 2004 14:28:14 +0100, Filip Van Raemdonck <address@hidden> 
> escreveu:
> > > (just commenting on design, not functionality. I'll have to take a closer
> > > look first)
> > > Seems a bit awkward. Why aren't these methods on GksuContext instead of
> > > plain gksu functions, if they all require a context to begin with?
> > 
> > To answer myself, because GksuContext isn't a GObject to begin with.
> > I'll see how much work it is to implement that way.
> I don't know if making GksuContext a GObject is needed. Would this
> help on binding implementations? (mainly C++, Python and other
> OO languages?).

For binding implementations, it should be at least a boxed type (read the
various gobject docs on this, they are scattered but not hard to find with
google), i.e. with a _copy() and _free() method (and some other glue).[1]
If it's neither a GObject or a boxed type, it's a lot harder to make
python bindings - for GObject derivations, pygtk provides a number of
scripts to auto-generate a lot of glue code. (even if some methods need
manual overriding, it's still a lot easier than writing everything by

Granted, functionally there is little need to have anything in libgksu be
a GObject or even boxed type. If not for bindings, the only reason I could
think of is that it makes things easier to extend (due to libgksu becoming
object oriented).

(Another thing wrt. bindings: it's a lot easier if functions are both
technically (as they are now, even if not really because GksuContext isn't
really an object ATM) methods of an object, _and_ their signature makes
them look like object methods, i.e. gksu_context_do_things instead of just
gksu_do_things - simply because the language bindings definition
autogenerator[2] is just that - an autogenerator, not a sophisticated
parser; and it makes quite a few assumptions a lot of which are based
mostly on function signatures)

BTW, I'm sorry that I didn't live up to my promise of implementing this -
I just had less free time over the past weekend than I hoped for :-(



[1] But boxed types still require more work than real GObjects.
[2] Used, to the best of my knowledge, for at least python, C++ (the mm
    wrappers) and ruby bindings for GTK/GNOME libraries.

<Espy_on_crack> "I installed 'Linux 6.1', doesn't that make me a unix
<BenC> Espy_on_crack: no, you have to install it twice before you are a
       guru...once to prove you can do it, the second to fix the things
       your broke the first time
<Espy_on_crack> oh right, how silly of me

reply via email to

[Prev in Thread] Current Thread [Next in Thread]