kdevelop/kdevelop/lib

[Simon Hausmann]

On Fri, 23 Jun 2000, Bernd Gehrmann wrote:

> On Fri, 23 Jun 2000, Simon Hausmann wrote:
> > Out of curiousity: Why don't you make it inherit from KParts::Part ? :-)
> 
> Good question :-) This should be regarded as preliminary
> (and it can easily be changed). I have the impression that 
> the Part semantics do not fit well for components in general. 
> A part is something that can be "activated", and the GUI of 
> the application changes dependent on whether it's active or 
> not. This is appropriate for the text editor or the html
> viewer: when a text editor is active, the "Edit" menu should
> have a "Search" item that searches in the text; when the
> html view is active, the "Search" item should search in the
> html content.
> 
> However, for other things, it's different: A "Grep" component
> should always offer a menu item "Grep". The debugger should
> always offer a menu item "Continue", regardless whether one
> of its windows is focused or not. Maybe this can be achieved
> with KParts, but I couldn't find any example doing it.

Yes, these semantics (parts only for stuff which is activateable) were a
major limitation of the old OpenParts 8-)

The question of what to choose as base interface for a component (or a
derived base interface, like KDevComponent) is indeed difficult and
important. (IMO)

I fully agree that it depends on the type of integration (i.e. a htmlview
versuse a small grep component) . It's probably also a matter of personal
taste :-)

Hmmm, let's see about the possible choices:

- KParts::BaseBase (this one is almost completely a internal thingy --
                    it's safe to ignore it ;-)
- KParts::Part
- KParts::ReadOnlyPart
- KParts::ReadWritePart
- KParts::Plugin

I'd say KParts::Part is good as base class for components which provide:

- a separation between content/data and the visual representation
- a component specific GUI

I think it serves good as base interface for application specific base
interfaces (like KDevComponent) , independend from whether it's an
activateable/deactivable or a "steady" part.

KParts::ReadOnlyPart is for Parts which provide read-only
content. Much like for browsing. A good example for such a component is
khtml :-) . The main point about this interface is that it combines the
data with an addressable location (url) . That's the difference to the
generic KParts::Part.

KParts::ReadWritePart is for documents which are editable by the user. An
example is a wordpard component (well, kwrite :-). As it inherits from
ReadOnlyPart it should be possible to switch the component into read-only
mode (this is an implementation detail however) . The main difference to
ROP is that it provides methods to save/store the data.


Components inheritting from KParts::Part (like ROP, or RWP ;) are
embeddable and useable without any dependency to a shell or a activation
scheme. You can easily embed a part into a non-kparts application. All you
need is to create the component and insert the part's view/widget into the
widget hierarchy. In order to display the component's GUI one obviously
has to use the xmlgui system. But as KTMainWindow inherits from
KXMLGUIBuilder and provides a GUIFactory......... :-)


In environments like koffice or konqueror where you have multiple parts
and where it's important to deal with different activation/deactivation
states of parts, partmanager does a good job ;-) . However one can, as
stated above, use parts without a partmanager. (whereas use==embed, show
the gui, etc. ) .

The idea of KParts::Plugin was a bit different. Here the goal was to
provide a way to automatically load aggregate components without having to
modify the hosting component's sourcecode nor any other resource file.
All you need to do is to specify a .rc file for the component with a
library attribute in the document element. Installing the .rc-file into
$prefix/share/apps/theHostsInstanceName/kpartplugins will make kparts
automatically load the component, as the library name is specified in the
.rc file. The component is loaded within the setInstance() call. So
here the .rc file serves two purposes: On the one hand it describes the
layout of the plugin's GUI and on the other hand it is sort of an entry
point to actually load and access the component (in its shared library) .

As the hosting component is specified as parent QObject the plugin has
direct access to the host. Of course a plugin is always host-specific and
therefore depends on a (probably publically available) host interface.

The kspread calculator plugin is an example here :)
(->has a GUI (toolbar button to bring up the calc widget) and installs an
event filter and listens for selection events in the kspread document)

--> The main point here is to be able to extend the functionality of a
(host) component by aggregation and without the host knowing about it nor
having to touch/modify any of the hosts resources/files. (->interesting
for third-party developers)


Just some thoughts :)


Bye,
 Simon