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

List:       kwrite-devel
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 19:37:11
Message-ID: 93f85fee0708081237m793a96a8y350996ac187e1b74 () mail ! gmail ! com
[Download RAW message or body]

Hi again,

I have been thinking that if you want I can write a dummy plugin with
a dummy config dialog (that won't be installed, just on SVN as a
plugin, but not install sentence on CMakeLists.txt), but just as a
how-to write a plugin for kate.

So, what do you think about removing only those two methods from the
plugin interface ?

virtual bool configDialogSupported () const;
virtual void configDialog (QWidget *parent);

Please take in count is something regarding KPluginSelector now.

Right now, as far as I know, KPluginSelector is used by Konqueror,
Kopete and KWin. No one reported any kind of problem with it. I hope
Kate will too, but as I said on a previous email is just a bit of
effort, for example, removing those methods from the plugin interface
and letting KPluginSelector do its work.

Adding the method you said on other email
supporsConfigDialog(KPluginInfo*, ...) would be redundant because that
information could collide with the real information it has about
KCModules. For example if you said false and it found KCModules for
that plugin, or viceversa.

What's more, for adding code to kdelibs I think there is a minimum of
2 or 3 applications needing that for adding it. Please understand is a
very little change on Kate and so much winning.


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

-- 
Bye,
Rafael Fernández López.
_______________________________________________
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]