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

List:       kde-core-devel
Subject:    Re: [RFC] Unified Application Scripting Interface
From:       ian reinhart geiser <geiseri () yahoo ! com>
Date:       2001-11-12 23:20:25
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 November 2001 05:59 pm, Neil Stevens wrote:
> I did read it.  You only provide an API for the application finding out
> the script's progress.  There's not one line about how the script can get
> information from the application.
>
Section 1.1 Description Last line:
"The idea is that I want to provide a consistent base for scripting and 
automation to be based off of. " 

Basicly what I am trying to say here, is that the script interface provides 
the ability to use either dcop or a parent object that is passed in during 
the loading.  DCOP is inherent, and obvious, the object twin take a little 
more understanding of how Extending and Embedding scripting languages work.

> > This is to bridge the gray area between plug ins and dcop scripting
> > again, this is spelled out in the pdf file, if you read it.
>
> Why do you assume I didn't read it?  You didn't address what I ask - How
> are the scripts supposed to get information from and pass commands back to
> the application?  Your writeup seems more focused on philosophy and
> buzzwords than how people will actually use the thing.
>

The idea is that the script engine runs the script.  The control from the 
main application comes from the *parent via an object twin or via dcop.  

- From python/shell/perl one has access to the dcop interfaces.  From python 
via an object twin you have full access to public members of the parent 
pointer. 
Again this is completely based on the script engine.  You seem very hung up 
on this dcop thing,  it really is not that radical of a jump.  We are just 
moving a dcop script from the external of an application to be controlled by 
the application itself.  I guess I fail to see an example where the 

> > If you think along the lines of how ScriptFoo in GIMP works or how they
> > python extensions work in XCircut, you will see how this becomes very
> > useful.
>
> ScriptFu scripts in Gimp has access to Gimp's internals.  Your script API
> gives no such access to applications that I can find.
>
> I think a generic system to allow language-independent scripting would be
> nice.  There just needs to be a way for the application to export a list
> of function calls back to the script, so that the script can actually *do*
> something that ordinary DCOP-based scripting cannot.

This is why the idea of a script interface was used.  I am not locking users 
into using dcop.  Using something like python you can access the *parent 
pointer to access the internals of the application via python.  Now the only 
issue with that is someone would have to provide python bindings for the 
classes they wish to access.  If you stick to stock QT/KDE classes then it is 
very trivial.

Please understand that interfaces are not the implementation.  They are a 
generic method so that we can define other script engines to run a certain 
way.  Then applications can genericly access these script engines. 

I hope this makes more sense to you.

For further details on how object twins work take a look at the python 
examples. spacificly demo.c.  For more examples on how interfaces operate 
take a look at KTextEdit and KRegExpEdit.   The real danger here is that 
people tend to think too small and they miss the entire idea behind this.  
This is meant to be the foundation for lightweight extending and automating 
of KDE applications.

- -ian reinhart geiser

- -- 
:-- Ian Reinhart Geiser --:
GPG Key: D6A6 7E16 13A9 B5A7 9E18 D1A7 3F2E B64D 19BC 76F8
===========================================================
We are experiencing system trouble -- do not adjust your terminal.
===========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE78Fk5Py62TRm8dvgRAtqcAKDfhHCL/kjkPc/qmQ+LdrvR2Zo2iACaAkAl
oEy6bgO+O/lFvoq77q0aoNg=
=1vnU
-----END PGP SIGNATURE-----

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