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

List:       kde-devel
Subject:    Re: KPlugins - summary
From:       Mats Loman <lom () wombat ! ludvika ! se>
Date:       1997-05-14 23:00:30
[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 ).
> 
> But never the less we should define a language independend API
> for common task like TextEdit, Draw, PlaySound etc.
> 
> 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.
> 
> We need a nice and esay IDL and some compiler that generates the stuff
> for various languages ( C++, Python, Perl ).
> 
> But the above task is not easy. Some ideas on this ?
> 
> Bye
> Torben
> 
Yes I have !

I'm in a slow process of defining something similar to COM

So far I have rather good idea of how it will work. It will be 
based on interfaces. I have promised you some kind of doucmentation
of my ideas. Please have litte pations, you cannot try to define a
thing like this very quickly without missing a lot.

So far I can solve these thing with Interfaces:

 1. Plugins.
 2. Some kind of OLE.
 3. Your KParts.    
 4. The interface to a "Macro language".
 5. COM

Everybody: Please dont rush to implement these things separately, I
           think that with a decent IDL and Interface functionality we
           can solve all 5 issues real nice and easy. 
 
But for the moment I think its more important to release KDE
to get more time for this new functionality later.

//Mats Loman 

I  

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