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

List:       kde-devel
Subject:    Re: KPlugins - summary
From:       Ashley Winters <jql () accessone ! com>
Date:       1997-05-13 20:39:02
[Download RAW message or body]

On Wed, 14 May 1997 weis@stud.uni-frankfurt.de wrote:
> On Tue, 13 May 1997, Kay Winkler wrote:
> 
> > Hello Torben 
> > 
> > weis@stud.uni-frankfurt.de wrote:
> > > 
> > > ... 
> > > All parts have common functions not only for sharing window
> > > ressources. They can print/load/save. I am using a Bento like
> > > library that allows storing of any kind of KParts in one file.
> > > 
> > > You may have a look at koffice-0.0.1.tgz. There you can ( perhaps )
> > > get an idea of how things work together.
> > > 
> > > KParts are the choice if you want several parts to share one GUI
> > > and to load/save/print into one file.
> > > 
> > 
> > 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!
> > 
> > 			Gruss
> > 				Kay 
> > 
> > Kay Winkler        Planckstrasse 1         D-64291 Darmstadt 
> > (49)6159/71-2551   Fax:(49)6159/71-2785     K.Winkler@gsi.de
> > 
> > 
> I had this in mind when creating the KFM IPC Compiler. But mapping an 
> API of a C++ class to some language like Python or perl is no trivial
> task at all ( I tried it ).

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

> But never the less we should define a language independend API
> for common task like TextEdit, Draw, PlaySound etc.

Is there any major advantage of this over just using some small, efficient
programs and just having them 'aliased' somehow into kde programming?
Perhaps the idea to just call whatever your editor is 'Editor' and having
an Editor.kdelink point to xemacs (I admit, not efficient in the least) or
whatever. The only major drawback is to your ability to control the
editor after it's run. But what were you really going to do anyways? The
API would have to be *really* specific, and good, if it were to allow
extension via virtual method overriding and such.

> Doing so would result in this: You dont like your chart program anymore?
> Just drop in anotherone. It is just important that they all
> use the KDEChart-API.

Interesting, but it seems a bit complex. I'd be interested to hear what
kind of regulatory system you would setup, or if de-facto standards would
prevail. Gonna setup your own version of ISO? Perhaps KSO? :)

> We need a nice and esay IDL and some compiler that generates the stuff
> for various languages ( C++, Python, Perl ).

Hey, a C++ Qt to PerlQt converter is on my TODO list. Down towards the
bottom. :)

> But the above task is not easy. Some ideas on this ?
> 
> Bye
> Torben

It certainly isn't easy, but it's a good idea to throw around. It
certainly got my brain working.

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

I have no idea if this is the kind of direction you wanted your idea to
go, but it's a reflection of my interpretation of your idea.

Well, that's my few cents.

Ashley Winters

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