Feasibility and Approach for Opening GDSII Files in KLayout via Plugin

simransingh14

Hi Team,

We have a requirement where a GDSII file is stored in our application, and the file needs to be opened in KLayout directly.

Our approach is to develop a KLayout plugin that will:

1. Authenticate and create a session with the application via REST APIs.

2. Download the GDSII file locally.

3. Programmatically load the file into KLayout.

Please let us know:

1. If this use case is supported via KLayout plugins.

2. Any recommended guidelines or steps for implementing this integration.

Thanks,
Simran

Matthias

Hi Simran,

I think you need to be more specific. What is the requirement UI-wise and what are the details?

Basically, KLayout can download from HTTP(S), but authentication supports Basic only, is per-session and requires the user to enter a password into a form.

You can do the download approach you mentioned by using third-party clients such as curl. You do not necessarily need to download as KLayout supports pseudo-paths with the "pipe" scheme:

pipe: curl https://www.klayout.org/klayout-pypi/samples/basic.gds

With curl, you can many more authentication options. If you REST API supports token-based authentication, you can include the token in the curl call using additional header fields for example.

Also, KLayout includes a binding to Qt's QNetwork module. This gives you a lot of flexibility, but it's kind of low-level and implementation of the authentication process may be tedious.

Matthias

simransingh14

Hi @Matthias ,

Thanks for your response. Let me clarify the use case in more detail, especially from a UI and workflow perspective.

The starting point is an XML file available on the local system. This XML file contains an identifier (or metadata) that references a GDSII file stored in our application backend.

What we would like to achieve using KLayout is the following flow:

1. The user opens the XML file using “Open with KLayout” from the local system.

2. When KLayout starts, a custom UI (dialog) is shown that asks for:

• Application URL
• Username
• Password
  along with a Login button.

3. On clicking the Login button, KLayout establishes a session with our application via REST APIs.

4. After successful authentication, the plugin parses the opened XML file, extracts the GDS reference ID, and searches for it in the application.

5. The corresponding GDSII file is then retrieved and opened in KLayout (via a local temporary file download).

Could you please confirm if this overall approach aligns well with KLayout’s plugin capabilities, and if there are any recommended steps or best practices we should follow for implementing this workflow?

Thanks,
Simran

sekigawa

Hi Simran,

Thank you for raising this interesting topic. It prompted me to experiment with an alternative approach outside of a KLayout plugin.

Rather than embedding authentication and REST handling inside KLayout, I tried a small external launcher (built with PySide6) that reads an XML file containing a GDS reference ID, communicates with a REST backend, downloads the corresponding GDSII (and LYP) files, and then launches KLayout explicitly from the command line.

In this setup, KLayout is kept as a pure viewer/editor without plugins or internal API dependencies, which can simplify testing and reduce long-term maintenance concerns.

I have attached the full prototype code along with a detailed ReadMe.md describing the architecture, design rationale, and test environment.
Please refer to that document for the complete context before diving into the code itself.

For reference, this experiment was carried out on an M4 Mac mini running macOS Tahoe 26.2, using Python 3.13 from MacPorts.

Personally, this was also a nice opportunity for me to deepen my understanding of REST-based workflows, so thank you for initiating the discussion. It may be useful to consider this kind of separation-of-responsibilities approach alongside a plugin-based solution, depending on project constraints.

Best regards,
Kazzz-S

---

---

In the local server & client environment...

simransingh14

Hi @sekigawa

Thank you for sharing the external launcher prototype and the detailed explanation. I appreciate the time and effort you put into exploring this alternative and documenting the design choices.

While the separation-of-responsibilities approach is interesting, for our project we are more inclined towards a plugin-based solution within KLayout, mainly to keep the entire workflow (authentication, lookup, and GDS loading) seamless inside KLayout and avoid an additional external tool.

With that in mind, I wanted to specifically ask for guidance on initiating this use case using KLayout plugins:

• Is it feasible to hook into KLayout startup or file-open events when an XML file is opened?
• Would a Python macro/plugin be the recommended place to trigger the login dialog and REST-based retrieval?
• Are there any best practices or known limitations around networking, dialogs, or temporary file handling inside plugins?

Any high-level guidance on how you would structure such a plugin would be very helpful for us to move forward.

Thanks again for the insightful discussion.

Best regards,
Simran

Matthias

Hi @sekigawa,

thanks for this impressive survey

@simransingh14: regarding the plugin-based approach: it is not possible to explicitly capture the "File/Open" event. "Plugins" are scripts that make use of a special API to hook into KLayout's layout view API and allow creating new layout editing or measurement tools.

It may be possible to modify the behavior of the "File/Open" menu button using the Qt objects involved, but I'd not recommend that as the details may depend on Qt versions and may be subject to change without notice.

But you can:

• Create a new menu entry in the File menu (e.g. a new entry "File/Open XML" below "File/Open") and bind it to a macro (a script written in Ruby or Python). This script can utilize the Qt API provided by KLayout to create custom dialog asking for the details and perform all the necessary operations. To deploy such a macro, make sure your users have them installed in KLayout's home folder (see below).
• Run a script on startup by using the command line's "-rm" option like klayout -rm yourscript.py.
• Install a script with the "autorun" option set, so it is automatically executed when you run KLayout. Such scripts can be installed in the "macros" folder of KLayout's home path (i.e. c:\users\youraccount\KLayout on Windows or ~/.klayout on Linux).

To configure a macro for autorun or menu binding, use these options:

There are some concerns however:

• The Qt API is similar, but not exactly identical to pyqt5, if you are using Python, and documentation is sparse. You will need to get familiar with programming Qt in KLayout. There are a number of examples available to help you get started. Here is a simple dialog example in Ruby: https://www.klayout.de/examples/qtdialog.html
• If you plan to deploy your application on Windows and want to use the standard KLayout distribution, your choice of Python or Ruby modules is limited. KLayout comes with a number of important modules preinstalled (such as pandas or scipy/numpy), but that's it. Adding new modules is cumbersome as KLayout does not share the system Python installation. This is a choice made to avoid a maintenance nightmare. Things are far easier on Linux or MacOS, where KLayout shares the system installation and you can use the distribution's package manager or Anaconda/HomeBrew (on MacOS) to install new Python modules. On Windows, some attempts have been made to hook KLayout into Anaconda, but with little success.
• Authentication may be a pain to implement. Basic authentication with HTTPS (to avoid unencrypted transmission of the password over the network) is simple. If your server requires more advanced authentication like OAuth, there is no support within the framework of the Qt API shipped with KLayout and I doubt you will find much support within the Python modules that come with the Windows binaries.

There are no known limitations regarding temporary files. You can use Python's "tempfile" for example to create a temporary file. If your files are not too big and fit into memory, you can even use Layout#read_bytes to read directly from a binary string or QByteArray object and avoid the temporary file.

Kind regards,

Matthias