Hi,

I'm having some problems understanding certain aspects of KConfigXT, hopefully someone can enlighten me. The problem:
In our application we have a config option (inside a KConfigDialog page with lots of other config parameters) where you can specify a list of input directories, my initial belief was "hey, that's easy! Just choose a StringList in KConfigXT and hook it into a KListWidget.", unfortunately this doesn't work. So what I did then was to "hack into" kconfig by using KConfigGroup::writeEntry() as soon as a path is added to the list (Simply using a mutator in our settings didn't work for obvious reasons - kconfigxt isn't notified something has changed and will thus not write any changes to disk). I know this is the wrong way to do things (no possibility to press cancel in the dialog plus you have to take care of manually activating the apply button, etc etc), but we just felt we didn't want to spend any time on it just then.

So, now when I come back to this problem and try to think how it should be solved I'm getting confused. Can someone enlighten me a bit about KCModule stuff. Can I derive KCModule for just the KListWidget (plus add/remove buttons) and include that in the KConfigDialog page? Or is KCModule only for a whole page, or sets of pages? Do I really have to compile the KCModule into a plugin or is it possible to just derive a class from KCModule and add that to the GUI?

Another idea I have is to simply add a widget to the page that correctly emits the changed() signal and let KConfig deal with it. This way I think it should be possible to simply use the mutator, but I could be totally wrong.

Would be nice if there was a page about this stuff on techbase, as the only thing I can find is the KDE 3.x example. The documentation inside KCModule itself also seems outdated as it refers to the KDE 3.x example. I mean, after all KConfig is great for developers, but without knowing everything about it you run into problems like these.

You may find the documentation at api.kde.org to be of help.

bcooksley wrote:You may find the documentation at api.kde.org to be of help.

That's where I've been looking.. And in KCModule it only refers to an outdated KDE3 example.

I believe KCModule is for making System Settings control panels, not usually for what you are after.

The reason why hooking StringList with KListWidget doesn't work is because KListWidget does not supply a method to return it list in an easy format. You will need to have a method called when the user accepts their changes and use QListWidget::findItems to get a list of all the items then call QListWidgetItem::text() on each one, and adding that to a QStringList ( which you can finally write out using KConfigXT )

bcooksley wrote:You will need to have a method called when the user accepts their changes and use QListWidget::findItems to get a list of all the items then call QListWidgetItem::text() on each one, and adding that to a QStringList ( which you can finally write out using KConfigXT )

Yes that is what I am doing now, however since I have to do this manually the KConfigDialog isn't doing things - instead it is me who is manually ungreying the apply button when a new item is entered into the list, etc. Also I found that using the mutator in the KConfigXT generated settings isn't doing anything (I guess simply because nothing signals that this is changed), so I am currently using KConfigGroup::writeEntry() as soon as an item is entered into the list - thus making it impossible (without further hacks) to revert any changes should the user close the dialog or press cancel without pressing apply or OK.

So what I need, really, is a way to use the mutator in kconfigxt to write data and then signal (with KConfig::changed(bool) I guess?) that something has been changed so it will be written to disk. Is this possible? Otherwise I will have to hack even more ugly code to first put the items in a QStringList and using some bool to indicate changes in this one, and on settingsChanged() write this list. I just wanted to do it "properly" once for all without having to hack around stuff like I do now. I want to rely on KConfigXT/Dialog/etc to take care of things the way it does with everything else to avoid introducing bugs in my own workarounds. After all that's what KConfig is for, so you don't have to care about all these things yourself..

Unfortunately I am not very skilled with KConfigXT. You may be able to find help on the kde-devel@kde.org mailing list, which may have people who can help you solve your problem.