Gideon

[Ralf Nolden]

On Friday, 10. August 2001 11:55, you wrote:
> Do you remember KDE2 development? If we have switched from the begining to
> KDE2 much more time were wasted. You remember 1 year of Corba development
> in KDE2? Who warranted that not the same happend with Qt Component and
> KDE3? Please consider that KDevelop is no KDE core application,but a normal
> "third party" application like koffice or kmud in my opinion. If I work on
> gideon I want to find bugs in gideon and not in the kdelibs. BTW: It is
> very _frustating_ to compile the kdelibs everyday and find bugs. Sorry I
> don't like the idea.
Sandy, let me explain. There's a couple of things which I see different:
-KDevelop is a central component that grants the success of KDE as a 
development platform and the shipping of KDevelop with KDE is essential for 
both, KDE and KDevelop. It's not that KDevelop is that independend from KDE 
anymore because it is also integrated completely into the documentation and 
translation process. The given version of KDevelop always has to support the 
latest KDE requirement, which is in our case, Qt 3

- regarding KDE 2 Development this was a whole new platform where no 
estimated knowledge about components and IPC was handy. That was why CORBA 
was evaluated and it cost us nerves, yes. With DCOP everything changed and 
the technology was there. Nobody will move away from DCOP again

- The API difference between KDE 1 and KDE 2 was huge, even at the Qt level. 
The switch from KDE 2 to the KDE 3 platform and Qt 3 will be minimal due to 
the reason that we like to have all currently programmed applications 
available for the KDE 2 platform to migrate within two month latest, 
depending on the time the individual programmer outside of KDE has. That 
means, that the API change is restricted to the Qt changes which are minimal 
plus the KDE changes which are currently regarded as minimal as well, though 
I personally tend to review things like the KDockWidget stuff but it won't 
harm if it will stay in kdelibs

Result for me is: it will be a matter of a day to switch to Qt 3. The API 
changes in kdelibs can be expected as minimal but binary incompatible from 
time to time so it will require a compile. We can however schedule that we 
say, as Charles proposed on kde-devel (or kde-core-devel) that BIC and API 
changes were to be introduced on fridays to do the swithing easily and assure 
that everything is working again on the compile level on mondays. I think 
that is a good compromise that we can rely on and which isn't too much of a 
trouble for everyone. The timeframe set for the release of KDE 3.0 btw 
doesn't allow breaking all of KDE completely like we had with KDE 1 to KDE 2, 
so the API will be finished much earlier; that also makes sure that third  
party developers can port their apps to KDE 3 before the final is released, 
thus we will have all the apps available for KDE 2 right now as the KDE 3 
version right away from the beginning. 

Please give these things a second thought. I don't want to persuade you, I 
just want to name the facts that are currently known from KDE, and I think 
others can confirm that. Another very strong reason to keep the pace with KDE 
is that if we don't do that, we have the problem that all of the KDE 
developers who are using HEAD on a daily basis won't be able to test and fix 
KDevelop anymore after the switch to Qt 3. You're shutting everyone off and 
force them to have a KDE 2.2 version installed, and we saw that with KDevelop 
1.3 it just doesn't work and our group will become smaller instead of larger. 
Take Simon for example; he'll stick with HEAD as well as I will because I 
have kpersonalizer in HEAD and if I want to do another tool I will definetly 
do it for the HEAD branch, not for KDE 2.2 anymore because that is double 
work right from the beginning. Looking at the kdevelop list, you can also see 
that the "customers" of us already switched to Qt 3 by a great deal - without 
any trouble btw, even for large applications this has been done in hours. You 
will get them probably a lot more as beta testers if we switch to Qt 3 as 
well and avoid the trouble a dual-KDE system brings with it.

So please, give it a second thought :)

Ralf
-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment	The KDevelop Project
http://www.kde.org		http://www.kdevelop.org


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«