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

List:       kde-core-devel
Subject:    Re: Again: KAction
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-06-01 18:56:59
[Download RAW message or body]

On Thu, May 31, 2001 at 04:12:01PM +0200, Martijn Klingens wrote:
> Like I said yesterday in my previous patch: I encountered the 
> icons-in-popupmenus issue by accident, because I was attempting to do 
> something else...
> 
> Attached is another KAction patch that enables to plug at least a basic 
> KAction and a KToggleAction into a plain QWidget. As long as the widget can 
> do its own layout management it's enough to do
> 
> action->plug( widget );
> 
> Otherwise you need to do
> 
> int index = action->plug( widget );
> layout->addWidget( action->representative( index ), ... );
> 
> Or something similar for the used layout.
> 
> Possible uses for this are plugging actions into wizard-style apps. Those 
> normally have neither a menubar nor a toolbar, but can certainly benefit from 
> actions.
> 
> I'm not too familiar with KAction, so please review. The patch is so small 
> that have a strong feeling to forget something, but it already seems to work 
> now, don't ask me why.
> 
> It should _not_ affect the behaviour of actions plugged into toolbars or 
> popupmenu's, so if it does, it's a bug in my code.
 
I'm not sure how useful a default implementation for plain QWidget plugging
is. I mean... I can't think of a case where I want to plug a plain action 
into a plain qwidget and get a QToolButton (outside a QToolBar!) as
representation.

One reason against such an implementation is what you already mention with 
regard to layout management:
If I plug an action into a container then that's it, I don't want to know
about how the representation of the action is inserted internally (from a
developers point of view) . Plugging is an atomic operation.
Now in case of a plain QWidget as container you can't make it an atomic 
operation because a plain QWidget does (obviously) not say anything about
how items (child widgets) are managed/layouted.

This means this default implementation changes the semantics of plug()
by requiring the developer writing the plug() call to think very carefully
where the action is being plugged in (does the widget have layout management,
or does it not? what kind of widget is it? maybe this actions does it
differently?) . Ideally you get actions from one component, get widgets from
another component and you can just plug them together, letting it be an
implementation detail of the action how it represents itself in the
container widgets. The best example where this pattern is used is in the
xmlgui framework.

Bye,
 Simon

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