|
|
The following standard actions are defined by the host of the view :
[selection-dependent actions] cut : copy selected items to clipboard and notifies that a cut has been done, using DCOP copy : copy selected items to clipboard (and notifies it's not a cut) pastecut : called when doing a paste after a cut pastecopy : called when doing a paste after a copy trash : move selected items to trash del : delete selected items (couldn't call it delete!) shred : shred selected items (secure deletion) properties : show file/document properties editMimeType : show file/document's mimetype properties <P> [normal actions] print : print :-) reparseConfiguration : re-read configuration and apply it refreshMimeTypes : if the view uses mimetypes it should re-determine them <P>
The view defines a slot with the name of the action in order to implement the action. The browser will detect the slot automatically and connect its action to it when appropriate (i.e. when the view is active)
The selection-dependent actions are disabled by default and the view should enable them when the selection changes, emitting enableAction.
The normal actions does not depend on the selection. For each slot that is defined in the second list, the action is automatically enabled.
A special case is the configuration slots, not connected to any action directly, and having parameters. [configuration slot] setSaveViewPropertiesLocally( bool ): if true, view properties are saved into .directory otherwise, they are saved globally.
An extension class for container parts.
Base class for parts.
A "part" is a GUI component, featuring
About the widget : Note that KParts::Part does not inherit QWidget. This is due to the fact that the "visual representation" will probably not be a mere QWidget, but an elaborate one. That's why when implementing your KParts::Part (or derived) you should call KParts::Part::setWidget() in your constructor.
About the GUI elements : Those elements trigger actions, defined by the part (action()). The layout of the actions in the GUI is defined by an XML file (setXMLFile()).
See also PartReadOnly and PartReadWrite, which define the framework for a "viewer" part and for an "editor"-like part. Use Part directly only if your part doesn't fit into those.
Base class for all KParts events.
This event is sent to a Part when its GUI has been activated or deactivated.
See also: guiActivateEvent, This, is, related, to, PartActivateEvent, but, the, difference, is, that, GUIActivateEvent, happens, later, (when, the, GUI, is, actually, built), only, for, parts, that, have, GUI, elements, and, only, if, using, KParts::MainWindow.
This event is sent by the part manager when the active part changes. Each time the active part changes, it will send first a PartActivateEvent with activated=false, part=oldActivePart, widget=oldActiveWidget and then another PartActivateEvent with activated=true, part=newPart, widget=newWidget.
This event is sent when a part is selected or deselected.
A generic factory object to create a Part. @see_also KLibFactory.
A KPart-aware main window, whose user interface is described in XML.
Inherit your main window from this class and don't forget to call setXMLFile() in the inherited constructor.
It implements all internal interfaces in the case of a KTMainWindow as host: the builder and servant interface (for menu merging).
The part manager is an object which knows about a collection of parts (even nested ones) and handles activation/deactivation.
Applications that want to embed parts without merging GUIs only use a KPartManager. Those who want to merge GUIs use a KPartsMainWindow for example, in addition to a part manager.
Parts know about the part manager to add nested parts to it. See also KParts::Part::manager and KParts::Part::setManager .
A plugin is the way to add actions to an existing KParts application, or to a Part.
The XML of those plugins looks exactly like of the shell or parts, with one small difference: The document tag, named kpartplugin should have an additional attribute, named "library", and contain the name of the library implementing the plugin.
If you want this plugin to be used by a part, you need to install the rc file under the directory "data" (KDEDIR/share/apps usually)+"/instancename/kpartplugins/" where instancename is the name of the part's instance.
Base class for all parts.
Base class for any "viewer" part.
This class takes care of network transparency for you, in the simplest way (synchronously). To use the built-in network transparency, you only need to implement openFile(), not openURL(). To prevent network transparency, or to implement it another way (e.g. asynchronously), override openURL().
KParts Application can use the signals to show feedback while the URL is being loaded.
ReadOnlyPart handles the window caption by setting it to the current URL (set in openURL, and each time the part is activated). If you want another caption, set it in openFile and (if the part might ever be used with a part manager) in guiActivateEvent
Base class for an "editor" part.
This class handles network transparency for you. Anything that can open a URL, allow modifications, and save (to the same URL or a different one).
A read-write part can be set to read-only mode, using setReadWrite.
Part writers : Any part inheriting ReadWritePart should check isReadWrite before allowing any action that modifies the part. The part probably wants to reimplement setReadWrite, disable those actions. Don't forget to call the parent setReadWrite.
Generated by: root@porky.devel.redhat.com on Wed May 10 08:57:00 2000, using kdoc 2.0a35. |