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

List:       kde-devel
Subject:    Re: KPlugins - summary
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-05-14 1:05:35
[Download RAW message or body]



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

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