[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 |
Hello,
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
hand)
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 :-(
Regards,
Filip
[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
guru?"
<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