On Thu, Apr 18, 2002 at 09:55:38PM +0300, Andy Fawcett wrote:
> > Well, it is very similar, in that it does the same, and looks rather
> > similar, but Kig has some more features ( is a kpart, supports
> > macro's ).
> 
> And what does the KGeo maintainer think of a possible merge?
> 

well, some time ago, i got a reply on a mail he sent here, but since then, i haven't heard anything from him again.
Also, it seems to me that KGeo hasn't been too active lately, unless the author is working on his local copy and not committing changes.
In the last mail i got from him, he did say he was still working on KGeo, i believe he said he was working on the object representation.

By the way, Kig and KGeo are totally incompatible, Kig is written from scratch, i have used few source from KGeo (the splashscreen, but i'm going to remove that, the grid) (i did get much ideas from KGeo (e.g. an optimization trick)).
A merge could only be a replace, and i'm not sure that's a good idea. (not too sympathetic towards the KGeo author, and kig is still missing some things which KGeo does have).

> > > If it is too similar, it really
> > > is not a good idea to have duplicate applications in a release.
> > > (refer to the ongoing cd-burning application discussion in the main
> > > development lists, and see what I mean)
> >
> > could you give a url on that discussion, i've been trying to find it
> > on lists.kde.org, but i don't seem to find it.
> 
> http://lists.kde.org/?l=kde-core-devel&m=101912617606338&w=2 (and 
> thread)
thx, i've just read the thread, and i think that the first poster is completely right, it's not good to have two programs in KDE doing the same think.
However, in school, i have to work with a commercial windows program Cabri which does what KGeo and Kig do, and it does have lots of more features than either (locuses, conics...)
Trying to be neutral here: it seems to me that if KDE wants to provide a viable alternative (which is the reason i started working on Kig), it would be better to continue with Kig, since
1) Kig already has some features KGeo does not have
2) the features KGeo has, and Kig does not, are minor (colouring objects, and such), the other way around not
3) the KPart interface offers some possibilities which Cabri cannot offer, like KOffice integration.
4) there's quite some work necessary on KGeo (e.g. it doesn't use KActions), which has already been done on Kig

Then again, I wouldn't like to kick KGeo out of KDE, since that wouldn't be sympathetic towards the KGeo author... (deep down, i am a nice person :)

I don't really know what is the way to go here, let me know what you think
domi
_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel