From kde-core-devel Mon Nov 12 23:20:25 2001 From: ian reinhart geiser Date: Mon, 12 Nov 2001 23:20:25 +0000 To: kde-core-devel Subject: Re: [RFC] Unified Application Scripting Interface X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100560717604016 -----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-----