[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]