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

List:       kde-devel
Subject:    Re: Scripting Language for IPC
From:       Ashley Winters <jql () accessone ! com>
Date:       1998-03-05 23:56:38
[Download RAW message or body]


On Sat, 28 Feb 1998, Mirko Klemm wrote:

> Does anyone know REXX (OS/2 or Amiga) or AppleScript?
> 
> Applications can be very powerful, but they won't ever be perfect for
> the needs of advanced users.
> No one ever has managed to make an application perfectly suitable for
> any purpose, instead applications are getting bulky, more features are
> added at every new release and the user just gets confused with all the
> features that he/she doesn't really need.

Indeed. I'm often annoyed by the wasteful use of resources forced by
duplication and special-case programming.

> The solution to this could be a scripting system similar to REXX.
> Applications are obliged to put up an IPC port that other applications
> and scripts can send commands to.  There should be a basic set of
> commands that has to be understood by every KDE application, such as
> minimize, restore, maximize, trigger menu items, stick, unstick, close

Umm... if you have direct access to the objects, you don't need an
interface. You could use the existing methods.

> ....
> Additionally, applications could allow for inserting new menu items,
> trigger special functions, present data to the script or accept data
> from it, and so on. With this, an e-mail program could for example be
> enhanced by PGP functionality even if this is not explicitly
> implemented. If the e-mail program supported commands for presenting a
> special mail to a script (e.g. return the filename...), advanced
> filtering options could be implemented. Applications could be linked
> together to a powerful System without having to use large and bulky
> killer executables.

This is what requires the complex system. Pulling the strings of another
program is simple. Figuring out which program to fiddle with, and how to
do that, is difficult.

> Things like Netscape Communicator are completely obsolete with IPC
> Scripts. If You received a HTML-email with Your ordinary e-mail client,
> You could automatically launch a Browser to view it, if the message was
> in RTF-Format, You could bring up a word processor or other viewer for
> this file format.

Ain't mime great?

> Graphics Programs could automatically generate graphics from raw data
> received from a different application, such as a spreadsheet. Word
> processors could be automatized to generate e-mail, letters, faxes or
> whatever from data obtained from a web robot or something similar.
> And all of this can be done transparently to the user.
> 
> Implementation of this will of course affect all present kde
> applications, including kwm, kdm, kfm ...
> You could use Perl for this purpose. A C/C++ shared library can provide
> the functionality for the IPC system such as putting up the port,
> waiting for messages and parsing the commands. Applications could see
> the issuing of a command to its port like a menu, widget or other input
> message. The basic features (like minimize, maximize and so on) could be
> provided by the window manager, so that the application programmers
> won't have to care about this.
> 
> In perl, there could be a perl library that maintains a list of all
> available ports (i.e. running kde applications) from which a script can
> obtain a special port by its name, which has to be documented with the
> application. The valid commands for this application will also have to
> be documented. You could then use that port as an object and call the
> valid commands and data structures as its members.

Umm... that's not too hard. Just pass the name of the function to the Perl
script. Hell, send entire commands. Setup a special QSocketNotifier which
connects to other applications, and when a message is received, eval it.

You will even be able to have another program click on Hello World. :)

$hello_world_app->automate("hitButton \$hello new QPoint($x, $y)");

That's allowable today with PerlQt, although PerlQt-2 will have KDE as
well. If you interface a class to Perl, all its functions become strings.
You can verify that a function-call is valid and secure by defining a
secure interface to it. hitButton() is okay, the destructor is not.
$hello is okay, $qApp is not. These things are all simple. Exporting an
interface through a socket is simple when all your functions can be called
straight from their name.

Actually, that method is clunky and insecure. You could do even one
better.

$hello_world_button_in_another_app->hitButton(new QPoint($x, $y))

The $hello_world_button_in_another_app would be a wrapper object. They're
simple to create in Perl. It would capture all method-calls and transmit
the function-name along with a serialized QPoint for an argument. Hell,
this is starting to sound like CORBA, but insanely simple. I could do it.
And in fact, I'm inspired to incorporate it into PerlQt-2.

> This system will also be quite easy to understand even for unexperienced
> users.
> 
> IMHO, straight use of this feature will be a great improvement, because
> You are not forced to write huge applications that fit any purpose nor
> provide thousands of perl libraries. Applications themselves will act as
> libraries, and user interaction is always possible.

Yes...

> I'm quite new to kde, but I'd like to do some programming on it and
> maybe I'll get something like the above to work. However, there has to
> be an addition to the style guide if this really should have some
> perspective for the future. And first, I need some information about
> application programming for kde itself. Where can I get this?  Any
> programmers interested in this?

Bah. Style-guides are pathetic. When you move into a scripting-language
like Perl, you can change the rules any way you want. You can define an
absolute paradigm, and it can be met. Even if your KDE class is totally
fucked up, like many of them are.

Whether you like it or not, this will probably end up in PerlQt-2 in one
crippled form or another. PerlQt-2 is due in about a month. Sweet dreams.
:)

Ashley Winters

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