[PATCHES] KCModule changes and kutils fixes

Rafael Fernández López ereslibre at gmail.com
Tue Aug 21 22:28:56 BST 2007


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.

## kutilsfix.diff ##

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.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070821/415454d5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs.diff
Type: text/x-diff
Size: 2641 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070821/415454d5/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kutilsfix.diff
Type: text/x-diff
Size: 1245 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070821/415454d5/attachment-0001.diff>


More information about the kde-core-devel mailing list