Qt 3.2 requirement

[Marc Mutz]

[ the important message is in the last four paragraphs ;-) ]

On Tuesday 29 July 2003 21:19, Aaron J. Seigo wrote:
> On Tuesday 29 July 2003 12:34, Marc Mutz wrote:
<snip>
> to play devil's advocate[1], the flip side to the coin is that
> maintaining multiple versions of Qt means:
>
>  o having to work around bugs / misfeatures that are already fixed in
> Qt 3.2

So, what about the poor KDE 3.1.x users? Are they stuck with the bugs? 
If bugs are grave enough, workarounds will need to be found for the 
3_1_branch, which then leads to a tiny little more harmonization of the 
two branches, which will not increase testing load if you consider both 
branches. If the bug is not worth it, why bother then?

> o having to keep multiple versions of Qt around for testing.

You don't need to. Others will fix errors as they fix incompats with 
other compilers/OS'es. The important thing is that those fixes must not 
result from someone willingly breaking backwards compat.

> o having to maintain multiple code paths which you may or may not be
> able to test thoroughly.

Noone can seriously tell me she tests all code paths in her application.
You know that's both impossible and not necessary. Replacing a self-
coded feature with it's equivalent implemented upstream has very little 
potential for bugs once the new version has been debugged (which has to 
be done anyway, I might add).

> all of the above leads to:
>
>  o longer development time

For the framework developer? Maybe. For the app developer? Hardly. Since 
this is a discussion on _Core_ Devel, I don't expect people here to 
agree that the framework nowadays is so much less important than the 
applications from a user perspective, but it is. The more I wonder why 
extremely tiny framework enhancements such as adding a new std action 
need to be immmediately commited to all CVS, breaking application's 
backwards compat and forcing an immediate upgrade of the whole kdelibs. 
If you've done this, you can forget your incremental builds and devote 
half a day to recompile your modules. Now, that's what I call 
development time saving! ;-)

>  o more obfuscated code thanks to ugly #ifdef'ery

If a lib upgrade shows that you've relied on undocumented features, then 
you should not #ifdef another workaround but instead find a solution 
that works with the documented features. If you can't, refactor so that 
the code with the intimate lib knowledge is in a single place, then 
#ifdef only there.

Ifdefs have the nice side effect that they're easily grepped for. So if 
you need a workaround for Qt 3.1 (or Qt 3.2, for that matter), then you 
can be reasonably sure that once Qt 3.2 is required (hopefully only 
when the feature freeze for KDE 3.2 starts), a kind soul will go 
through CVS and remove #ifdef QT_VERSION < 0x030200'ed code. That's a 
newbie task. OTOH, if you see un-ifdef'ed code with a "workaround" 
comment, then (1) you can't easily grep for them and (2) a newbie won't 
clean this once it's not needed since she can't prove that it's not 
needed anymore. Removing #ifdef's for unsupported lib versions is 
provable behaviour-preserving, while removing non-ifdef'ed code is 
potentially not behaviour preserving. Don't underestimate this point.

>  o hightens the chance for bugs in code left there for backwards
> compat but which few (if any, in some cases) of the developers use

See above. To the contrary.

>  o bugs in the code that appear when run with one version of Qt but
> not another (the recent konq sidebar commit that relied on Qt 3.2 was
> a good example of that)

"Bugs in code". Hmm, do I understand the above correctly as saying "it's 
better to not have multiple version compat, since it might uncover 
hidden bugs in our code"? ;-)

>  o less people testing what will be the common version of Qt+KDE when
> KDE 3.2 arrives.

Nope. I'm not advocating that KDE 3.2 should be compatible with Qt 3.1. 
I'm advocating that the Qt 3.2 requirement only gets kicked in place 
once the feature freeze is in place.

> there are costs both ways. trying to enforce better layering by
> making more work rather than encouraging and enforcing good coding
> practice is a bit like leaving your shoelaces untied so you can learn
> how to break a fall better.

The "violation of layering" argument came into play to explain that the 
"pain" of supporting multiple libs versions is self-made and not an 
intrinsic feature of supporting multiple versions.

That it since enjoyed a career as an argument pro multiple versions was 
not intended, but is nice as a side-effect.

> i also think there is a distinction between applications and the base
> libraries. while the application developers may wish to develop
> against KDE 3.1, it hardly makes sense for kdelibs 3.2 to develop
> against kdelibs 3.1... same for Qt reliance.

I'm partly with you here. It doesn't make sense for styles to be 
compatible with multiple Qt versions. It may even make no sense for 
kdeui (due to KDE widgets that want to get to know their Qt base 
classes too intimately), but then, if there is a dependancy on qt 
versions anywhere in kdelibs, then why not revive qt-addons as the 
layer that encapsulates and abstracts away code that depends on 
undocumented Qt features and thus is likely to break for every new Qt 
version? I don't see why kabc or even kdecore should be dependant on Qt 
3.2 until the feature freeze kicks in.

