[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-03 8:30:36
[Download RAW message or body]



On Mon, 3 Jul 2000, Richard Moore wrote:

> 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.

Oh, yes, they are incorrect :-) Everyone should use kpartgui, not
kpartplugins.

Ohh! Now I see. I said it wrong at
http://lists.kde.org/?l=kde-core-devel&m=94753837118017&w=2 . Hmmmm, well,
there have been lots of changes since then anyway, so... ;-)

D'oh! and the docu in plugin.h is wrong, too . Argh, it's my fault :-(

I'm on my way to fix this %-}

(in fact currently we have only one kparts plugin in the CVS, and that one
uses kpartgui as document element ;-) (kspread/plugins/calculator)

> 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 normal part .rc files in the CVS should be all valid (at least I onced
went through all of them and ran them your rxp) . And the only plugin I've
found sofar uses kpartgui, too, and is valid IIRC .

Ah, some of them have some "undefined" tags, because they use kurt's
ui_standards stuff.

> > 
> > (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. :-(

I'm very sorry for the trouble! My apopolgies!

I think your tutorial is definitely the right spec :-) . If there's
anything you would like me to add/fix/correct, please let me know.

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

Yes, I agree. Well, it's all still young/unreleased code :-}

(and the idea of using <kpartgui> for everything is exactly to make it
easier (one DTD for all, 100% same syntax for all) . Just one different
attribute (library) and a different location ($hostInstance/kpartplugins
instead of $instance)

> > 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.

Ah, two different things here, I think :-)

I was talking about the versioning of the .rc file itself. Here I think
the current version should work fine.

However for the library versioning.. hmm....

Well, parts and plugins are supposed to be linked with KDE_PLUGIN, no? And
KDE_PLUGIN expands to -avoid-version -module -no-undefined -> The DSO has
no version in its filename. But well, the value of the library attribute
is directly passed to KLibLoader/libltdl anyway, so I guess if libltdl can
successfully deal with dlopen( "libfoo.so.1.3" ) then a 
"versioning" should work.

What do you think?

Bye,
 Simon

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