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

List:       kde-core-devel
Subject:    Re: Writing KParts plugins
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-07-02 21:58:59
[Download RAW message or body]



On Sun, 2 Jul 2000, Richard Moore wrote:

> 
> 
> Simon Hausmann wrote:
> > 
> > On Sun, 2 Jul 2000, Richard Moore wrote:
> > 
> > > >
> > > > - make sure to give your plugin a name in the .rc file. A name attribute
> > > >   in the document element is required by the kpartgui DTD :)
> > >
> > > Where is the DTD? I am already planning part 2 which talks about
> > > using custom toolbar widgets etc. (the example is a news ticker
> > > embedded in a toolbar) and this would a useful document to refer
> > > to.
> > 
> > The DTD is in kdelibs/kdeui/kpartgui.dtd :-)
> > 
> > (but I guess it should probably also be somewhere on developer.kde.org)
> 
> This DTD doesn't match the spec for plugins. :-( It doesn't define
> a kpartplugin tag, so it means all plugins are currently invalid
> XML (because they claim to comply with a DTD). We need to declare
> another top level element like this:
> 
> <!--The root element for plugins that must enclose all other tags in the
> document. -->
> <!ELEMENT kpartplugin ((ActionProperties | MenuBar | ToolBar | Merge |
> DefineGroup | MainWindow | StatusBar | Menu)*)>
> <!ATTLIST kpartplugin
>   name CDATA #REQUIRED
>   version CDATA #REQUIRED
>   library CDATA #REQUIRED
> >
> 
> Note that I have made the library attribute #REQURIED for plugins.
> You should also note that the version is described as required for
> both kpartguis and kpartplugins - this doesn't correspond to any
> of the files I've seen. Perhaps it should be #IMPLIED or #OPTIONAL,
> or do we need to fix all the rc files?

Hmm, I don't think we should distinct between plugins and "parts" ,
regarding the xmlgui description. Actually the idea is (and that's how it
is currently implemented) that .rc-wise the only difference between a
"part" and a "plugin" is that library attribute in the document element,
as it is the initial reference to the component. So all "xml" GUI should
follow the kpartgui DTD and have a kpartgui document element. The
existance of the library attribute and the location of the document itself
( $prefix/share/apps/$hostInstanceName/kpartplugins/ ) identify a plugin.

IMHO we don't need a special kpartplugin element.

(the fact that it works with anything is because we actually don't check
the tagname of the document element)


However what's currently missing regarding plugins is the versioning (as
plugins can have a "local", user-customized GUI and in that case we don't
want to load the plugin twice ) . Well, it's on my TODO :) . But now I'm
very tired after a long train trip and a totally amazing LinuxTag event
:-) (it was really great fun!)


Bye,
 Simon

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