From kde-core-devel Mon Jul 28 16:11:20 2003 From: Ralf Nolden Date: Mon, 28 Jul 2003 16:11:20 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105940878305989 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_osUJ/6zqAsrWHMl" --Boundary-02=_osUJ/6zqAsrWHMl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Montag, 28. Juli 2003 16:20, Cornelius Schumacher wrote: > On Monday 28 July 2003 13:25, Chris Howells wrote: > > If I'm not mistaken, GTK/GNOME already support Indic languages, and I > > think it's pretty pathetic if when KDE 3.2 is released we don't have > > decent support for them, because we _should_. > > Yes. We should support and probably also require Qt 3.2 for the KDE 3.2 > release. All I'm trying to say is that we should be very careful about wh= en > and how we introduce the _requirement_ for Qt 3.2, i.e. when we give up > support for Qt 3.1.x. > > > > trouble it causes for application developers who are forced to upgrade > > > Qt without gaining anything. > > > > I would agree to an extent, but if the developers are using CVS HEAD th= en > > the least of their problems should be compiling a new Qt. > > If all goes well it costs some hours to compile it. We can save many > developers this time, if we wait until the major distributions provide > binary packages. Hmm Cornelius, as much as I like *not* to hassle with the underlying system= ,=20 it was *never* a problem to switch to a new Qt version. It even wasn't when= =20 we switched to Qt 3.0 so we could make use of the long release cycle for a= =20 binary compatible Qt with KDE. The issue I see here is only that you have those three scenarios: =2D people running HEAD -> no problem for them to switch to Qt 3.2 =2D people running KDE 3.1.x -> how does Qt 3.2 affect that ? I still didn'= t get=20 a complete answer on exactly *WHAT* does not work correctly when upgrading = to=20 Qt 3.2 on a KDE 3.1 machine. That is what should be fixed and therefore=20 #ifdef's in KDE_3_1_BRANCH for backports of fixes that go into HEAD to work= =20 with Qt 3.2. That makes users happy while we can use 3.2 with HEAD=20 automatically. Also people can install Qt 3.2, KDE 3.1 and HEAD, all on the= =20 same machine. =2D people running KDE 3.1 and HEAD -> see above So from my perspective it is *better* to switch to Qt 3.2 in HEAD and fix a= ny=20 known issues with Qt 3.2 in KDE_3_1_BRANCH ASAP. =20 If you still don't have Qt 3.2 packages for SuSE, kick Adrian :-) I'm=20 working with Madkiss to get Qt 3.2 into Debian unstable ASA I know where th= e=20 problems with KDE 3.1 *really* are as there is no way Debian unstable can=20 provide two binary compatible libraries at the same time without some very= =20 good reason not to upgrade. That is, if Qt 3.2 doesn't get into unstable th= en=20 Hindi support in KDE under Debian is non-existant by default. Ralf > > > > It's a frustrating experience, if you want to quickly fix a bug and > > > then realize that you first have to compile a new version of Qt, befo= re > > > you can test your fix. This costs us developers. > > > > If you're running CVS HEAD, you have to compile KDE regularly. > > That's already a problem. No need to make it even worse. =2D-=20 We're not a company, we just produce better code at less costs. =2D------------------------------------------------------------------- Ralf Nolden nolden@kde.org The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org --Boundary-02=_osUJ/6zqAsrWHMl Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/JUsou0nKi+w1Ky8RAvo6AKCmCiafM5ab8Tann1m4m/vw1rZV/wCeIEGO 31GImGKb521FwZyiCisSV/4= =wTzc -----END PGP SIGNATURE----- --Boundary-02=_osUJ/6zqAsrWHMl--