[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: [IDEA] kdelibs/kutils/kpluginselector
From: "=?UTF-8?Q?Rafael_Fern=C3=A1ndez_L=C3=B3pez?=" <ereslibre () gmail ! com>
Date: 2006-10-30 23:47:35
Message-ID: 93f85fee0610301547h4e984c33gf2ebe15aa0431a8d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
Hi,
After taking a look to the code I wrote (the patch), and some app's needs
(konqueror, kopete...) kpluginselector & friends (kpluginselector_p.h),
should be changed a bit (and the patch is totally invalid). My motivation to
propose this change is the next:
File: kdebase/konqueror/konq_extensionmanager.cc (lines 77 and 78):
// There's a limitation of KPluginSelector here... It assumes that all
plugins in a given widget (as created by addPlugins)
// have their config in the same KConfig[Group]. So we can't show
konqueror extensions and khtml extensions in the same tab.
I have thought of a very neat change, and maybe preferred for eye-candy on
the future. Right now, if different calls to addApplet are executed, and
they had different categories, a tab widget on the left is created, and the
QTreeWidget will remain into the KTabWidget. On the path of achieving the
main goal (what konqueror says) I propose to have all plugins in the same
QTreeWidget, but categorized. I mean, we could add a visual eye-candy
separator (not selectable, or maybe selectable and showing information about
the category at the right). So at a first look to the dialog the user will
know what plugins are available.
For achieving all these goals I propose the next KPluginInfoLVI class:
class KPluginInfoLVI : public QTreeWidgetItem
{
public:
KPluginInfoLVI(KPluginInfo *pluginInfo, QTreeWidget *parent);
~KPluginInfoLVI();
/**
* Setter methods
*/
void setPluginInfo(KPluginInfo *pluginInfo);
void setCfgGroup(KConfigGroup *cfgGroup);
void setCfgWidget(QWidget *cfgWidget);
void setModuleProxy(KCModuleProxy *moduleProxy);
/**
* Getter methods
*/
KPluginInfo* pluginInfo() const;
KConfigGroup* cfgGroup() const;
QWidget* cfgWidget() const;
KCModuleProxy* moduleProxy() const;
private:
KPluginInfo *m_pluginInfo;
KConfigGroup *m_cfgGroup;
QWidget *m_cfgWidget;
KCModuleProxy *m_moduleProxy;
};
This way we can see that konqueror needs are scoped:
1. The QTreeWidgetItem will have all the information about what it holds.
2. As before, insertKCM will be called only when needed (when the user
clicks on an item that wasn't clicked before and needs to be created), so no
memory wasting will happen.
From my point of view, these are only advantages (maybe the
kpluginselector.h and kpluginselector.cpp code will be reduced as
side-effect [advantage too]). But it is just that, my point of view. I would
like to know yours ;)
Bye,
Rafael Fernández López.
[Attachment #5 (text/html)]
Hi,<br><br>After taking a look to the code I wrote (the patch), and some app's needs \
(konqueror, kopete...) kpluginselector & friends (kpluginselector_p.h), should be \
changed a bit (and the patch is totally invalid). My motivation to propose this \
change is the next: <br><br>File: kdebase/konqueror/konq_extensionmanager.cc (lines \
77 and 78):<br><br> // There's a limitation of KPluginSelector \
here... It assumes that all plugins in a given widget (as created by \
addPlugins)<br> // have their config in the same KConfig[Group]. So \
we can't show konqueror extensions and khtml extensions in the same tab. <br><br>I \
have thought of a very neat change, and maybe preferred for eye-candy on the future. \
Right now, if different calls to addApplet are executed, and they had different \
categories, a tab widget on the left is created, and the QTreeWidget will remain into \
the KTabWidget. On the path of achieving the main goal (what konqueror says) I \
propose to have all plugins in the same QTreeWidget, but categorized. I mean, we \
could add a visual eye-candy separator (not selectable, or maybe selectable and \
showing information about the category at the right). So at a first look to the \
dialog the user will know what plugins are available. <br><br>For achieving all these \
goals I propose the next KPluginInfoLVI class:<br><br>class KPluginInfoLVI : public \
QTreeWidgetItem<br>{<br>public:<br> KPluginInfoLVI(KPluginInfo \
*pluginInfo, QTreeWidget *parent);<br> ~KPluginInfoLVI(); \
<br><br> /**<br> * Setter \
methods<br> */<br> void \
setPluginInfo(KPluginInfo *pluginInfo);<br> void \
setCfgGroup(KConfigGroup *cfgGroup);<br> void setCfgWidget(QWidget \
*cfgWidget);<br> void setModuleProxy(KCModuleProxy *moduleProxy); \
<br><br> /**<br> * Getter \
methods<br> */<br> KPluginInfo* \
pluginInfo() const;<br> KConfigGroup* cfgGroup() \
const;<br> QWidget* cfgWidget() const;<br> \
KCModuleProxy* moduleProxy() const;<br><br>private: <br> \
KPluginInfo *m_pluginInfo;<br> KConfigGroup \
*m_cfgGroup;<br> QWidget *m_cfgWidget;<br> \
KCModuleProxy *m_moduleProxy;<br>};<br><br>This way we can see that konqueror needs \
are scoped:<br><br>1. The QTreeWidgetItem will have all the information about what it \
holds. <br>2. As before, insertKCM will be called only when needed (when the user \
clicks on an item that wasn't clicked before and needs to be created), so no memory \
wasting will happen.<br><br>From my point of view, these are only advantages (maybe \
the kpluginselector.h and kpluginselector.cpp code will be reduced as side-effect \
[advantage too]). But it is just that, my point of view. I would like to know yours \
;)<br><br>Bye,<br>Rafael Fernández López.<br>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic