[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] KDE 3.2 schedule ?
From:       dominique devriese <fritmebufstek () pandora ! be>
Date:       2002-04-18 19:45:28
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]