Re: [gtkmm] Re: [gnome-db] libgdamm: C++ bindings

[murrayc t-online de (Murray Cumming)]

On Sun, 2002-04-14 at 17:59, Rodrigo Moya wrote:
> ok, what help do you need? I just got the sources for gnomemm, and can't
> understand from a first look how everytrhing works, so I also need a bit
> of help

See the irc conversation below.
 
> > Due to libgda's use of CORBA types in its interface, it might be
> > necessary in future to make libgda depend on the ORBit2 cpp branch, but
> > this will be merged into ORBit2 HEAD soon after GNOME2 is released. The
> > libbonobouimm project already depends on the ORBit2 cpp branch, so we
> > know how this works.
> > 
> ugh, I would prefer not to make libgda depend on the cpp branch, so
> we'll try to help you in having that branch merged into the 'real'
> ORBit2 branch ASAP.

Michael and Mark assure me that it can go in after GNOME2 is released.

> I'm going to #c++ now...

<rodrigo> I'm Rodrigo, libgda's maintainer
<rodrigo> so, what do you need for libgdamm?
<murrayc> Hi rodrigo. We need people to go through all the classes,
adding *.hg/*.ccg files, and adding wrapper lines for the methods,
signals, and properties.
<rodrigo> ok
<Cactus> hi Rodrigo
<rodrigo> hi Cactus
<murrayc> And to add any examples that are currently in libgda.
<rodrigo> so, is that a 'by hand' process, right?
<murrayc> There's a small learning curve for people who aren't familiar
with gtkmm, but it's quite simple really.
<rodrigo> (ie, as you said there were some scripts)
<rodrigo> oh, yeah, I can't understand gnomemm directories :-(
<murrayc> rodrigo: Well, it's partly by hand. Lots of the code is
generated, based on a list of conversions and the .defs files that I
have already generated from your libgda headers.
<murrayc> rodrigo: There are docs on gtkmmproc in gtkmm. But you can see
the general idea in libgdamm/gda/src/connection.hg.
<rodrigo> hmm, I suppose you're wrapping libgda HEAD, right?
<murrayc> rodrigo: Yes. Is that sensible?
<rodrigo> yes, that's correct
<rodrigo> I don't want you to lose any time in the GNOME 1.4 version
<murrayc> One or 2 people have expressed interest in gnome-db C++
bindings. I'm hoping that they will help out. It's low priority for me
at the moment. I like to get things started so that other people can
continue them.
<rodrigo> yes, cool
<murrayc> rodrigo: Yes, GTK1.2/GNOME1.4 is boring ancient history.
<rodrigo> in fact, we were planning on doing the .defs files for
generating bindings for many languages
<rodrigo> so I guess we can reuse the ones you did
<murrayc> rodrigo: Yes. I used h2defs.py and our own signals defs
generator, but I had to remove some ORBIT_* functions because they
weren't parsed properly.
<rodrigo> ok
<murrayc> rodrigo: In practice, we all use the same .defs generators but
end up having slightly different .defs files.
<rodrigo> so, it is in libgdamm/libgda/src that I should add the ccg/hg
files, right?
<murrayc> rodrigo: Yes.
<murrayc> rodrigo: me, cactus, and danielk are very familiar with the
.hg/.ccg system. Others know about it too.
<murrayc> rodrigo: It gets _slightly_ more complex when dealing with
boxed types or raw structs. But you can leave them as C types until you
understand how to wrap them. We can wrap them though.
<rodrigo> ok, I'll ask you then :-)
<murrayc> rodrigo: So you have an interest in C++, or only for libgda?
<murrayc> rodrigo: I meant to start wrappers for gnome-db after I heard
about them at GUADEC2. Then I waited for the big GObject change. Then I
was reminded by your talk at GUADEC3.
<rodrigo> I'm interested in having libgda in many languages, not only
C++
<rodrigo> but C++ has been the best supported
<rodrigo> the only complete binding in libgda so far
<rodrigo> although for GNOME 2, it's outdated, since we did many changes
in the C API
<murrayc> GObject is difficult to wrap, due to lifetime issues.
<rodrigo> oh
<murrayc> But we solved it.
<rodrigo> cool
<rodrigo> that's why I don't understand the source code in connection.hg
:-)
<rodrigo> those macros are what solves the GObject issues?
<murrayc> rodrigo: Well those macros result in generated code, or give
information about code that will be generated. Then all C++ classes are
used via the RefPtr<>. See http://gtkmm.sourceforge.net/gtkmm2 for a
link on memory management, or see the RefPtr bits in here:
http://www.murrayc.com/murray/talks/2002/
<murrayc>
http://www.murrayc.com/murray/talks/2002/GUADEC3/slides/html/img10.htm
<murrayc> Later I'll post this conversation as a reply to your mail.
<rodrigo> I'm adding a bug to bugzilla with this conversation
<rodrigo> but please, also send the mail, since some people don't read
bugzilla :-)
<murrayc> From cvs, you'll also need sigc-1.1 and gtkmm-1.3
<rodrigo> ok
<murrayc> You don't really need gtkmm and gdkmm (in gtkmm). We will
separate glibmm one day if it's really helpful.
<rodrigo> it is for libgda, for instance
<rodrigo> http://bugzilla.gnome.org/show_bug.cgi?id=78670 -> please add
anything you want there
<murrayc> I don't want o separate glibmm until we have a quite-complete
library that obviously benefits from it. People complain about too many
libraries.
<rodrigo> yeah, ok, there's no hurry at all
<rodrigo> I'm just saying that it will be useful for libgda, since it
does not use GDK nor GTK
<murrayc> Useful docs for gtkmmproc (only slightly out-of-date) from
gtkmm here:
<murrayc> http://cvs.gnome.org/lxr/source/gtkmm-root/tools/README
(halfway down)
<murrayc> Yes, that's hat I meant about glibmm.
<rodrigo> murrayc: I'll talk with Kuba (C++ bindings maintainer) to
convince him to do the job
<rodrigo> murrayc: and if he doesn't want, I'll try to do it myself

-- 
Murray Cumming
murrayc usa net
www.murrayc.com