Kross - Start of a Unified Scripting Approach

RM <ny_r_marquez@yahoo.com> wrote:
[color=blue]
> This is from the new KOffice Announcement.
>
> http://www.koffice.org/announcements/announce-1.5.php
>
> '''This version of KOffice features a start of a unified scripting
> solution called Kross. Kross provides cross-language support for
> scripting (thus its name) and at present supports Python and Ruby.
>
> Kross is easy to include into programs previously lacking scripting
> abilities, and is included in this version as a technology preview. So
> far, only Krita and Kexi are improved by means of the Kross engine.We
> would also like to point out that the API might change in the future
> and expect Kross to be fully integrated into KOffice version 2.0.'''
>
> Interesting isn't it?[/color]

An absolutely exellent idea. Most of the potential issues are with the
details (that's where the devil is, right?-)... can't check it out right
now (vacationing in the Grand Canyon, very occasional net access), but
I plan to do so when I'm back home next week!


Alex

So, this would be like .Net or Mono, but for KOffice? Kind of like
AppleScript then?

Sorry, just starting to learn about some of this stuff (CLI, CLR, CIL,
etc...) and am interested in understanding better.

Jerry wrote:[color=blue]
> Kind of like AppleScript then?[/color]

Same fundamental goal, i.e. language-independent application scripting.
They seem to have a similar sort of approach to decoupling a scripting
language from its host application (Kross::API::ScriptManager vs. the
Open Scripting Architecture API) but a very different approach to the
intercommunication part.

Kross appears to create native language wrappers for the application's
public (C++) classes; nothing fancy, but pretty straightforward. Mac
apps use serialised procedure calls containing first-class queries and
other arguments to describe the action to perform and the application
object(s) to use in that action. A query engine in the application
framework (e.g. Cocoa Scripting) locates the actual object(s) and
applies the appropriate action to them. Much higher level of
abstraction and a lot more sophisticated, though it can be a bit tricky
for application developers to implement (for the same reason).

Plus I get the impression that Kross doesn't do interprocess yet
although it's on the cards, presumably using something like proxy
objects and dbus to provide the bridge. With Macs you only need OSA for
intraprocess communication; the Apple Event Manager, which handles the
messaging part, can pass messages between processes as well.
[color=blue]
> Sorry, just starting to learn about some of this stuff (CLI, CLR, CIL,
> etc...) and am interested in understanding better.[/color]

As far as how the Mac does it, here's an old but good paper on the
basic principles involved if you want to know more:

http://www.cs.utexas.edu/users/wcoo...pleScript95.pdf

I couldn't find a nice, simple overview of the Kross system. You should
be able to form a rough impression from reading through the following
links, although some better examples of calling Kexi from scripts would
help:

http://wiki.kde.org/tiki-index.php?page=kross
http://www.kexi-project.org/wiki/wi...x.php?Scripting
http://www.kexi-project.org/docs/cv...spaceKross.html

HTH

Awesome, thanks for the explaination. It was very informative.

Cool. I hope I got the bits about Kross right; I only just found out
about it from seeing your post so haven't been long learning about it
(I'm a sucker for this stuff). Hopefully some nice expert can correct
anything I may've got wrong. :)

BTW, if you're curious about how Python hooks into this stuff on the
Mac, check out the appscript bridge
<http://freespace.virgin.net/hamish.sanderson/appscript.html>
(shameless self-link) and PythonOSA language component
<http://homepage.mac.com/philip_aker/osa/osa.html>.

Appscript uses a lot of syntactic sugar to put a nice easy-to-use
syntax (which looks like OO but isn't) on top of the underlying
RPC+query mechanism; the underlying aem package gives a better idea of
how things actually work. If you don't have a Mac to play with, you
might still find the appscript and aem documentation in the source
distribution
<http://freespace.virgin.net/hamish.sanderson/appscript_source.html>
worth reading.

The PythonOSA component provides basic OSA support
(compile/load/store/execute), allowing you to edit and run Python
scripts in Script Editor and other OSA editors and trigger them from
OSA-based application script menus and so on. There is a more advanced
but unfinished MacPythonOSA component on my site that can do message
sending and receiving as well, but it needs a bit of poking to get it
built and working at all. And I've also got an unfinished osawrapper
module that allows you to load and use OSA languages in Python.

HTH

RM 写道:[color=blue]
> This is from the new KOffice Announcement.
>
> http://www.koffice.org/announcements/announce-1.5.php
>
> '''This version of KOffice features a start of a unified scripting
> solution called Kross. Kross provides cross-language support for
> scripting (thus its name) and at present supports Python and Ruby.
>
> Kross is easy to include into programs previously lacking scripting
> abilities, and is included in this version as a technology preview. So
> far, only Krita and Kexi are improved by means of the Kross engine.We
> would also like to point out that the API might change in the future
> and expect Kross to be fully integrated into KOffice version 2.0.'''
>
> Interesting isn't it?
>
>[/color]
Just like the .Net vision , Good idea !