Qt 3.2 requirement

[Matthias Ettrich]

On Friday 25 July 2003 23:36, Ralf Nolden wrote:
> On Freitag, 25. Juli 2003 22:08, Bernhard Reiter wrote:
[...]
> >
> > I wouldn't fully agree with this.
> > KDE libs should have their own stability criteria and not getting forced
> > by the QT schedule. You unnecessarily force all the developers to test
> > QT.
>
> Don't you realize that it's way harder to force the developers to stick
> with an older Qt than for the others to grab and compile a newer Qt ? They
> want to use things like QSplashScreen, see the recent other mails here.

With Qt 3.2.0, the feature argument is rather weak. Unless you do database 
development with the SQL module, there is little new and flashy in the 
library that you must have. Lots of small nice things, yes, but nothing you 
cannot live without. QSplashScreen, as somebody mentioned, is a rather simple 
class, KDE can easily provide its own. The community in India hopefully has a 
very different opinion about 3.2.0, but it seems not all western developers 
share this :(

But even if you do not care about non-western alphabets there is another 
"but",  and that is a very big one: there are SEVERAL HUNDRED bugfixes in 
3.2.0. Smaller and larger issues, all reported by both the Qt and the KDE 
community. Qt 3.2.0 is mostly about stability and minor improvements, and 
little about new features (btw. in NoveHrady I will talk about new features 
and improvements Trolltech develops and plans for future versions).

KDE users and developers who are happy with the subset of functionality they 
are using, will most certainly vote for compatibility. And quite rightly so, 
afer all it is the job of the OTHER authors to work around problems in the 
libraries. Everything should run with evertyhing, right? Why not run KDE 3.2 
application with Qt 1.4,  the kdesupport package from KDE 2 and libkdeui from 
KDE 3.1? Answer: Because you end up with stagnation, the smallest common 
denominator, and the most boring software development model imaginable for a 
GUI framework. And your code has around 5 lines of #ifdef ... #elseif 
...#else ...#endif per line of logic. Look at the xterm sources for a shiny 
example. That's stuff some might do for a living, but hardly for fun.

Bernhard, when a fix or feature gets commited to libkdecore, do you also raise 
your voice for not using the new features in KDE applications, and not to 
rely on the bugfix, because somebody might chose to run new applications and 
libraries linked against the old version? How do you think KDE would look 
like if we did that right from the start?

Trolltech treats KDE as one of our most important customers. In return, KDE 
provides a fair amount of exposure and - highly important - testing. I hope 
we can maintain this partnership and that the voices that want KDE developers 
to stop test and use new Qt versions - and no longer benefit from the work 
Trolltech provides to KDE - remain a minority.


Matthias