[Kexi-devel] Qt Script possibly not the best tech for Kexi scripting

[Jaroslaw Staniek]

Hi,
As you know a semi-official conclusion is that we can afford
development of scripting for at most one scripting language, and for
some reasons like popularity and security it's JavaScript. [0]

I am forwarding the thread from the development at qt-project.org list. [1]

(CC'd to calligra-devel since potentially, scripting is something
useful for other Calligra apps in some distant future)

It says that Qt Script is going to be deprecated in Qt 5.5, and most
likely removed them from binary packages in Qt 5.6. By the time we're
done with porting to Qt5 5.5 would be ready (May 2015).

The concern is that Qt Script isn't wery actively developed and
possibly not a safe technology for our scripting needs in Kexi.
Its engine's code has not been actively updated, and JavaScript has
since evolved as a language. Previously QtScript status was Done, what
already meant a "no new features" policy.


== What's a replacement? ==

As you know KROSS isn't in KF5/Qt5, so it's not an option to re-add
it. Moreover the idea of KROSS was a general one-size-fits-all support
for multiple programming languages, without find-grained support for
specifics of given language. For example you'd like to use your
language's list structure instead a wrapped QList (just an example).

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. Feel free to look closer, it would be
appreciated.

== Problems? ==

Two particular things I raised questions for in case of the above proposal, are:
1. Support for encapsulating non-QObject objects (light, simple
structures) for use in javascript code
2. Support for (visual) debugging environment for users

The answer I got (in the same thread [1]):
Re 1. There are some lighter solution, possible related to the  new
Qt's Gadget construct
Re 2. Solution would come as a result of contributions that are in
progress, obviously more projects need a debugger component.

Extra bonus is that we can develop JSON/QML (not necessarily Qt Quick)
based "micro-formats" that are can be easily accessible/blended into
JavaScript scripting. Think of conditional formatting for data grids
or Assistant GUI APIs for end users.

== Your turn ==

Feel free to post your analysis or concerns regarding scripting here.

We're about to enter the porting to Qt5/KF5 stage. Aspects of
scripting are included in the plan [3]. The minimum is not to break
compatibility with the simple scripting features in Kexi 2 Reports.
We're not going to support compatibility with the experimental
scripting module of Kexi 2 however (the script Kexi objects). They are
experimental after all. We hope to reuse the Kate-based editor of
course.

== Good thing ==

I think it's good that given the plan is pragmatic (e.g. we do not
half-develop features) we've not developed QtScript-based scripting so
far, otherwise we're be rather sad because of lost resources.


[0] https://community.kde.org/Kexi/Plugins/Scripts
[1] https://www.mail-archive.com/development@qt-project.org/msg18866.html
[2] http://doc.qt.io/qt-5/qjsengine.html
[3] https://community.kde.org/Kexi/Porting_to_Qt%26KF_5

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek