[calligra] /: Qt3Support is also needed in Calligra.

[Jaroslaw Staniek]

On 3 December 2011 23:31, Cyrille Berger Skott <cberger at cberger.net> wrote:
> On Friday 02 December 2011, Jaroslaw Staniek wrote:
>> I am ok with this at the current stage. Porting should be careful, you
>> know - Kexi 1.x on Qt 3 was way more stable, and in Qt 4 version we
>> have almost no extra complicated features. How about discussing about
>> a deadline for removal of Qt3Support? I propose
> Did it occured to you that using deprecated(/unsupported) API is not the best
> road to stability ?

All minor uses of QT3SUPPORT in Kexi will be removed really soon. Only
complex code of tableview that depends on it still stays untouched
because it's tested for years with Qt 3 and Qt3 support and _is_
stable.
It's all fragile when APIs change so extremely, e.g. (boring details follow):
Porting KoProperty to modelview took me calendar months and it is
still not rock stable compared to Qt3 version. Tableview port means
going from QWidget paint events and child widgets to a plain QGV like
in Harmattan Office.

>> This is just Qt 5.0. Many devs are afraid of releasing
>> software using x.0 version of a new library, so that could add up to
>> the delay.
>
> Well there is not much difference in Qt 5.0 and what would have been Qt 4.9,
> just they move some code around, axe some libraries in two. So I would expect
> the adoption rate of Qt 5.0 to be very quick, and since it will be a blaze to
> compile application that don't use API-that-are-deprecated-since-5-or-more-
> years-ago, then I expect most distribution to want to simplify their life and
> be quick to drop Qt 4.8. Which means, that supporting Qt 5.0 when it goes out
> will be a must.
>
>> as said before I see no features in Qt 5 that justifies abandoning support
>> for older Qt 4-oriented distros.
> This is totally unrelated. Compiling with Qt5 does not prevent us to also
> support Qt4. Since both are almost source compatible, maybe a few #ifdef in
> some places, and we are done. However, "not supporting Qt5" is suicidal, and
> frankly, since most calligra applications do not require QT3SUPPORT, most of
> them are ready, meaning that it is very likely that in recent distributions
> Calligra/Qt5 will be used instead of Calligra/Qt4, with or without Kexi.

 "Not supporting Qt5" is obviously suicidal, I did not propose to even
delay working on having the code build with it.
What I said that for cases where no important features new in Qt 5 are
used, there is no need to drop support for Qt 4, especially if there
is evidence that Qt 4 support makes sense. Certain transitional period
when both are supported, (i.e. what you proposed) is a good idea,
consistent with what I said. Hope it's more clear now.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)