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