Kexi/Plugins/Scripts

From KDE Community Wiki
< Kexi‎ | Plugins
Revision as of 19:15, 26 August 2023 by Jstaniek (talk | contribs)

Note

May 2023: This document needs deep updates because of the changed direction to Python. See https://invent.kde.org/office/kexi/-/issues/34

Note

Two aspects of scripting:
  1. user-defined "modules"
  2. extensions that add in-app features to KEXI, what is an alternative to binary C++ extensions


Notes

  • A new stable, non-experimental scripting shall appear in the Qt5-based Kexi.
  • Qt Script possibly not the best tech for Kexi scripting (kexi-devel) QtQml / QJSEngine is the only proposed replacement so far, by the Qt community. We have not yet analyzed if it's as complete tool set as QtScript for our needs.
  • Initial idea: Target implementation shall use Qt5's QtScript since it uses the more efficient V8 engine which will not be used in Qt4. Qt4's QtScript uses a fork JavaScriptCore and exposes internal APIs of JavaScriptCore.
  • But: In Qt5 QtScript is a DONE module without (as of 2012) plans for porting to V8. It is too costly to standardize on Qt4 scripting and then porting to Qt5 (with changed API). See also Summary of QtScript problems in Qt5.

Wishes

Create some security/signing for kross scripts, so that there is some protection when doing:

import("qt.core");

Documentation

Q: Is there documentation of objects and operations available for scripting, e.g. using python or ruby?

User asked:

> Is there a list of calls that can be made to Kexi to do something
> from a Python script?  For example:  Let's say from a form menu in Kexi
> it calls a Python script, that script then calls one form and based on
> the input from that form either calls another form or does some table
> action.  Now, what calls to Kexi are available to do this?

Answer by j.staniek

List of objects and operations is not documented separately of the source code, which uses the Kross bindings helpers that expose operations to python. The author is Sebastian Sauer (mail at dipe.org)

I am sorry but for now one needs to get the source code and look closer. There's no excuse for no documentation, other plans for delivering much more extensive set of scriptable objects. This means we keep the right to completely remove the current object model, with possibility (in theory) of breaking backward compatibility (e.g. for security reasons).

There are two areas:

  • kexi window and operations on it; this is exposed in code kexi/plugins/scripting/kexiscripting
  • kexidb objects and operations on them, i.e. database-access-related features; this is exposed in code kexi/plugins/scripting/kexidb

To learn what objects are, look at, let's look at kexi/plugins/scripting/kexiscripting/kexiscriptadaptor.h, which is: "Adaptor class that provides Kexi specific functionality to the scripting world." as has been described in the file.

In line 45, there is setObjectName("Kexi"). This means the object to use in scripting is called "Kexi".

Then after the line 47, "public Q_SLOTS:" we have list of operations (slots, i.e. C++ methods) like windowWidget, viewWidget, actions, and so on. i.e. calling Kexi.windowWidget() is possible.

All is documented there in the code. To use objects in Python, one needs to use bindings to Qt, since objects typically inherit functionality from Qt rather being written from scratch. The last operation exposed in this file is 'viewIsDirty'.

Object Model