[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 7:58:01
Message-ID: 93f85fee0708080058u395e2546lc94a4924ba8b8792 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
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.
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.
About the connect()... we could do an effort. It's now or never. Why can't
we remove from the plugin interface of KATE the part related for showing
configuration dialogs ? That would imply removing:
virtual bool configDialogSupported () const { return false; }
virtual void configDialog (QWidget *parent) { Q_UNUSED(parent); }
from the interface. Only that, no more changes needed.
...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.
To KCModule, because it provides a perfect interface for configuration
purposes, that is for what it was designed.
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 :( ).
As I said before... I think the best option is to choose kdelibs code, but
that is up to you, without any doubt.
I am doing lots of work because I found something wasn't fully correct on
the way KCModules were loaded (all about the KCModuleInfo patches), and I'm
fixing every *.desktop file related, to let a library plugin provide the
plugin and the configuration dialog for it.
Bye and thanks,
Rafael Fernández López.
[Attachment #5 (text/html)]
2007/8/8, Dominik Haumann <<a \
href="mailto:dhdev@gmx.de">dhdev@gmx.de</a>>:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On \
Wednesday 08 August 2007, Christoph Cullmann wrote:<br>> \
Hi,</blockquote><div><br>Hi, <br></div><br><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> > guess have spend to much time on working instead of \
watching here :)<br>> I am fine with the new GUI of the plugin selector, but my \
problem is,<br>> that Dominik is right, it should work like the old one or it is \
not <br>> acceptable and must be reverted. We don't want a more complex \
structure<br>> for plugins, they should stay plain easy. Before, it was just the \
matter<br>> of some minutes to add the one function and code there the dialog, now \
<br>> you need to adjust cmake files, write additional desktop files and \
all,<br>> which is, IMHO, overkill. If the pluginsselector is designed to \
allow<br>> only this, we must stay with our old code, which was not that beautiful \
<br>> visual-wise but worked. From my 5 minutes look at the selector, I \
think<br>> it's not really possible to reuse it for our approach, which is bad \
:/<br>> Rafael, have you a different opinion? If it is possible to get the old \
<br>> behaviour back together with the new (nicer) GUI, I would be happy,<br>> \
otherwise, please revert it to the old handcrafted selector, if you have<br>> \
time, you can beautify it, too, but I don't want to have this additional <br>> \
work for ktexteditor plugins.<br>><br>> cu<br>> \
Christoph</blockquote><div><br> Yeah, an additional desktop file is needed in \
comparation to the older plugin selector.<br></div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> I believe our main concern is still this:<br>We \
don't want to change the KTextInterfaces<br>(e.g. why do we have deps on KCModule \
etc just to use KPluginSelector)<br><br>the possibilities for KDE4 are:<br>1. revert \
everything so it works as in KDE3 </blockquote><div> </div>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. <br><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. add our own \
Configure... button below KPluginSelector just as in KDE3.<br> \
KPluginSelector's API would have to be extended: <br> - \
KPluginInfo* currentItem() (we somehow have to map this to \
a<br> KatePlugin \
then)<br> - signal \
currentItemChanged()</blockquote><div><br>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. <br></div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">3. use KPluginSelector completely, but its API still \
would need to be<br> extended, e.g.:<br> - \
setConfigurable(KPluginInfo*, bool)<br> - \
connect(kPluginSelector, SIGNAL(showConfig(KPluginInfo*)), \
this,<br> SLOT(foo(KPluginInfo*)));</blockquote><div><br>Yeah, \
check my patches:<br><br><a \
href="http://media.ereslibre.es/2007/08/kdelibs-08082007.diff"> \
http://media.ereslibre.es/2007/08/kdelibs-08082007.diff</a><br><a \
href="http://media.ereslibre.es/2007/08/kdepimlibs-08082007.diff">http://media.ereslibre.es/2007/08/kdepimlibs-08082007.diff</a><br><a \
href="http://media.ereslibre.es/2007/08/kdebase-08082007.diff"> \
http://media.ereslibre.es/2007/08/kdebase-08082007.diff</a><br><br>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. <br><br>About the \
connect()... we could do an effort. It's now or never. Why can't we remove \
from the plugin interface of KATE the part related for showing configuration dialogs \
? That would imply removing:<br><br> virtual bool \
configDialogSupported () const { return false; }<br> virtual void \
configDialog (QWidget *parent) { Q_UNUSED(parent); }<br><br>from the interface. Only \
that, no more changes needed.<br></div><br><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">
...or something similar. The api is for sure not perfect, but you get the<br>idea. (I \
really wonder anyway, why KPluginSelector is so tightly coupled to<br>KCModule for \
example.</blockquote><div><br>To KCModule, because it provides a perfect interface \
for configuration purposes, that is for what it was designed. \
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Actually both is 100% \
orthogonal. KPluginSelector's<br>API could be more flexible so that you could do \
both. Time for 4.0 is<br>getting short :( ).</blockquote><div><br>As I said \
before... I think the best option is to choose kdelibs code, but that is up to you, \
without any doubt.<br><br>I am doing lots of work because I found something \
wasn't fully correct on the way KCModules were loaded (all about the KCModuleInfo \
patches), and I'm fixing every *.desktop file related, to let a library plugin \
provide the plugin and the configuration dialog for it. <br></div><br></div><br>Bye \
and thanks,<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