[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Recommended application-development styles
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2011-04-12 7:24:06
Message-ID: 201104121724.06456.iandw.au () gmail ! com
[Download RAW message or body]

On Sunday 10 April 2011 11:14:31 pm Aaron J. Seigo wrote:
> On Sunday, April 10, 2011 14:58:25 Ian Wadham wrote:
> > What are the currently recommended application-development styles
> > for KDE 4?  When KDE 4 started there were several alternatives:-
> 
> > Because I am working on KDE Games, I find I need to keep very up to
> > date with kdelibs and Qt sources, although I would rather I did not have
> > to. It is a constant chore and, in my view, a serious impediment to
> > "real" development and maintenance work (i.e. developing new apps and new
> > features and fixing bugs).
> 
> if it's a real impedement, then i'd recommend staying with the latest
>  released version and living with that (e.g. 4.6.2). most "top tier"
>  distros have packages available for the most recent release, though you
>  usually need to add another repository to get them.
> 
How I wish I could feel safe doing this!!!  E.g. Use KDE 4.6.2 and Qt 4.7.1,
as released, to develop an app for KDE 4.7 release.  But see below.

> > or its code has changed.  It's just that the libraries do not work the
> > same way as they used to.  So we have to keep up to date.  It is not
> > enough to rely on released versions of Qt and KDE, although it *should*
> > be.
> 
> it pretty much needs to be, as that is what users will most likely be using
> themselves. when such issues arise, they should be addressed by those
>  working on the components that triggered the regression.
> 
Just about every .1-incremental release of KDE/Qt in the last two years or so
has thrown up problems in KDE Games. For example, on my distro installation,
KDE 4.3.5 from OpenSuSE 11.2, KPatience exhibits some interesting card
clips as one card moves above another.  One day I had a multiple cut, like
a sawtooth, across the corner of one of the cards.  I helped investigate this
one a while back, because I happened to have two different releases of Qt
built from source and was able to show that most recent Qt had the bug and
the other did not.

Last year I had to be out of circulation for a few months, so I built KDE and
Qt from source about the beginning of July, wrote and tested my new features
for KGoldrunner in KDE 4.6 early and checked them in during July/August.  I
thought everything would be safe while I was away ...

When I returned to the fold just after Christmas, I was horrified to discover
that some changes in Phonon during the previous four months were causing
the KGoldrunner sounds not to play properly.  Another guy on KDE Games
found that KGoldrunner would actually crash during startup if sounds were
enabled.  This was with source-coding for sound (in the app) unchanged for
a year or more.  So I felt obliged to disable the sound-feature for the
KDE 4.6 release and it is still disabled.  I am just about to start posting on
kde-multimedia to get to the bottom of that problem.

One time the KDE Games team nearly withdrew a complete game (Kolf)
just before a major KDE release.  It was failing to start properly, nobody
could see why and the most recent author/maintainer had long since
disappeared.  I was not going to stand for dumping an entire game, so I
jumped in to see what I could do and, after some considerable effort,
managed to nail the problem in time for the release.  It was one of those
"nobody is responsible" problems that occur in complex systems.

Kolf had made an assumption about how the config classes operated.  The
app was written back in the day when KDE library doco was not very good
and, as an application writer, you would have to make assumptions and
perform experiments or read source code to find details out.  A recent
and quite valid change to the internals of the config classes had rendered
Kolf's assumption incorrect and so Kolf failed disastrously.

Back when I started KDE application development work, in KDE 1 times,
I could develop and test application code with whatever libraries came out
on the distro's CDs.  The pace of change in the libraries was not that fast.

Since the KDE 4 upheaval, application developers at KDE Games at least,
have felt obliged, for various reasons, to develop new game features in
parallel with development of new kdelibs and Qt libraries.

Maybe it is time to make application releases depend on the kdelibs and Qt
releases from about 6 months before.  IOW if I write some new features
for an app now, for simultaneous release with KDE 4.7, they are asserted to
work on KDE 4.6 libraries (and matching Qt) and *might* work on KDE 4.7
and Qt 4.7.

That way, nasty surprises from the newest libraries could be absorbed
and properly dealt with during the next development cycle of applications.

All the best, Ian W.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]