Jaroslaw Staniek js at iidea.pl
Sat Feb 11 21:11:22 GMT 2006

In addition to what David said (I highly agree here), I'd like to add my .02E:

Let's think about Linux distributions, the way how they choose technology.
For distro release N+1, many distributions prefer KDE version that supports 
most of the app that were also available in release N. Otherwise they would be 
most probably in risk of "being less feature-rich than competition".

I'd say something even more extreme: most Linux distros will ship Qt3 for a 
long time (maybe for 2 or more major releases). By accepting the intermedate 
step (a port to qt3support and kde2support) we can make the time closer when 
Qt3 is not needed anymore in distros.

Depending on the optics, (this may be hell, as in MS Vista ;), but we want to 
make a choice: whether the transition has to be smooth or not. Big jump is 
risky when you have no guaranteed workforce that forced to work on unsexy 
porting on demand.

If we force application developers to port "every single button" to the v4 of 
KDE and Qt API, a number of them may have a problem: "to spend my time on 1) 
improving my app or 2) performing a port and related tests".

Since many devs look at their activity in KDE as fun, they may prefer to 
improve the app (read: fun) instead of porting.

Others, like me, have employer that do not allow to spend most of the time on 
porting activities unless the result can be seen "dynamically", say, resulting 
in a working application for every 2 weeks or so. The result, working 
application, could be available more quickly when kde4support is available. 
You can see the difference. Exchange building blocks step by step without 
breaking everything for a long period of time.

Yes, there are obvious exceptions to that, e.g. apps that rely on improved 
painting/printing features, good font support, etc., as in KOffice.

So in my imagination, not only qt3support is needed for our strategy, but also 
kde3support. I am not even sure it can be dropped anytime in the KDE4 
lifetime. I think, marking the Q3/K3 classes as obsolete could be enough. How 
else can we advertise our API for using by 3rd party devs?

That said, I am aware there are classes/behaviours that simply cannot be 
"emulated" by wrapping KDE4 API into kde4support.

Could anybody working for distro makers (SuSE, Mandriva, Debian?) comment on 
the above assumptions?

regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

  Kexi Developer:      http://www.kexi-project.org | http://koffice.org/kexi
  Kexi Support:        http://www.kexi-project.org/support.html
  Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
  KDE3, KDE4 Libraries For Developing MS Windows Applications:

More information about the kde-core-devel mailing list