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

List:       kde-core-devel
Subject:    RFC: Making KStdActions more generally useful
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-10-28 19:35:14
[Download RAW message or body]

I just had a talk with Simon on IRC about KStdActions. I basically want the 
_DATA_ of KStdActions to be reused in KDialogBase. Obviously the normal 
KAction concept doesn't really fit pushbuttons in dialogs (I started a 
discussion about that before and I am somewhat convinced now ;-), but reusing 
the data from many standard actions would be nice.

I would like Q/KPushButton and KDialogBase to be able to easily add QIconSets 
to the buttons, as all other desktops on this planet already have since ages. 
Qt also supports it by means of QPushButton::setIconSet(), but KDE doesn't 
use this ability anywhere.

Since essentially a 'help' button or a 'help' menu entry are equivalent I 
think it would be nice to share the data by means of a class like 
KStdGuiElement or so (yes, that name sucks, but we couldn't come up with 
something better yet :-).

Then KAction would derive KStdGuiElement and have a constructor that takes a 
KStdGuiElement as parameter. Essentially that means that instead of

--
KAction *quit = KStdAction::quit( this );
--

you would write

--
KAction *quit = new KAction( KStdGuiItem::quit(), this );
--

And to create a pushbutton with this you would use

--
KPushButton *helpButton = new KPushButton( KStdGuiItem::help(), this );
--

This is only the basic idea that we had until Simon had to leave for a 
concert, and we decided to pass this on to core-devel. There are probably 
some problems with this design, though we both pretty much like the overall 
idea and its possibilities.

One known issue is that currently changes to the properties that would go 
into this new class (iconset, text, etc.) are picked up by KAction and 
propagated to all plugged objects. With this new class the way this is done 
needs to be changed a bit. Maybe it is enough to make the setXXX methods 
virtual, but we haven't spent much (read: virtually none) thought on this yet.

With this new class in place KStdAction will be pretty much obsolete, though 
it would be easy to keep it as a wrapper for source compatibility. Internally 
it would just create a KAction with a KStdGuiItem.

And now the obvious question is: what are the opinions on this? Flames, 
suggestions, fixes to this very premature design? Cool ideas that we didn't 
think of yet but that would also be possible with the proper API are also 
welcome, of course...

Martijn

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