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

List:       kfm-devel
Subject:    Re: popupmenu in konqy
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-03-31 9:14:59
[Download RAW message or body]

On Fri, Mar 31, 2000 at 11:31:50AM +0200, Simon Hausmann wrote:
> 
> 
> On Fri, 31 Mar 2000, David Faure wrote:
> 
> > Sounds good ;-)
> > 
> > Since it's already action-based, I guess what you could would be
> > - define an XML for the standard popupmenu (instead of my manual plugs)
> > - allow the developer to pass another XML (QDomDocument, whatever) and
> > action collection to be merged into it.
> > 
> > Re-implementing a "minimalistic merging" is perhaps too much re-inventing
> > the wheel if we can use the XML-GUI merging for that, no ?
> 
> Well, I don't know if it's a bit too much overhead to use the complete
> xmlgui merging :)
> 
> but OTOH it provides maximum flexibility :)
> 
> OK, so we could let the KonqPopupMenu inherit from KXMLGUIClient, provide
> some standard actions (and allocate the in the constructor), connected to
> the current existing internal slots. Konqueror itself can then add new
> actions via the actionCollection the popupmenu exports (same for kdesky) .
> 
> This way we can let parts embedded in konqueror provide KXMLGUIClient's,
> which can be added to the KXMLGUIFactory the konqpopupmenu allocates.
> 
> What's left is the question about the XML the konqpopupmenu provides.
> Perhaps we should let konqy modify the QDomDocument to add new elements
> for actions like "Fullscreen mode", etc. ?

Hmm - isn't that what GUI merging is about ? If the app provides
its XML for the additionnal actions, it doesn't need to "manually modify"
any QDomDocument. The merging is done in konqpopupmenu the usual way...

> What do you think? Is that too much overhead?
I don't know - that's hard to tell.
But I think that by going for the full-fledged solution,
we even give more: the ability for [experienced] users to customize this menu
(removing entries, moving them - can't add something though ;-)
And we assure our future by not going for a hack that we would
replace with the real solution at some point ;-)

As long as the objects involved with this aren't kept in memory
when the popupmenu isn't shown, I think it's ok.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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