Difference between revisions of "Development/Architecture/KDE3/Action Pattern"

Jump to: navigation, search
(port http://developer.kde.org/documentation/library/kdeqt/kde3arch/actionpattern.html)
 
 
(3 intermediate revisions by 2 users not shown)
Line 17: Line 17:
 
From the programmer's point of view changing the state of "copy"
 
From the programmer's point of view changing the state of "copy"
 
(enable/disable for example) means calling methods of three ui container
 
(enable/disable for example) means calling methods of three ui container
objects (menu, toolbar and popupmenu) . And each time the same "thing"
+
objects (menu, toolbar and popupmenu). And each time the same "thing"
 
is added somewhere else in the application's ui, you have to go through the
 
is added somewhere else in the application's ui, you have to go through the
whole code and update any code which is supposed to change the "thing" .
+
whole code and update any code which is supposed to change the "thing".
  
 
Now from the user's point of view that "thing" is nothing but an action. An
 
Now from the user's point of view that "thing" is nothing but an action. An
action he is able to activate (by activating the corresponding ui item) ,
+
action he is able to activate (by activating the corresponding ui item),
 
an action he has control over.
 
an action he has control over.
  
Line 52: Line 52:
 
The KDE UI library provide action class implementations for most ui  
 
The KDE UI library provide action class implementations for most ui  
 
container classes and most kinds of ui items (from a simple item to a list of  
 
container classes and most kinds of ui items (from a simple item to a list of  
items or toggle items for example) .
+
items or toggle items for example).
  
 
When no action class is available for a certain ui container type or kind of item,
 
When no action class is available for a certain ui container type or kind of item,
 
then you should simply inherit from the nearest action class available and
 
then you should simply inherit from the nearest action class available and
 
re-implement the virtual plug()/unplug() methods and the property setting
 
re-implement the virtual plug()/unplug() methods and the property setting
methods (like setText() for example) .
+
methods (like setText() for example).
  
 
When inheritting from an action class, don't forget to call the previous
 
When inheritting from an action class, don't forget to call the previous
Line 63: Line 63:
  
 
''Initial Author:'' [mailto:hausmann@kde.org Simon Hausmann]
 
''Initial Author:'' [mailto:hausmann@kde.org Simon Hausmann]
 +
 +
[[Category:KDE3]]
 +
[[Category:Architecture]]

Latest revision as of 22:35, 11 March 2007

[edit] Introduction

Creating a graphical user interface with the Qt/KDE3 development framework often means calling a lot of insertItem() and insertButton() like methods on all kinds of menu-, tool- and statusbar objects.

This concept has two major disadvantages for dynamic ui's, where standard ui items get activated/deactivated, item texts or pixmaps get changed or certain elements get disabled, depending on the user's input and the application's data. With the standard framework there's a lot of unnecessary code duplication and complexity, regarding the handling of these elements.

An often mentioned example are standard editing ui items, like "cut", "copy" and "paste". These items show up in multiple places in the ui, like in the toolbar, the "edit" menu in the menubar and in a context sensitive popup menu.

From the programmer's point of view changing the state of "copy" (enable/disable for example) means calling methods of three ui container objects (menu, toolbar and popupmenu). And each time the same "thing" is added somewhere else in the application's ui, you have to go through the whole code and update any code which is supposed to change the "thing".

Now from the user's point of view that "thing" is nothing but an action. An action he is able to activate (by activating the corresponding ui item), an action he has control over.

[edit] The Action Concept in KDE

For the user an action is one thing, for the developer it used to mean dealing with multiple ui container objects. The KDE Action classes centralize this scheme for the developer, too.

The developer allocates a KAction object and connects to the activation signal of the object, which gets emitted whenever the user decides to activate the action.

Now this action object can be plugged into any kind of ui container object, like a QMenuBar or a KToolBar for example. The process of plugging in the object is the same for all container types, it's just calling the plug() method. The action object then automatically takes care of inserting "itself" into the container object and therefore creates a visual representation of the action, like a menu item or a toolbar button, which the user is able to activate, select or choose, for example, depending on the type of action.

The point is that an action object can be plugged into multiple container objects at the same time. Of course changing a property of an action, like the displayed text for example, results in an immediate change in all plugged containers.

[edit] The Action Classes

The KDE UI library provide action class implementations for most ui container classes and most kinds of ui items (from a simple item to a list of items or toggle items for example).

When no action class is available for a certain ui container type or kind of item, then you should simply inherit from the nearest action class available and re-implement the virtual plug()/unplug() methods and the property setting methods (like setText() for example).

When inheritting from an action class, don't forget to call the previous implementation!

Initial Author: Simon Hausmann


This page was last modified on 11 March 2007, at 22:35. This page has been accessed 3,049 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal