NOV
28
2004

"Is your application enterprise ready?" - KConfig::writePathEntry()

This is an attempt to establish awareness of KDE programmers for problems that might arise on large installation sites. I am expiriencing them at Uni from time to time, where several hunderts of clients run a FC1 based KDE installation. So I decided to start a little series that might be an eye-opener for people that usually only code with the computer as a single workstation in mind and as a reminder for those who know about the difficulties that may arise in corporate environments. Feel free to continue this series in your blog or send ideas for more "enterprise development problem" quickies my way.

If you write KDE applications, you probably also have to deal with saving pathes to the users home directory, usually when storing files into your applications custom directory (e.g (~/.kde/share/apps/myapp/).

This raises a problem with some enterprise setups which use network filesystems such as NFS. Assuming the server has an nfsexport /data/ which holds all home directories in a subdir "homes", a users home directory can appear at /nfs/homes/user/ or /nfshomes/homes/user, depending on name of the mountpoint on the local machine. This happens surprisingly often even in well-administered environments.

Now if we store the full path to a file using writeEntry(), the user would be lost as soon as he uses a differently administered machine with the same home directory, which is of course not valid on this machine and causes all kinds of weired behavior. Now, how do you, the caring programmer, solve that?

Enter writePathEntry(). Of course the environment knows about $HOME, otherwise we wouldn't have come as far as starting KDE. Since KDE 3.1.3, KConfigBase and classes inheriting from it have writePathEntry(), which as a special offer for KDE programmers, is also available as writePathListEntry(). They love to take care of your problem by substituting your local home directory in pathes with $HOME, so their lovely counterparts readPathEntry() and readPathListEntry() can take resubstitute the variable with your current home directory path. Tadaaa! Problem solved.

Within KDE, Helge Deller and others have tried to ensure that every application uses writePathEntry where appropriate, but if you see one (either in your application or in one of the other applications of either kde module), please don't hesitate to fix this or send a patch.

Comments

Good request Daniel, but one note here: there's just following overload:

writePathEntry(const QString &pKey, const QStringList &rValue,....)

.. not writePathListEntry()


By Jarosław Staniek at Mon, 11/29/2004 - 07:08

Yes, path lists can be a lot useful, because sometimes storing a single path is not exactly what we want.

Maybe we can just iterate over a qstringlist, and change them with a function to store them as StringList, until a PathList is present.

Forgot to say: I was referring also to KConfigXT kcfgs.


By Diego Elio Pettenò at Sun, 12/05/2004 - 00:33

Thanks - I didn't know this either. Any chance that you could add it to the API docs in kdelibs/kconfigbase.h?

Also, how about a test for this to include in the kdenonbeta/kdetestscripts set?


By brad hards at Mon, 11/29/2004 - 09:48

Yes, good ideas, done that. The test is pretty dumb at the moment, though. Feel free to improve it.


By Daniel Molkentin at Mon, 11/29/2004 - 13:23