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

List:       kde-core-devel
Subject:    Re: Writing KParts plugins
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2000-07-02 23:10:51
[Download RAW message or body]

Simon Hausmann wrote:
> 
> 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.

We already have it, what I'm suggesting is that we make it usable via
valid
XML DTD. At the moment every plugins .rc file is invalid because the DTD
is
wrong. You must specify a kpartplugin element in the XML according to
everything I've been told, but the DTD does not define one. Thing is
certainly
a bug - are you saying that we should not use kpartyplugin at all? If so
then all the examples, docs and messages from everyone else are
incorrect.
Please clarify what you mean. At the moment I haven't seen a single XML
file that is valid according to the DTD you refered to. :-(

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

Then please write a spec. At the moment it is totally unclear how this
stuff works and how it is meant to be used. I proceeded as far as I did
because David and Dawit pointed me to some examples, not because the
docs
were any good. I am trying to fix the docs, but I have nothing to
work with except emails, and you just contradicted everyone else. :-(

This XML stuff is great, but it's a complete waste of time if noone
knows
how it's supposed to work.

> 
> 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!)

Did you read my comments about the version attribute? It is defintely
something we need to tie down.

Cheers

Rich.

> 
> Bye,
>  Simon

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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