Re: [gnome-db]Re: Introductions and Proposed Changes

[Rodrigo Moya <rodrigo gnome-db org>]

On 07 May 2001 19:54:25 -0400, Ian D. Stewart wrote:
> On Mon, May 07, 2001 at 04:00:22PM +0200, Rodrigo Moya wrote:
> > > 
> > ok, the url for the list of things he mentioned is http://mail.gnome.org/archives/gnome-db-list/2000-November/msg00009.html.
> > 
> > * gda-init should be part of the client lib...: no, it should stay in
> > libgda-common, since it will be needed by other gda non-client apps,
> > such as the report engine
> 
> Done ;)
> 
> > * gda-config shoudl be part of the client library...: no, for the same
> > reason as before
> 
> And again
> 
> > * the names of the macros... (IS_GDA_XML_DATABASE): yes, please do it.
> > The best way to do it would be to update the libgda/convert-api.sh
> > script, adding all the necessary stuff to convert the IS_GDA_* macros to
> > GDA_IS_*, so that we then just have to run this script on apps that use
> > libgda (Glade, Gnumeric, etc)
> 
> Would you be averse to using Perl for this? (shell scripting is not my 
> strong point).  Also, I would like to address the issue of coding standards
> and consistency in general, but that will have to wait till another e-mail
> (and until I actually contribute some code ;) )
>
of course, Perl is ok, do it as you want. The coding standards: for C,
we're following the GNOME coding standards, which are somewhere in
http://developer.gnome.org (BTW, if you find the URL, please tell us so
that we add a reference in the home page).
 
> > * every object should have a gda_xxx_free function...: yes, in fact,
> > what you should do in the gda_xxx_free function is to gtk_object_unref
> > (or g_object_unref) the object, and then, as proposed by Reinhard, do
> > all the clean up in the _destroy/_finalize function. I've already done
> > so for the GdaConnection object.
> 
> Ok.  I have a function, gda_object_destroy, in gda-object.h, which handles the
> dereferencing itself in a version-agnostic manner.
> 
that's one of the things I was thinking: have a GdaObject class which
does all the #ifdef stuff. So it would be the best solution, IMO, if you
do so and remove all #ifdef in libgda-client/common/server

> > * AM_PATH_* for ORBit: yes
> 
> May have to get Reinhard to help me on this one...
> 
> > * Makefile.am should be cleaned up a bit...: I'm not sure if what
> > Reinhard proposed is good, so please just have a look and tell me what
> > you think must be done, and we'll see if it breaks or not something
> 
> Ok.  Ran into in an issue with libtool and GOB while building from CVS.  
> Believe these may also be related to the Makefile.am (or perhaps I just did
> something foolish.  Has been known to happen).
> 
> > * gda-config should call gconf-config, ...: I don't think it's worth the
> > effort. I would prefer to make the transition now to pkgconfig (module
> > pkg-config in GNOME CVS), which we'll have to do sooner or later
> 
> Will take a look at this when I get a chance (not sure when that will be)
> 
> > * a private header file in each directory...: yes, but please use a
> > meaningful name (as the rest of the files), such as gda-common-private.h
> > or gda-commonP.h
> 
> I'm leaning towards gda-xxx-private.h.  A little longer, but leaves little
> question as to what it's for.
>
perfect!
 
> > * gda.m4: the same as for the macros directory
> > * GdaRecordset's signals: yes, a bit of clean up could be done, but I
> > think I already did some, so just have a look to see what can be done
> 
> Will take a look at this.  Hopefully GdaObject (see previous e-mail) will
> handle most of this.
> 
yes

> > * gda-value.h and gda-commandP.h: the latter has already been removed.
> > About gda-value, don't remove it, since I think I must have a look at it
> > to see what it was created for :-)
> 
> Will do (or won't do, as it were)
> 
> > 
> > Thanks for the help!
> 
> Glad to be of service ;)
> 
:-)

cheers

-- 
Rodrigo Moya <rodrigo gnome-db org> <rodrigo ximian com>
http://www.gnome-db.org/