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

List:       kfm-devel
Subject:    Re: PATCH adds PluginInterface to KonqPopupMenu
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-10-29 18:32:37
[Download RAW message or body]

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.

> 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 :-)

> 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?
:)
 
> 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? :)


Simon

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