[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 8:14:17
Message-ID: 200708081014.17358.dhdev () gmx ! de
[Download RAW message or body]

On Wednesday 08 August 2007, you wrote:
> 2007/8/8, Dominik Haumann <dhdev@gmx.de>:
> > On Wednesday 08 August 2007, Christoph Cullmann wrote:
> > > Hi,
>
> 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
>
>  Yeah, an additional desktop file is needed in comparation to the older
> plugin selector.

to be pricese + changing the KTE to match the new system. Also, what if 
other KTextEditor implementation (yzis) don't want to use KPluginSelector.

> 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
>
> That would make me sad, but you are free to do it if your tastes do not
> fit KPluginSelector. On the long term it will be harder and harder to get
> adapted to libraries code. That's a fact, and that's more work too. I
> dream with the day that all kde apps are unified and consistent. Imagine
> every app develops its own plugin selector... not so intuitive for users,
> huh ? As I said... that's the solution I *personally* would never take.
>
> 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()
>
> Sorry, that's impossible, from all perspectives. We cannot add a button
> that needs to click on every plugin for knowing if that plugin is
> configurable or not (checking if it is enabled or not). Completely
> impossible from the usability perspective.
>
> 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*)));
>
> Yeah, check my patches:
>
> http://media.ereslibre.es/2007/08/kdelibs-08082007.diff
> http://media.ereslibre.es/2007/08/kdepimlibs-08082007.diff
> http://media.ereslibre.es/2007/08/kdebase-08082007.diff
>
> setConfigurable() is not needed. KPluginSelector checks if the plugin has
> KCModules or not. That method would be redundant, error-prone and
> unneeded. We shouldn't over-engineer libraries. That is automagically
> decided by KPluginSelector. From my point of view... adding a .desktop
> file for each config dialog is not that hard.

That's what I meant with orthogonal. KPluginSelector should not do it 
itself, but rather a KPluginSelectorFiller or KPluginSelectorProxy or 
whatever that finds the KCModules and then fills the KPluginSelector. This 
way we could ust it in both ways. More flexible and independant.

Regarding the ::self-accessor.
The plugin is also configurable even if the plugin is not loaded. ::self() 
would return 0 then. The pointer can be checked, but it's still a source of 
errors ;) Maybe "More Options" should be grayed out if a plugin is not 
loaded.

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]