(CC'ing devel list)
Well, I'm always interested in more help. B-) There has been some
progress since the initial website was created, but we're still way far
from even an alpha release. I don't think there's a link on the project
site for the project page at SourceForge
(http://sourceforge.net/project/?group_id=4216).
Right now in CVS, there's the start of the date class that we're going to
use as well as stubs for the other object that we'll need. I've been
working my way through another GEDCOM library that was made available to
us that parses one line of the GEDCOM and stores the results in global
variables (I can forward a tarball of it if you'd like to see it; it's
not in the CVS yet). Since we haven't fully integrated this into the
package yet, it can very easily be changed. I'm not so sure that I like
the parser to put its results into global variables, a structure or class
of some kind seems to make more sense.
It seems that it might be better to have the parser derive an object to
hold the data from the parser, and then return a pointer to the base class
from which the new object was derived. Perhaps the base class would look
something like this (this probably wouldn't pass the compiler in its
current incarnation, but you get the idea)...
class gedline
{
public:
gedline(void);
gedline(const gedline &);
~gedline(void);
int get_type(void);
private:
int gl_linetype;
};
class gl_person :: gedline // gl_person is derived from gedline
{
public:
gl_person(void);
gl_person(const gl_person &);
~gl_person(void);
char * get_name(void);
...
private:
char * name;
...
};
In the base class, the function get_type() would, naturally, return the
value of the gl_linetype variable. This would then determine what
functions are to be used with the derived type.
Anyway, it's something to think about as we get closer to implementing
this support (I'm purposely cutting this short, since it's now 6:20a and
I'm supposed to be getting ready for work...).
The only other change from the original site is that we may end up using
GTK+ instead of Qt. The reason for this is that we've been building a
few possible screens with Glade, which outputs code using GTK+. The
choice of widget libraries seems to make less of a difference than the
choice of database libraries, since all of the popular window managers
that I know of can run both GTK+ and Qt applications. But, like the
GEDCOM support, we're still at such an early stage that this could change
too.
--
Sean Lamb
Chief Webmaster, SCWD, NMRA --- http://www.scwd-nmra.org
Historian and Webmaster, Capitol City "N"Gineers ---
http://www.msn.fullfeed.com/~slambo/capcity.htm
Madison Linux User Group --- http://www.madisonlinux.org
On Sun, 14 May 2000, Jeff Pitman wrote:
> I was just perusing your Genes webpage on sourceforge.net. You've got a
> great idea, and linux does need a good gen program. Writing it in QT is
> a good idea. I've used QT quite a bit and I've got the Caldera dist
> also; KDE is slick.
>
> I'm starting a GEDCOM C Library, which will be released under the LGPL. The
> library will provide programmers an easy interface into the GEDCOM file.
> The library involves parsing the file and populating the data into
> memory structures. Using this interface, your program will be able to
> leverage a speedy parser and easy/intuitive function calls.
>
> Let me know if you are interested in this library.
>
>
> Jeff
>
_______________________________________________
Genes-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/genes-devel
