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

List:       kwrite-devel
Subject:    Re: Fwd: KDE/kdelibs/kate/plugins/wordcompletion
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2007-08-07 20:26:38
Message-ID: 200708072226.39018.dhdev () gmx ! de
[Download RAW message or body]

On Tuesday 07 August 2007, Rafael Fernández López wrote:
[...]
> Hi Dominik,

Howdy ;)

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

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;}

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

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.

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 ;)

Cheers,
Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel

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