--Boundary-02=_bP4J/7icj8yUdKx
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

[ 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?=20
If bugs are grave enough, workarounds will need to be found for the=20
3_1_branch, which then leads to a tiny little more harmonization of the=20
two branches, which will not increase testing load if you consider both=20
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=20
other compilers/OS'es. The important thing is that those fixes must not=20
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=20
potential for bugs once the new version has been debugged (which has to=20
be done anyway, I might add).

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

=46or the framework developer? Maybe. For the app developer? Hardly. Since=
=20
this is a discussion on _Core_ Devel, I don't expect people here to=20
agree that the framework nowadays is so much less important than the=20
applications from a user perspective, but it is. The more I wonder why=20
extremely tiny framework enhancements such as adding a new std action=20
need to be immmediately commited to all CVS, breaking application's=20
backwards compat and forcing an immediate upgrade of the whole kdelibs.=20
If you've done this, you can forget your incremental builds and devote=20
half a day to recompile your modules. Now, that's what I call=20
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=20
you should not #ifdef another workaround but instead find a solution=20
that works with the documented features. If you can't, refactor so that=20
the code with the intimate lib knowledge is in a single place, then=20
#ifdef only there.

Ifdefs have the nice side effect that they're easily grepped for. So if=20
you need a workaround for Qt 3.1 (or Qt 3.2, for that matter), then you=20
can be reasonably sure that once Qt 3.2 is required (hopefully only=20
when the feature freeze for KDE 3.2 starts), a kind soul will go=20
through CVS and remove #ifdef QT_VERSION < 0x030200'ed code. That's a=20
newbie task. OTOH, if you see un-ifdef'ed code with a "workaround"=20
comment, then (1) you can't easily grep for them and (2) a newbie won't=20
clean this once it's not needed since she can't prove that it's not=20
needed anymore. Removing #ifdef's for unsupported lib versions is=20
provable behaviour-preserving, while removing non-ifdef'ed code is=20
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=20
better to not have multiple version compat, since it might uncover=20
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.=20
I'm advocating that the Qt 3.2 requirement only gets kicked in place=20
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=20
"pain" of supporting multiple libs versions is self-made and not an=20
intrinsic feature of supporting multiple versions.

That it since enjoyed a career as an argument pro multiple versions was=20
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=20
compatible with multiple Qt versions. It may even make no sense for=20
kdeui (due to KDE widgets that want to get to know their Qt base=20
classes too intimately), but then, if there is a dependancy on qt=20
versions anywhere in kdelibs, then why not revive qt-addons as the=20
layer that encapsulates and abstracts away code that depends on=20
undocumented Qt features and thus is likely to break for every new Qt=20
version? I don't see why kabc or even kdecore should be dependant on Qt=20
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=20
defintely see interfaces, mimetypes, kate, kabc or kresources as=20
"application-level libs" that have no business with Qt internals.=20
Still, they're in kdelibs, which means that if you want to enjoy new=20
features in those libs, more often than not you have to upgrade not=20
only that subdir of kdelibs, but the whole of kdelibs and qt, again=20
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=20
kresources, but not necessarily on HEAD of other kdelibs subdirs.=20
Requiring Qt 3.2 for HEAD kdelibs is implies that kde-pim implicitly=20
requires Qt 3.2. Since KDE 3.1 libs apparently don't work well with Qt=20
3.2, development of the PIM suite cannot continue using stable kde core=20
libraries. I'm not denying we've been already past that point when this=20
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=20
runs on the latest stable KDE release and want to be so nice as to work=20
with the community. Either those projects will work w/o the community=20
in the dark and appear with a large amount of code to merge (like=20
Safari), possibly with an unacceptable approach to the problem so the=20
work is lost for KDE or they start abandoning KDE as a development=20
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=20
one is better for the KDE project _as a whole_.

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

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

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

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

Marc

=2D-=20
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

--Boundary-02=_bP4J/7icj8yUdKx
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/J4Pa3oWD+L2/6DgRAj1PAJ0dw/SnD80GgEQfyEIFEG2WGGZL4gCfQvXr
+icdS7cXRCJ6TauMnFLqktU=
=zi7T
-----END PGP SIGNATURE-----

--Boundary-02=_bP4J/7icj8yUdKx--