> perhaps there needs to be a distinction between libraries (kdelibs
> and perhaps kdebase) and applications and application-level libraries
> (everything else) when it comes to Qt dependencies, which is actually
> a natural extension of your arguments regarding layering.

Yes, I think it is. We maybe disagree on where the line is, though. I'd 
defintely see interfaces, mimetypes, kate, kabc or kresources as 
"application-level libs" that have no business with Qt internals. 
Still, they're in kdelibs, which means that if you want to enjoy new 
features in those libs, more often than not you have to upgrade not 
only that subdir of kdelibs, but the whole of kdelibs and qt, again 
leading to an afternoon of recompiling instead of productive work.

The ideal layering would be:

Qt
Qt-AddOns <- styles, widgets, Qt plugins that need or want intimate
             knowledge of Qt internals or have a track record of
             breaking with Qt upgrades, classes that we want DCOP to
             work with on the command line. Bound to a particular Qt
             version, required to be updated whenever Qt is updated.
kde core libs <- kdecore, kdeui, kio, ...
             Requires Qt version of the last stable KDE release,
             suggests latest stable Qt version.
other kde libs <- kate, kabc, kutils, kio slaves...
             Requires latest stable kde core libs,
             suggests HEAD libs
kdebase, apps <- kdebase and kde app modules
             Requires latest stable kde core libs,
             May require HEAD versions of "other kde libs" (with a few
             weeks grace period).
             Suggests HEAD libs.

> i also look at past releases of KDE, from the time that i was a
> spectator to now as someone who is somewhat involved in things, and i
> don't see the policy to date causing egregious problems for people.
<snip>

You forget how this all started. KDE-PIM depends on HEAD kabc and 
kresources, but not necessarily on HEAD of other kdelibs subdirs. 
Requiring Qt 3.2 for HEAD kdelibs is implies that kde-pim implicitly 
requires Qt 3.2. Since KDE 3.1 libs apparently don't work well with Qt 
3.2, development of the PIM suite cannot continue using stable kde core 
libraries. I'm not denying we've been already past that point when this 
thread started, though.

> even more poignantly, the Qt 3.2 vs Qt 3.1 issue is not an issue for
> end users, since they will upgrade their Qt along with the KDE
> packages as is generally the case with binary packages. so for KDE
> 3.2 proper this isn't an issue, it's really only an issue for
> applications that will be a part of 3.2 that wish to do independant
> release between now and then and for developers who couldn't be
> bothered to compile 3.2 themselves.

Or for commercial projects that are contracted to deliver a product that 
runs on the latest stable KDE release and want to be so nice as to work 
with the community. Either those projects will work w/o the community 
in the dark and appear with a large amount of code to merge (like 
Safari), possibly with an unacceptable approach to the problem so the 
work is lost for KDE or they start abandoning KDE as a development 
platform and start to use Gnome or vanilla Qt.

> i'm glad you're very convinced of your position in this matter, but
> common sense and truly rigorous evaluation shows that there are
> benefits and challenges to both positions.

Of course there are. However, what is not resolved is the question which 
one is better for the KDE project _as a whole_.

Since I think KDE's path to success will primarily lie in the 
applications and commercial Free Software projects such as Safari, 
Aegypten and Kroupware, and _not_ in further improvements of the 
(already mature) framework, I conclude for myself and anyone that is 
willing to follow this line of reasoning, that it's about time the 
focus shifted from making development easy for "us" (the framework 
developers) to making it easy for the application developers.

Developing a framework for the sake of developing a framework is 
masturbation. Nice if you can't have anything better, maybe even 
necessary to learn what you want ;-) but boring if you can have the 
real thing.

There must be a reason that Gnome, though commonly (and from Gnome 
people!) refererred to as the poorer framework and awkward to work 
with, has attracted far more commercial companies and has the better 
portfolio of not-so-standard application solutions (where's the gnucash 
equivalent on kde?). The reason may very well be that their libraries 
are developed more or less independantly (which benefits KDE as well - 
see libxml, libxslt).

It's time that KDE recognizes that it has become mature, that the wild 
escapades of it's youth (KDE 1->KDE 2 rewrite) are more or less over 
and that it's now time to get a decent living (stable interfaces), give 
birth to children (innovative apps) that thrive through the great 
foundation (kdelibs) laid by their parents. Something like that.

Marc

-- 
It seems that the only thing worse than being an enemy of the US is
being a close friend and ally.
     -- John Horvath, "The Meaning of Friendship", Telepolis #14395
-------------- 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/20030730/b71d7089/attachment.sig>