kexi project
Rapid Database Application Development
"Microsoft Access for Linux"

Home Download FAQ Support Features Handbook Screenshots Screencasts Compile Kexi Development Authors Contact License Sponsorship Translate This Site

wiki navigation:

Front Page
[info] [diff] [login]
[recent changes]
[most popular]
You can donate
to Kexi Project:
Via PayPal

Spread the word about Kexi!
Get Kexi Now!

Built on the KDE technology

Member of the Calligra Suite

No Software Patents!


Kexi Script Editor

Table of Contents
   Errors Handling
   Flattening the user-level API


The Kexi scripting editor is used to be able to edit scripting code and is located in kexi/plugins/scripting/*. Internaly KexiScriptEditor inherits KexiEditor located in kexi/widgets/kexieditor.*, a wrapper around KTextEditor. The KexiScriptEditor itself doesn't depend on Kross, the Kexi scripting framework, directly. We use KexiScripting, located at core/kexiscripting.*, as abstraction layer. If Kexi got compiled with --enable-kexi-scripting the Kross scripting framework is used else KexiScripting provides a dummy-skeleton to be still able to edit/save the scripting code. So, we are able to use the functionality the editor provides independend of the used (compiled in) scripting framework.

^ toc


To name just some ideas a script editor could be aware of;

  • create skeletons for new classes/functions
  • debugging, breakpoints
  • Source-formatter
  • word completion
  • create documentation out of the code (use kexi-reporter?)
  • Some of the goodies KDevelop provides could be maybe (re-)used
^ toc

Errors Handling

Kross provides stdin and stdout events which are catched and displayed at the textview. That way scripting code is able to print some visibled feedback. In python or in the Kross scripting framework thrown exceptions are catched and displayed as stderr-message. Execution got aborted and a signal emitted which indicates the linenumber in the scripting code where the exception got thrown.

^ toc

Flattening the user-level API

 jstaniek, dec 2005
 status: proposal
 note: this could be moved to other document...

Flattening the user-level API means simplicity for average use case. Of course, there still could be the original KexiDB API exposed. Look at the KexiDB connectivity example above, then at the following flattened version:

  # no import directive here: everything is imported by default
  connection = Connection("SQLite3", "/home/foo/myproject.kexi")
  if not connection.connect():
      # Joe user wil luse message boxes and return here rather, no exceptions
      messagebox("Failed to connect")
  # no conn.useDatabase(...) is required here:
  # SQLite driver uses the db at the connect time
  # - default value used value here
  # - unlike in KexiDB the statement here
  # - is parsed against KEXISQL grammar
  print connection.querySingleString("SELECT name FROM table1")

Kexi - "MS Access for Linux" ... and Windows
© Kexi Team
This content is available under GFDL
Last edited: January 10, 2006 by js, visited 0 times.