[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Fwd: KDE/kdelibs/kate/plugins/wordcompletion
From:       "=?UTF-8?Q?Rafael_Fern=C3=A1ndez_L=C3=B3pez?=" <ereslibre () gmail ! com>
Date:       2007-08-07 11:29:21
Message-ID: 93f85fee0708070429v597bd3f2uf1b58eb83c73d980 () mail ! gmail ! com
[Download RAW message or body]

---------- Forwarded message ----------
From: Rafael Fernández López <ereslibre@gmail.com>
Date: Tue, 7 Aug 2007 13:22:13 +0200
Subject: Re: KDE/kdelibs/kate/plugins/wordcompletion
To: Dominik Haumann <dhdev@gmx.de>

Hi Dominik,

> Unfortunately, that breaks how the KTextEditor plugin system and its config
> pages and configuration system are designed.
> Now readConfig and writeConfig are not used anymore, but that's how plugins
> are supposed to save/load data. Applying the settings is not possible
> anymore, because the config settings are only read in ::addView now.

Yeah, I saw that merging the way plugins are designed on Kate and
making KPluginSelector control them is not a trivial thing. What do
you mean with "Applying the settings is not possible anymore" ? Hmm, I
think I can still keep writeConfig and readConfig if needed.

> A way would be to readd the "Configure" button under the KPluginSelector
> widget and handle it this way (see Kate in KDE3). Also other KTE
> implementation that do not use KPluginSelector won't work (yzis). In other
> words: We can't rely on KCModule.

KCModule is not only for KControl. They are meant for KConfig modules,
and that can be applied to plugin config dialogs. Sorry, but there's
no chance of adding the configure button under the KPluginSelector.
That would need a click on every plugin for knowing if they are
configurable or not (seeing if the configure button becomes enabled or
not). That is completely un-usable.

What we could try to do is to adapt things in Kate for things in
kdelibs. For me, is what makes more sense. On the long term we are
getting more benefit, because when libraries are improved, the app is
improved. That has been seen with KPluginSelector. Kopete had a "free"
benefit from it. Yeah, KPluginSelector wasn't the best some time
ago... and today is a bit better. Kopete trusted from the first day on
KPluginSelector and they are getting all improvings for free. As well
as not duplicating efforts, and the less bugs.

I know that probably Kate's plugin manager was developed even before
KPluginSelector was, so there's no objection from my point of view,
but my suggestion is to use as most as code as possible from kdelibs.

That could imply now some efforts of adaptation. Well, better now than
in 2 years. I offer myself to help you on this stuff, because I
consider really important this kind of changes.

> Also possible: If there exists something like:
> X-KDE-PluginInfo-HasConfigPage=true
> Then there is the "More Options" link, which emits a signal so that we can
> show the settings dialog.
>
> Given all that, imo, we have to revert this commit :( I wasn't aware of
> those rudimentary changes KPluginSelector brings ;)

I have another one in the pipe for letting only a library providing
both, the plugin and the config dialog if a change is allowed on
KCModuleInfo.

Let's give a try, if you want.

> Maybe the additional configure button is the easiest way... though, it would
> be nicer to use the embedded "More Options" link.

Okay, the main problem I've faced is that you can add several views to
a plugin. You can modify properties on each view of the plugin (but
all they start with the initial one, the KPluginSelector config one).
That makes sense to me. The only problem is that when you open the
configuration dialog, and thus, the KPluginSelector. It will read
directly from the config files. So you could have unmarked "Autopop
completion list" from the Tools menu on Kate if the plugin was
enabled, and then go to "Configuration" and see that it is marked. You
could go as "wtf... i unmarked it !!", but there is marked !, yes but
that means that by default it will be marked (when loading the
plugin). That probably could be fixed somehow (no idea really), I was
thinking on what I told you, maybe some static list of views, and
static methods that inform about them, or which view is the active
one.

Let me dive more into the problem. Feel free to revert the commit if
you think is necessary. We could try to work on this too...
Personally, I'm diving more into the problem, so I hope I get
something.

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



-- 
Bye,
Rafael Fernández López.

[prev in list] [next in list] [prev in thread] [next in thread]