klayout Python Module Technical

C++ infrastructure

KLayout's infrastructure is built on a call abstraction which enables exchangeable and interoperable language front-ends. This layer is called "GSI" (generic scripting interface).

Every class that wants to be exposed registers itself in a configuration space with a class descriptor object. The GSI framework manages these descriptors and supplies the algorithms for the implementation. It provides methods to marshal and unmarshal the arguments and to transfer control between the script client and the implementation code.

The Python client-side implementation resides inside the "pya" C++ namespace. It provides the client side for the Python integration. "pya" implements the Python module, the Python classes and the frontend side of the GSI framework (Python to GSI parameter and control transfer). Furthermore, "pya" also implements the interpreter wrapper - a standardized interface for all script languages supported.

So technically, the task of providing a standalone Ruby module is to isolate the Python module provisioning code.

Qt binding

The Qt binding is based on the GSI framework and supplies class descriptors for many Qt classes and enums. Apart from that, the Qt binding is not quite special.

Challenges

• Modularization: the current API supplied by the "pya" Python module is a huge one and pulls in manifold dependencies. To keep the API lean, splitting into distinct modules is required.
• Late registration: the GSI class declarator system is based on static load-time initialization. A Python module is loaded when it is required, so initialization may happen later and in parts (if multiple modules are given)
• Interoperability: To allow interfacing KLayout's objects with other Python extensions, implementation of functionality on C/C++ level is required. For example, the transfer of Polygon data into a different object is far more efficient if specialized C code supplies. For these "bridge" applications, methods that translate a Python object to a KLayout object and vice versa are required.
• PyQt interoperability: As KLayout supplies it's own Qt binding, interoperability between PyQt and KLayout's is not given per se.
• API fitness: specifically the UI classes are not designed as standalone components currently. Some API enhancements are required.
• Qt binding fitness: the Qt binding library was designed for providing UI design abilities to KLayout extensions. Exporting the UI components means a use case shift for the Qt bindings: instead of providing "bridge" code, the Qt binding will become the basis for UI code integrating KLayout's UI components. This puts more emphasis on the usability of this API (documentation, automated Qt API extraction for rich version support etc.)

Module structure

The KLayout master module is "klayout". The KLayout core itself comes in four modules

• tl: the basic toolbox (boxed types, introspection, utilities, expression parser ...)
• db: the core algorithms of KLayout (geometrical primitives, layout, cells, regions ...)
• lay: the application objects (user interface objects ...)
• rdb: the report database objects

With Qt bindings enabled, some Qt modules add to this:

• QtCore: classes from QtCore
• QtGui: classes from QtGui
• etc. ...