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

List:       kde-devel
Subject:    Re: Scripting in KDE
From:       Simon Edwards <simon () simonzone ! com>
Date:       2001-01-08 16:41:45
[Download RAW message or body]

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


Hi all,

On Sunday 07 January 2001 07:33, Pavel Troller wrote:

> Let me express my opinion about a good language: As a former Amiga fan, I
> remember the Rexx language. 
> ....
> Every better Amiga app had an ARexx interface.

Every better Amiga app was 'better' because of the fact that it had an ARexx 
interface IMHO.  The Amiga users expected and demanded that thier apps 
supported ARexx.

>   I wonder if there is a possibility to implement Rexx here - I saw some
> publicly available sources on the net but they were useless because there
> is no Rexx interface on Unix apps available. However, KDE has dcop and it
> offers de facto the same functionality. Rexx's main goal would be to use
> dcop to fullfill its integration and communication features.

>   Any ideas about that ?

[This is going to be long. sorry. I just hope I don't repeat too much of what 
other people have said.]

As a former Amiga fan and programmer myself I know where you are coming from. 
The most painful thing about leaving the Amiga platform was losing the 
ability to easily script almost every application I had, and being able to 
easily run scripts from inside my favourite applications. I haven't seen an 
OS yet that has that level of scriptability and ease of use. But KDE is close 
to achieving this, frustratingly close.

Ok, here is what I want to see, from a user point of view. I want:

1. ability to script every aspect of my applications. If an action is 
possible directly through the GUI, it should also be possible through a 
script. (This includes things like selecting/deselecting text, clipboard use 
etc).

2. well documented, stable and complete Application Scripting Interfaces. 
(for example, the the KWrite DCOP interface needs to be documented properly 
with script programmers in mind. Stable, the interface should not change 
between releases, backwards compatability. Complete - all actions that the 
user can do via the GUI should be possilbe via scripting).

3. Simple and natural. Complexities like serialising data and worrying about 
type conversions should be automatically be handled for the script 
programmer. i.e. calling a DCOP function should be as simple and natural as 
calling any other function/method in whatever scripting language I'm using.

4. My choice of scripting language. Perl, Python, PHP, Prolog, Pike, Pascal, 
Postscript, whatever I want.

5. Integration of application scripting directly into the application itself. 
It should be possible to run and maybe edit scripts without having to leave 
the application itself (i.e. to go to a shell). Possibly via a standard 
'Scripting' menu (like the 'Settings' and 'Help' menus). Also, scripts 
started from within an application should also have easy access to the 
application that called them. (i.e. the DCOP AppId of the calling app should 
be accessable to the script).

6. Customisation. I should be able to add my scripts directly into the menus, 
keyboard shortcuts, toolbars etc of my applications. For example I should be 
able to write a "To Lowercase" script for KWrite that I can add to the 'Edit' 
menu. It should act just like a normal first class application command.

For extra credit points....

7. Macro recording. (More of a wishlist item). Should be able to have the 
application record my command via the GUI and output a script to recreate 
those commands, or atleast give me the beginning of a script that I can 
modify.

Still reading? good. I want to expand with some more concrete technical 
speculation on how to do this.

The best part about all of this is that KDE already has all the technology 
and code needed to quite easily make this reality. The hardest part is 
getting everyone to realise how important and powerful this is. DCOP and 
scripting is now available for developers, but it needs to reach the (power) 
users.

Referring to the points above:

1. "Script every app". - DCOP is here and works well. Just a matter of people 
adding more featureful DCOP interfaces to thier apps.

2. "Well documented, stable script interfaces". - Application manuals need to 
actually document the DCOP interface that they expose. The documentation 
should not be aimed at developers, but power users who wish to use it for 
scripting. (DCOP methods that are not stable and intended for scripting user 
use, should be marked as such in the manual). This is more a matter of 
getting people to think out thier DCOP interfaces and write documentation 
(ouch!).

3. "Simple and natural". - DCOP IDL and dcopidl2cpp already exist to make 
calling DCOP methods via C++ just like calling any normal method. This 
concept needs to be extended to other scripting languages. dcopidl2perl, 
dcopidl2python need to be written. Perhaps application *.kidl files should be 
installed along with the application and stubs for scripting languages be 
generated on the user machine. Hence removing the burden for application 
developers to distribute stubs for every language under the sun.

4. "My choice of scripting language". I think everyone agrees that this is 
important and trying to declare a single scripting language (like Rexx) for 
everyone to use is just not going to work. But having said that I do think 
there is great virtue in KDE deciding on at least one language being agreed 
on for use in sample scripts, scripts bundled with apps, documentation etc. 
My choice being: Javascript, for the following reasons:

* KDE already has a Javascript interpreter. People could install KDE and find 
that all the supplied scripts work without any external baggage/dependances 
like Perl or Python.

* It's everywhere. Thanks to the web. I'm guessing that there are more people 
who have some Javascript knowledge/skills than all the Perl and Python people 
put together. People who have done some web page scripting can come over to 
KDE and find that thier skills can be used here. Not to mention the amount of 
info on the web about Javascript programming.

* For documentation and sample code it's quite easy to read for most 
programmers, espically unix types who grew up on C/C++. I can't say the same 
about Perl. i.e. Javascript shouldn't alienate/upset too many unix gurus.

* Unlike other existing scripting languages/interpretters, the existing 
Javascript interpretter can be wrapped in a KDE program which can communicate 
via DCOP directly without having to go through the kxmlrpcd daemon. The 
advantage is that it's now possible to write a Javascript script that 
registers with the DCOP server and exposes methods *itself* via DCOP just 
like any other normal KDE app. I don't think this is possible via kxmlrpcd. 
I'm guessing that this would make it possible for a script to do 'refective' 
type stuff like kdcop, like examine registered programs for interfaces etc.

* Having control over the interpreter means that suitable security features 
can be added. i.e. sandboxing, and being able to execute scripts with limited 
privledges, being able to stop scripts from doing certain things. (Much like 
the Rebol interpretter).

* It's not BASIC. ;-)

5. "Integration of application scripting" - I would like to see every KDE 
program get a 'Scripting' menu where I can run scripts, edit them etc. Any 
scripts I run from here should know what app called them. i.e. in Javascript 
for example, a script should have access to a 'host' object that they can 
execute methods from directly. My "To lowercase" script for KWrite should be 
as simple as:

host.overwriteText(host.getMarked().toLower());

6. "Customisation". It shouldn't be too difficult to modify the GUI XML stuff 
to make it possible to add scripts to menus etc.

7. "Macro recording". I haven't got any big ideas on how to easily implement 
this one... suggestions?

What do guys think? Am I speaking complete bullshit, just tell me if I am.

mmm... I'm tempted to have a play with the KJS stuff now...

- - -- 
Simon Edwards
simon@simonzone.com
http://www.simonzone.com/
Nijmegen, The Netherlands
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjpZ7ckACgkQuIuDmTrvhSaKygCdHY4X3cq68hTqNGpaJbN2Ulb+
FREAn1phyLnZJfdPM43q2eyIIH1vCkHJ
=H+M9
-----END PGP SIGNATURE-----
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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