Qt 3.2 requirement

[Marc Mutz]

On Tuesday 29 July 2003 21:16, Lubos Lunak wrote:
> On Tuesday 29 of July 2003 20:34, Marc Mutz wrote:
<snip>
> > 1. better layering of the code,
<snip>
>  This can be achieved even without supporting multiple versions,
<snip>

How?

> > 2. a stable framework for app developers to work with (esp.
> > commercial projects that KDE wants to be so attractive for)
>
>  If you're suggesting Qt-3.1 is still good enough for KDE,

Where did I say so? What I said is that it's good enough for _some_ KDE 
users and developers and the KDE development model should reflect that.

>  how about 
> telling the app developers KDE-3.1 is still good enough? Then they'll
> have stable framework as well, won't they? They'll be in the same
> position WRT KDE just like you suggest we should be WRT Qt.

I never said that kdelibs vs. Qt is any different from kde apps vs. 
kdelibs.

> > 3. more testers for HEAD apps since thay can check out
> > bleeding-edge apps on a stable desktop.
>
>  Perhaps. But I

_you_

>  run HEAD apps from time to time in my

_your_ I'm not talking about a KDE core developers here. I'm talking 
about people that want to track Kontact development b/c it's cool and 
don't want to update the complete framework just to be able do so. I'm 
talking about intermediate app releases targeted at the latest stable 
KDE release.

>  stable KDE, and  
> they work too. If one can compile HEAD app, they can compile
> Qt+kdelibs as well.

It's *much more* work to set up multiple KDE versions. It's several 
orders of magnitude easier to just build a single KFoo app or kdebar 
module:

rpm -Uvh {qt,kde}*devel*.rpm
./configure
make
[make install]

> > Whereas the only arguments against supporting multiple versions are
> > 1. It's a pain (unspecified up to now)
> > 2. Less testing with the later lib.
>
>    3. One can't use new features.
<snip>

Pardon? Ever heard about #ifdef KDE_IS_VERSION(...)? Just deactivate the 
feature if compiled against the old lib... Where's the problem?

> > My rebuttal of those arguments:
> > ad 1: The pain is self-made and stems from (a) violating the
> > layering and (b) people that don't respect the backwards compat
> > policy.
>
>  And also from (c) the fact that shit happens, and theory and
> practice in practive sometimes differ. E.g. Qt-3.0.1 and Qt-3.2 are
> not quite compatible when it comes to certain small details (like the
> plugins, changed around 3.0.3 IIRC).
> [snip]

Did these changes break documented behaviour? If not, then this was a 
case of layering violation. If it was, it's a Qt BIC or SIC bug. If Qt 
doesn't keep BC and SC, why should KDE then try?

Marc

-- 
Kight, Khis Kay KDE Krogramms Kre Kasier Ko Kdentify; Gnome Grograms
Gn Ghe Gther Gand Gtart Gith G.
            -- "diskord_" in heise.de newsticker comment (translated)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030729/e4c6e05f/attachment.sig>