[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-08 7:34:28
Message-ID: 200708080934.28761.dhdev () gmx ! de
[Download RAW message or body]

On Wednesday 08 August 2007, Christoph Cullmann wrote:
> Hi,
>
> guess have spend to much time on working instead of watching here :)
> I am fine with the new GUI of the plugin selector, but my problem is,
> that Dominik is right, it should work like the old one or it is not
> acceptable and must be reverted. We don't want a more complex structure
> for plugins, they should stay plain easy. Before, it was just the matter
> of some minutes to add the one function and code there the dialog, now
> you need to adjust cmake files, write additional desktop files and all,
> which is, IMHO, overkill. If the pluginsselector is designed to allow
> only this, we must stay with our old code, which was not that beautiful
> visual-wise but worked. From my 5 minutes look at the selector, I think
> it's not really possible to reuse it for our approach, which is bad :/
> Rafael, have you a different opinion? If it is possible to get the old
> behaviour back together with the new (nicer) GUI, I would be happy,
> otherwise, please revert it to the old handcrafted selector, if you have
> time, you can beautify it, too, but I don't want to have this additional
> work for ktexteditor plugins.
>
> cu
> Christoph

I believe our main concern is still this:
We don't want to change the KTextInterfaces
(e.g. why do we have deps on KCModule etc just to use KPluginSelector)

the possibilities for KDE4 are:
1. revert everything so it works as in KDE3 

2. add our own Configure... button below KPluginSelector just as in KDE3.
   KPluginSelector's API would have to be extended:
    - KPluginInfo* currentItem() (we somehow have to map this to a
      KatePlugin then)
    - signal currentItemChanged()

3. use KPluginSelector completely, but its API still would need to be
   extended, e.g.:
    - setConfigurable(KPluginInfo*, bool)
    - connect(kPluginSelector, SIGNAL(showConfig(KPluginInfo*)), this,
              SLOT(foo(KPluginInfo*)));

...or something similar. The api is for sure not perfect, but you get the 
idea. (I really wonder anyway, why KPluginSelector is so tightly coupled to 
KCModule for example. Actually both is 100% orthogonal. KPluginSelector's 
API could be more flexible so that you could do both. Time for 4.0 is 
getting short :( ).

Thanks,
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]