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 <<