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

List:       kde-core-devel
Subject:    Re: Again: KAction
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-06-01 19:35:13
[Download RAW message or body]

--- Simon Hausmann <hausmann@kde.org> wrote:
> 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.

I'm talking about QPushButtons here. I need them in my
own app (both toggle and non-toggle). This way I can
abstract the difference between the representation
(button) and the associated action, just like with
toolbuttons and menu entries.

This way all kinds of standard actions also
automatically take the right IconSet in the button.
Think of buttons like Ok, Cancel, Quit, Close, Save,
Apply and such. Some of these are already used in apps
as both actions and buttons, thus duplicating efforts.
Also, buttons do not use IconSets yet in most of KDE,
but once we implement them a KStdAction style would be
very welcome.

> 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 is true. Like I said you have to rely on the
representative() if you do your own layout managment.
If setAutoAdd() is true this is not needed of course.
Also, you still don't need to know _what_ widget it
is, just that there is a widget that might need a bit
of layout.

But I agree that this is a weak point of my proposal.

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

I don't think that plug should (try to) do layout
management. I think it should rely on either auto-add
or manual management _afterwards_ by means of
representative().

> 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.

Which is almost exactly what I'm doing in my app...

But the manual layout problem is something that
bothers me too, I already have a place where I can't
use setAutoAdd.

But still... Hmm... Anyone else who has some ideas?

Martijn


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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