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

List:       kfm-devel
Subject:    Re: PATCH adds PluginInterface to KonqPopupMenu
From:       Holger Freyther <freyther () gmx ! net>
Date:       2001-10-29 18:46:18
[Download RAW message or body]

On Monday 29 October 2001 19:32, Simon Hausmann wrote:
> On Mon, Oct 29, 2001 at 07:16:08PM +0100, Holger Freyther wrote:
> > activatePopup is kindof needed. It looks cleaner but I can remove it and
> > let the work be done in the constructor.
>
> Hm, IMHO the code in activatePopup is code that belongs into the
> constructor. But if you still want a separate method then I'd suggest
> to call it init() or sth. that stresses more the fact that the purpose
> of the method is to initialize things in the plugin, not to activate a
> popup (after all the plugin doesn't activate the popup :) . I personally
> prefer if the work is done in the constructor though. (like, all
> member variables should be initialized in the constructor of a
> class, like for example the KAction members -> not much of a point
> to have it in a separate method)
>
> > Then the XMLGUI stuff will be done. There will be three way of doing
> > this. Either manipulate the menu directly with popup->insertItem( )... (
> > sometimes
>
> I seriously hope no plugin will do that. I'll just mess up the
> merging and everything. But anyway, we can't prevent it,
> unfortunately.
Fortunately I'm going to do this. You the disknavigator in kicker? Actually
I think something like Copy to -> and then the entries woud be cool
but to do initialize  every dir and add it to konqpopupmenu ist bit to load 
intensive
I'm going to a dummy entry
and in slotXMLGUIFinished I'll replace my dummy entry with a real submenu and 
adds the quick copy to it.
> > needed ), to load a xml gui client or functions like the ones in
> > konq_popupmenu.cc for convience when mainpulating the xml gui by hand (
> > shouldn't be needed ) but the whole point of a plugin is to be dynamic
> > (to which degree?).
>
> Hmmm, you're right here. We need the dynamic aspect. This in fact
> sounds like a generally interesting idea. Maybe it would make sense
> to move the code for building an 'xmlgui' conformant DOM document at
> run-time into a separate class. Sounds like useful functionality and
> maximum code reuse we'd have, too, because KonqPopupMenu itself
> could utilize (aggregate or inherit) that class, as well as the
> plugin. Ah, that in fact justifies a KonqPopupMenuPlugin class for
> real :-)
Inheritance should be good
class KonqXMLManipulator : KXMLGUIClient {}
class KonqPopupMenu : KonqXMLManipulator : QPopupMenu {}



> > The XMLGUIFinished slot is necessary. It's where the base class come in
> > handy. If you do not want it just ignore it.
>
> I didn't really understand why that one is needed. Can you explain?
>
> :)
look above
> :
> > PS: Then there could be a dir in kdeaddons which shows all kind of
> > popupmenus for different apps
>
> Yup. Out of curiousity: What kind of plugins are you thinking of? :)
I think of Quick Copy Quick Move with some kind of caching.
but the rest is my secret. I will make my gallerycreator a plugin once it's 
finished. 
Regards Holger


> Simon

-- 
Kwebsuite http://kwebsuite.sf.net Holger Freyther alias zecke(123)
freyther@yahoo.com
freyther@gmx.net
spamme@keul-dir-ein.de for spmmers

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