|
|
The KAction class (and derived and super classes) provide a way to easily encapsulate a "real" user-selected action or event in your program. For instance, a user may want to "paste" the contents of the clipboard or "scroll down" a document or "quit" the application. These are all @bf actions -- events that the user causes to happen. The KAction class allows the developer to deal with this actions in an easy and intuitive manner.
Specifically, the KAction class encapsulated the various attributes to an event/action. For instance, an action might have an icon that goes along with it (a clipboard for a "paste" action or scissors for a "cut" action). The action might have some text to describe the action. It will certainly have a method or function that actually @bf executes the action! All these attributes are contained within the KAction object.
The advantage of dealing with Actions is that you can manipulate the Action without regard to the GUI representation of it. For instance, in the "normal" way of dealing with actions like "cut", you would manually insert a item for Cut into a menu and a button into a toolbar. If you want to disable the cut action for a moment (maybe nothing is selected), you woud have to hunt down the pointer to the menu item and the toolbar button and disable both individually. Setting the menu item and toolbar item up uses very similar code.. but has to be done twice!
With the Action concept, you simply "plug" the Action into whatever GUI element you want. The KAction class will then take care of correctly defining the menu item (with icons, accelerators, text, etc) or toolbar button.. or whatever. From then on, if you manipulate the Action at all, the effect will propogate through all GUI representations of it. Back to the "cut" example: if you want to disable the Cut Action, you would simply do 'cutAction->setEnabled(false)' and the menuitem and button would instantly be disabled!
This is the biggest advantage to the Action concept -- there is a
one-to-one relationship between the "real" action and all
GUI representations of it.
The steps to using actions are roughly as follows
Here is an example of enabling a "New [document]" action
KAction *newAct = new KAction(i18n("&New"), QIconSet(BarIcon("filenew")), KStdAccel::key(KStdAccel::New), this, SLOT(fileNew()), this);
This line creates our action. It says that wherever this action is displayed, it will use "&New" as the text, the standard icon, and the standard accelerator. It further says that whenever this action is invoked, it will use the fileNew() slot to execute it.
QPopupMenu *file = new QPopupMenu; newAct->plug(file);
That just inserted the action into the File menu. You can totally forget about that! In the future, all manipulation of the item is done through the newAct object.
newAct->plug(toolBar());
And this inserted the Action into the main toolbar as a button.
That's it!
If you want to disable that action sometime later, you can do so with
newAct->setEnabled(false)
and both the menuitem in File and the toolbar button will instantly be disabled.
Note: if you are using a "standard" action like "new", "paste", "quit", or any other action described in the KDE UI Standards, please use the methods in the KStdAction class rather then defining your own.
If you are using KAction within the context of the XML menu and toolbar building framework, then there are a few tiny changes. The first is that you must insert your new action into an action collection. The action collection (a KActionCollection) is, logically enough, a central collection of all of the actions defined in your application. The XML UI framework code in KXMLGUI classes needs access to this collection in order to build up the GUI (it's how the builder code knows which actions are valid and which aren't).
Inserting your action into the collection is very simple. To use a previous example:
KAction *newAct = new KAction(i18n("&New"), QIconSet(BarIcon("filenew")), KStdAccel::key(KStdAccel::New), this, SLOT(fileNew()), actionCollection());
The only change is to use 'actionCollection()' as the parent of the action. That's it!
Also, if you use the XML builder framework, then you do not ever have to plug your actions into containers manually. The framework does that for you.
Generated by: root@porky.devel.redhat.com on Wed May 10 08:56:43 2000, using kdoc 2.0a35. |