[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-09 20:32:06
Message-ID: 93f85fee0708091332l2921a4d3jf1c9b185e97b893b () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
Am Mittwoch, 8. August 2007 21:37:11 schrieb Rafael Fernández López:
> 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.
I don't think so, it makes plugins that much harder to write for zero bonus,
beside that apps must use the kpluginselector, I don't think that's really a
plus. The apps you name use some very limited plugins, as there plugins don't
deal with any document/view or anything. I think it makes sense to let the
KTextEditor stuff remain and just avoid kpluginselector in kate, don't know
if people will really miss that, or?
This stuff makes me extremely sad. As I said what KPluginSelector gives
users is in a part of the desktop (plugin stuff) a unified look on all apps,
for a really low price: a .desktop and 2 method removal from the plugin
interface in Kate. If you are not going to accept that, I can't do anything
more. I just worked as hard as I could on this stuff, and you people, your
collaboration has been near to 0.
So, finally, everything is on your hands. On monday I'm committing all the
work related to KCModules and I would like to know if I have to commit my
changes on doc word completion plugin too or not, because you are going to
revert everything.
Bye,
Rafael Fernández López.
[Attachment #5 (text/html)]
<pre>Am Mittwoch, 8. August 2007 21:37:11 schrieb Rafael Fernández López:<br>> \
Hi again,<br>><br>> I have been thinking that if you want I can write a dummy \
plugin with<br>> a dummy config dialog (that won't be installed, just on SVN \
as a <br>> plugin, but not install sentence on CMakeLists.txt), but just as \
a<br>> how-to write a plugin for kate.<br>><br>> So, what do you think about \
removing only those two methods from the<br>> plugin interface ? <br>><br>> \
virtual bool configDialogSupported () const;<br>> virtual void configDialog \
(QWidget *parent);<br>><br>> Please take in count is something regarding \
KPluginSelector now.<br>><br>> Right now, as far as I know, KPluginSelector is \
used by Konqueror, <br>> Kopete and KWin. No one reported any kind of problem with \
it. I hope<br>> Kate will too, but as I said on a previous email is just a bit \
of<br>> effort, for example, removing those methods from the plugin interface \
<br>> and letting KPluginSelector do its work.<br>><br>> Adding the method \
you said on other email<br>> supporsConfigDialog(KPluginInfo*, ...) would be \
redundant because that<br>> information could collide with the real information it \
has about <br>> KCModules. For example if you said false and it found KCModules \
for<br>> that plugin, or viceversa.<br>><br>> What's more, for adding \
code to kdelibs I think there is a minimum of<br>> 2 or 3 applications needing \
that for adding it. Please understand is a <br>> very little change on Kate and so \
much winning.<br>I don't think so, it makes plugins that much harder to write for \
zero bonus, <br>beside that apps must use the kpluginselector, I don't think \
that's really a <br>plus. The apps you name use some very limited plugins, as \
there plugins don't <br>deal with any document/view or anything. I think it makes \
sense to let the <br>KTextEditor stuff remain and just avoid kpluginselector in kate, \
don't know <br>if people will really miss that, or?</pre>This stuff makes me \
extremely sad. As I said what KPluginSelector gives users is in a part of the desktop \
(plugin stuff) a unified look on all apps, for a really low price: a .desktop and 2 \
method removal from the plugin interface in Kate. If you are not going to accept \
that, I can't do anything more. I just worked as hard as I could on this stuff, \
and you people, your collaboration has been near to 0. <br><br>So, finally, \
everything is on your hands. On monday I'm committing all the work related to \
KCModules and I would like to know if I have to commit my changes on doc word \
completion plugin too or not, because you are going to revert everything. \
<br><br><br>Bye,<br>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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic