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

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

Hi,

> I'd like to point out how it worked and how it works now:
>
> The process was:
>
> 1. load plugin
> 2. call readConfig (read file)
> now user wants to configure:
> 3. Kate Part calls showConfigDialog
> 4. apply settings
> 5. ... hours of editing...
> 6. call writeConfig (write file)
> 7. unload plugin
>
> All this worked out of the box if the plugin overrides
>   bool hasConfigPage() {return true;}

yup !

> Now the process is:
>
> 1. load plugin
> (readConfig never called, plugin has to handle configuration itself, more
> complex)
> 2. KPluginSelector calls showConfigDialog
>    This is so much more work now:
> 2.a You have to provide an extra .desktop file + extra .so file (also more
>     complex in cmake)
> 2.b Then you have to read the config instead of reading the plugin settings
>     (and you have a file access)
> 3. apply settings means now:
> 3.a write the settings to the config file again (again file access)
> 3.b now the plugin itself has to read the settings from the file again.
> ...
> 4. save settings in destructor (instead of writeConfig being called
> automatically)
> 5. unload plugin

Not exactly as discussed on IRC :) For general knowledge, the
implementation I have (locally) is a singleton structure for the
plugin with a static self() method. From the config dialog you can
access to every method/property of the plugin itself. All the plugin
structure of Kate is kept, no changes done to the plugin architecture
of Kate. This is possible because only a plugin instance is loaded at
a time.

> I am convinced that the old method is better. The config pages directly
> communicates with the Plugin instead of via config files. And it was a lot
> easier to code.

Same here. Direct communication between the config dialog and the plugin itself.

> Right now, KTextEditor plugins never needed an additional KCModule (I stress
> again that, imho, it's much more work that what KTE provided). Can't we
> somehow keep that in KTE? I still don't see the benefits ;)
> > > 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.
>
> That is how it worked in KDE3, and it worked *perfectly*. ;)
> I'm not saying that it's really good. But it would keep our clean KTE
> interfaces. They are *really* well designed in KDE4, imho.
>
> > 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.
> [...]
>
> > 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.
>
> Of course we want to use KDE standards. But the workflow was so much better
> before, imho. see below.
>
> > 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.
>
> I'm not sure whether I follow you here ;)
>
> > 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.

Is not hard at all :), really :)

Bye !!
Rafael Fernández López.

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