Hey all, First of all, I am really sorry of sending this patches so late. I know our libraries are frozen, but I would like to know if the patch kdelibs.diff can be applied. The other one (kutilsfix.diff) should be for sure.

<br><br>## kutilsfix.diff ##<br><br>It fixes the forcing of a library containing a KCModule to start by kcm_. I removed that requirement a week ago or so. I didn't see this code, and now this is fixed too.<br><br>## kdelibs.diff

## = Why is it needed ? = As some of you probably know, on Kate plugins have their own configuration for views too. On different views the same plugin can have different configuration (aka, different behavior). There is only one plugin instance though. This means that the configuration that the unique plugin has is the one that will remain the next time the same plugin is loaded.

This bring us a problem on plugins that can configure their own behavior per view. Imagine (as happens currently with word completion plugin) that it adds an option on the menu (that happens on each view) that is able to change if the autocompletion list becomes auto popped. We can enable it on view 1, and disable it on view 2, but the important thing is that if we go to the plugin manager and there we have it checked (enabled), if we click "OK" that configuration will be applied to both, view 1 and view 2.

The problem here from KCModule point of view, is that save() method [the one that will propagate the configuration to all views] won't be called, because nothing changed on the configuration dialog [imagine the user saw it is checked, he wanted it, clicks "OK", and then it is propagated to all views]. If something is changed by the user there is no problem, because the changed signal has been emitted and everything woks perfectly (for example, clicking twice on the check box).

I tried at a first try to emit changed(true) on the constructor of the KCModule and instantly I saw that the problem is that this signal (of course) is connected after the object is created, so this was of no use.

I wanted to avoid also QTimer::singleShot(). I really think we should get rid out of the usage of this, because of being so conditional to the system. So my idea has been to add an init() method to KCModule that will be called after the connections of the signals are done.

This is useful if a method wants to force the module to be saved, emitting changed(true) for example. This is currently used by this plugin (locally, I haven't committed anything, of course), because of the previous explained reason. We can have different configurations on different views. As this dialog is common for all of them, this dialog will load the currently saved ones (yeah, those that will remain), for example checked. If we have unchecked it on a view, and we click on "OK" on this dialog, as this dialog is common for all views, all those views have to be set to this property general set.

<br clear="all"> If this latest patch is rejected I will understand, but we will have no way of "synchronizing" the general configuration of a plugin with the views one when clicking "OK" on that dialog [proxy module won't call save() method if it didn't receive a changed(true) signal].

If everybody is OK with this changes (nobody objects), I would like someone to commit it for me. I am currently driving from one house to other for SVN access and is really annoying... Please, if someone does, CCMAIL me the commit.

Bye and thank you, Rafael Fernández López.