What are the currently recommended application-development styles
for KDE 4? When KDE 4 started there were several alternatives:-
1. Bleeding edge. Use the very latest KDE 4 as your desktop and
keep it up to date, monthly maybe(?).
2. Separate user A. As for 1 (bleeding edge), but keep the desktop
and all development work under a separate user ID.
3. Separate user B. Use a KDE desktop from a standard distro and
installed by that distro. Have a separate user ID for development,
but use scripts and .bashrc (e.g. the cs/cb suite) to set up environment
variables (QTDIR, KDEDIR) when you want to compile, build or test.
4. No separate user. As for 3 (separate user B), but just keep development
work in a separate disk area and use scripts, etc., when you want to
compile, build or test.
Currently I use approach 4 (no separate user) but I have reason to believe
that, as KDE 4 becomes more and more complex and as it acquires more
dependencies on external packages, this approach may no longer be safe.
ATM I have a KDE 4.3.5 desktop, based on OpenSuSE 11.2. Until a year
and a half ago, I was still using KDE 3 and OpenSuSE 10.3, although KDE 4
had been on the streets for nearly two years.
There were two reasons: I had not been able to install KDE 4 successfully
until then due to graphics problems and I do have a computer life outside
KDE development. I use my desktop to manage our family finances, to
write notes for teaching, to make slide shows, to process travel photos,
to compose emails and to browse the web. I have read too many posts
on this list and others, over the years, about guys who went bleeding edge
and lost all their email folders, for example. So approach 1 (bleeding edge)
has zero appeal, unless I use a separate dedicated machine for KDE devel.
In particular, my wife and I are retired and live by investing, so loss or
damage of financial records would be a major catastrophe.
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).
Believe it or not, games stress Qt and KDE libs rather a lot. Sometimes,
by going to the latest versions of libraries, there are efficiencies to be had
and our games can run a bit faster, but quite often there are regressions.
A game that used to work well suddenly runs like a truck, has graphic
glitches, loses a feature or fails completely. Nothing in the game 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.
Recently I have begun to suspect whether approach 4 (no separate user)
is safe. I am worried that the "background" to execution of a KDE app may
now include sundry files, KDE processes and non-KDE processes and that,
if my development libraries are too far ahead of my desktop libraries and
run-time stuff, weird problems can occur.
For example, in my setup, Phonon no longer plays KGoldrunner sound
files properly. In December, at short notice, I had to disable KGoldrunner's
sound feature in the KDE 4.6 release. I will be following this problem up
on kde-multimedia soon. There is a chain of components between Phonon
and my sound-card. Where does the problem lie? Could it be that KDE 4.3
processes and other processes from SuSE 11.2 days are too far out of date
for current Phonon?
Any thoughts on approaches 1 to 4 above?
All the best, Ian W.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
