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



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 ;) )

> * 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.

> * 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.

> * 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.

> * 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 ;)


Ian

-- 
A kind word need not cost much,
The price of praise can be cheap:
With half a loaf and an empty cup
I found myself a friend.
--Havamal, St. 52




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