Re: [Gramps-devel] separation issue

[Alex R. <sh...@al...>]

Doug,

On 01/05/2005 03:55:58 PM, Douglas S. Blank wrote:
>=20
> I am now appreciating the shear volume of code in Gramps,

He-he -- here's what sloccount has to say about the code, and
that does not cound glade files containing interfaces.
=3D=3D=3D
   $ sloccount .
   [snip]
Total Physical Source Lines of Code (SLOC)                =3D 52,963
Development Effort Estimate, Person-Years (Person-Months) =3D 12.92 (155.02=
)
 (Basic COCOMO model, Person-Months =3D 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         =3D 1.42 (16.99)
 (Basic COCOMO model, Months =3D 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  =3D 9.12
Total Estimated Cost to Develop                           =3D $ 1,745,070
 (average salary =3D $56,286/year, overhead =3D 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
=3D=3D=3D

> ... and hope that=20
> we can continue to build on the live gramps code. Wouldn't want to just=20
> copy a current version and be stuck with it the way that it is. With=20
> just a little bit of compromise, I think we can make the code a bit more=20
> flexible (as many have suggested) so we can be using the latest CVS=20
> versions.

Sounds very good to me.

> 1. If you could change GrampsDbBase.py so that get_thumbnail_image()=20
> returned the filename rather than an actual pixbuf, and moved=20
> set_thumbnail_image() to an image manipulation library, then=20
> GrampsDbBase would not need to import gtk. There would need to be a=20
> pixbuf creation using the filename from where get_thumbnail_image() is=20
> called, but not nothing more.

I'll let Don answer this one, as he was tweaking this end just recently.

> GrampsGconfKeys can be replaced with .ini based key code on our end. (If=20
> you rename it to GrampsKeys that would make it make sense on our end, too=
).

I don't see a problem with that. If there's no objections, I can do it toni=
ght.

> That change should allow us to use the database code without any issues=20
> (I think). If this change can't be made, I could rig up some sed scripts=20
> that automatically make the changes and copy the code into another=20
> directory.

Actually, whether the above is done or not (I see no reason why not :-),
you may set up your CVS repository and treat Gramps' CVS as the vendor
branch. At any time you can do 'cvs export' from the Gramps' CVS and
then commit that tree to your repository's vendor branch, and then
merge that branch into your tree, thereby appplying all your changes
to the newer snapshot of Gramps.

Pretty much what you've suggested, but without a need for new scripts :-)

Alex

--=20
Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN  55455
Tel (612) 625-7566   FAX (612) 626-9201