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

List:       kde-devel
Subject:    Re: KPlugins - summary
From:       Vladimir Lobak <vels () vdo ! net>
Date:       1997-05-14 10:52:11
[Download RAW message or body]

On Tue, 13 May 1997, Ashley Winters wrote:

[skip]
> > > As i've wrote in former mail, please think one step further, about 
> > > a macro language access to application. The kind of language should be 
> > > a secondary problem; but kparts should offer more functionality for 
> > > access of "kobjects" features than load/save/print: 
> > > 
> > >  - text plugin:  goto_begin_of_line, insert_date
> > >  - table plugin: fill_row_with_value, summ_of_row
> > >  - image plugin: dither_gray
> > > 
> > > I don't know if i'm right, whether this should be part of kparts, but
> > > for getting full power of an application, we need a macro language.
> > > Think about a drawing widget, which will be driven by an html rederer
> > > macro - HTML Editor. This is one we could learn by microsoft!
> > > 

  The current set/get access to plugin resources allows you to specify any
option as a string (similar to X resources). This allows all plugins to
use one generic API and is very flexible IMO.

> > > 			Gruss
> > > 				Kay 
> > > 
[skip]

> Speaking as the author of PerlQt, amen. But once you get the frame-work
> done, the API mapping isn't that hard (at least for PerlQt). I could
> probably interface libkde to PerlQt in a week or two. Whereas all of Qt
> took... well... lets say that there's an old version with a time-stamp in
> 1996. :)
> 

  That's my main task for now - to get things working. I really like all
the ideas you guys come up with, but until we have some basic plugins 
working as part of KDE i'll not add any 'super' features (automatic download
of plugins, scripting language, plugin daemon etc...).

[skip]
> I think that if you decide to go through with some form of this, that it
> would be futile to try to define every API for every possible plugin
> class. You can probably agree with that. But the important APIs should be
> defined. Perhaps the most important, I think, is sound. Beyond that and
> maybe a couple of others, I suggest that authors collaborate and setup a
> de-facto standard. Perhaps also an API registration system with
> designated coordinators. That would invite an API certification. Nothing
> ANSI-like, just a rubber-stamp and a 'doncha think you should document
> that a bit more?'.
> 
  
  My original intention was to provide the generic API for plugins. This
allows me to connect them seamlessly into one chain. IMO defining specific
API for each specific task (text, audio, url, etc..) is a bad idea. You
won't get any standartization this way. Just look at Microsluth.

  Btw, if anyone would like to contribute on this macro language idea, i'd
happily give this part to him. I'm myself very unfamiliar with multi-language
issues.

> 
> Ashley Winters
> 

--
#include <disclaimer.h>
html *address(void) 
{ return Vels == (mailto:vels@vdo.net | http://aldan.ml.org:7000/vels); }

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