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