I'm using several handles for PCells and it's getting a bit bothersome to keep doing a second click to apply transformations.
I understand the philosophy behind why to do it this way (I read it somewhere in the docs a while ago), like being useful to move things around and allow for comfortable pan/zoom.

I saw others asking for the same, so I'd like to propose 2 different solutions which I think either would make everyone happy:

• Config toggle to change behaviour of the "Move" mode
• Smart handling of the event:
  • If the user does a click: down → up, behave like currently
  • If the user does a click: down → drag → up, apply the transformation right away

I think 2nd option would be best for seamless workflow and user practicality. I doubt any user is doing click: down → drag → up → down → up without the intention of applying the transformation on the first up.
A drag threshold or click timer may be added to not consider drag a very small movement of mice and/or "user intention" when clicking fast.

Thanks!

Gerard

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

I have a question about implementing a method for checking the minimum distance between geometries on the same layer.

Recently, I ran a script to check spacing between shapes on a layer using the .space() method, and I wanted to implement a similar algorithm in C++. I couldn't find a description of this algorithm in the repository, so I'm asking for help with its implementation. As far as I know, it uses a sweep-line algorithm and compares edges.

Currently, I'm trying to use an approach that checks distances between cells: first determining if cells are close to each other, then checking distances between geometries inside them (currently using min/max coordinates). The problem arises when working with the GDSII format because I don't know how to properly parse geometries considering transformations (offsets, rotations, mirrors) without excessive copying, which requires a lot of memory.

I tried to build the project in Visual Studio but didn't succeed. I would like to know where in the KLayout source code the implementation of the space() function is located so I can write a similar educational algorithm. I'm interested in how you handle such complex topology hierarchy.

Backtrace:
/usr/lib64/klayout/libklayout_lay.so.0 +0x291ebe lay::enable_signal_handler_gui(bool) [??:?]
/lib64/libpthread.so.0 +0xf630 __restore_rt [sigaction.c:?]

Crash log written to ./klayout_crash.logmake

I am running on CentOS
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.9.2009 (Core)
Release: 7.9.2009
Codename: Core

I have the layermap file for Virtuoso, where defines the map between layer name/purpose and gds number, like showing below:
M1 drawing 15 0 OASISLayerName:M1 # M1

Is here an automatic way to generate .lyp file? I don't care about the color/strippe/style, just want to get layer name instead of gds number.

Thanks.

Lately I've been working with PCells and these are awesome.
I got used to working with them by drag-dropping an instance from the library, double-clicking and tweaking properties from the "Object Properties window".
I have some comments about the workflow that are somewhat annoying, and couldn't figure out an obvious way to circumvent.
I listed them in no special order, in a hopefully easy to digest format:

1. Keep "Editor Options" for created instances

   • When creating a new PCell, a very convenient view "Editor Options-PCell" is available to be used before placing a PCell.
   • Proposal → Keep the view operative when selecting an instance/PCell and allow further tweaking from it.
   • Benefits → Avoids opening "Object Properties" every time a PCell is tweaked || Reserves opening "Objects Properties" for a more involved parameter insertion.
   • Technicalities: It could add overhead to the software, and the "Editor Options" would be updating every time something is selected, and I understand it could be distracting.

2. Object Properties window gets in the way

   • From time to time, while using "Object Properties" I'd like to pan/zoom the Layout so I can see better the resulting PCell.
   • The Layout seems to be unresponsive while "Object Properties" is open, and then the main KLayout window is made active, leaving "Object Properties" window behind.
   • It kills the flow to have to go find the "Object Properties" window buried under the main KLayout every time that happens.
   • Proposal → Make "Object Properties" always-on-top in a KLayout instance
   • Proposal → Allow Layout mouse pan/zoom while "Object Properties" window is present
   • Proposal (not as convinced) → Dynamically change contents of "Object Properties" window if another PCell/instance is selected || If (1.) is done, this shouldn't be as interesting.
   • Technicalities: This would require to open the window in another thread, something I'm not sure easly doable or not. If another "Object Properties" were to be opened, I would automatically close the previous one to avoid confusion.

3. Object Properties with custom positioning of PCell parameters

   • Currently parameters are displayed in a vertical sequence.
   • This is completely fine for the "Editor Options-PCell" view as it has to be narrow
   • But for wider views like extending the "Editor Options" view or in "Object Properties", there's much space unused, and it's a nuance to scroll down the list of parameters.
   • Proposal → Implement system to customize arrangement of parameters, be it HTML/CSS/XML style, table style, Qt injections, etc. Ideally it should be responsive to width changes, but horizontal scrollbar is fine (not so much for Edit Object narrow view, but that's on PCell developer, not KLayout's).

   • It would be also very useful to have some kind of built-in/intended delimeters, setting margins or proper labels to organize the parameters. Currently I'm using a readonly text field:
     

   • Of course sliders, images and other widgets would be much welcome too.

   • Technicalities: It would be a very involved KLayout development

4. Parameter changing callbacks (kind of discussed here)

   • When implementing PCells, sometimes I would find it useful/convenient for them to be able to read and expose data from the current Layout.
   • Proposal → Having a callback button capable of rewritting or updating a list of items in a drop-down list for example would be very useful.
   • Benefits → For this usecase, it would make "typeLayer" much less obscure, as it's exposing data relative to Layout, unavailable to expose otherwise.
   • Technicalities: Could cause infinite loops if used wrong, but I guess that's always a possibility with custom code.

Hopefully this list helps to come up with ideas to improve UX of KLayout.

Thank you very much!

Gerard

I love PCells, but if I ever want to "freeze" or export them by converting them to static, the basic name plus an index is used. I would like to keep the meaningful name defined in display_text to keep the distinction between different instances of the same PCell, not just a number.

Is there a way to do it? (Other than the hacky and inconvenient way of accessing the layout from pya.Application and try to map which is which)

I understand the reasoning for keeping the basic name in order to identify them when reloading libraries. Maybe this is the preferred way of having PCells converted (reason unknown to me), but having an internal PCell flag to the display_text insead seems to me like a very nice addition when executing Convert To Static Cell. I checked dbLayout.cc and it seems feasibe.

Thanks!

Gerard

In CMOS layout design, usually, the only angle allowed are 0, 45 or 90 degrees.
A nice feature to add would be to force an edge angle.
For instance, if an edge has an angle of 1°, it would be nice to select it, check that its angle is 1°, and force it at 0°.
Actually, 45° is usually more to difficult to correct. Once, I also got the very case where 2 edges of 2 different polygons should be parallel (i.e. same angle), and not necessary at multiple of 45°.
The very nice option is to keep it on-grid

Thanks, BRgds,
Laurent

The steps to reproduce are:

1. Be on FreeBSD
2. Open KLayout in Editor mode
3. File → New Layout
4. Tools → Edit Layer Stack
5. Press the + button at the bottom of "Technology Stacks", automatically-named STACK1 appears
6. Press "OK"
7. Tools → Edit Layer Stack again. On Windows, the newly added stack is still there. On FreeBSD, the window is empty again.

Do you have a feeling for what might be going on or suggest a few things that I can try to debug this issue?

I have been poking around src/plugins/tools/net_tracer/lay_plugin/layNetTracerTechComponentEditor.cc but am having trouble understanding where NetTracerTechComponentEditor::commit "commits" the data.

I use the following code to move shapes from a source cell into a target cell. However, since there are numerous cells and shapes involved, this code runs quite slowly. For both the source layout and the target layout, the database unit (dbu) is identical. Is there a faster method to move these shapes? Instead of creating new shapes in the target cell and then clearing the shapes from the source cell, can the shapes be moved directly? This would improve speed and reduce memory usage. Could you please advise on the appropriate function interface to use? Thank you very much

                  db::Cell &source_cell = source_layout.cell(source_cid);
                  db::Cell &target_cell = target_layout.cell(target_cid);

                  for (std::map<unsigned int, unsigned int>::const_iterator lm = layer_mapping.begin (); lm != layer_mapping.end (); ++lm) {
                    target_cell.shapes (lm->second).insert (source_cell.shapes (lm->first));
                     source_cell.shapes (lm->first).clear();
                  }

Is there a way to allow the cursor snapping to the grid while moving the mouse?
It is quite difficult to draw shapes or reading the coordinates at the lower right corner in the GUI.

Many thanks,
Martin

I was able to find one teaserware dwg to dxf demo
that got me from .dwg to R12 .dxf but its eval period
has expired. I had tried dxf format options in that
converter and they didn't open right until I got to
"good ol' R12" at the bottom.

Wondering whether we could get .dwg (to R12 dxf)
conversion "internalized" to klayout? Maybe there is
open source code somewhere that could be pulled
in?

I could stand any hints about using klayout to pull
in dxfs (like from package vendors) and then
exporting to GDSII, like when I have to make bond
figures for my chips. I need to get their cavity
drawings at right scale. Need to keep absolute
dimensions right (microns:microns) despite
whatever the vendor drawing might have been
(lots of the packages I like, still have inches as
drawing units).

I would like to know if the conda distribution is affected by any limitation compared to the windows installer. If not I think that, perhaps, it could facilitate the integration with other open source codes like, in example, FreeCAD or pythonOCC. FreeCAD and pythonOCC are both available from conda reposository: https://anaconda.org/conda-forge/freecad and https://anaconda.org/conda-forge/pythonocc-core.

In the developmemnt of my klayout package layoutDD, pythonOCC could be a lighter replacement of the FreeCAD modules.

I find the way KLayout mixes the colors of geometries in different layers marked as transparent or opaque very good and want to understand how this is done in detail.
As I am not very experienced with the KLayout code base, could anyone point me to the right file on github or give me an idea, what type of color mixing is used?

Regards,
Luis

My layoutDD package makes use of the python modules included in the FreeCAD package (which is composed of several submodules and binary files). The FreeCAD modules are available in MSYS2-ucrt and also in MSYS2-clang (see at https://packages.msys2.org/base/mingw-w64-freecad)

Looking inside "klayout/script/deploy-win-ucrt64", it seems to me that these modules would be automatically included in the klayout distribution if previously installed in your system.
May I ask to add them ? I could add them in my package, but the inclusion in the klayout distribution would assure the alignment with the related python compiler. Another problem is that if all these modules (a large quantity of data) are downloaded during package installation, the process can take a long time.

PS:
Th last release of layoutDD has bee made compatible with mainstream FreeCAD (https://github.com/FreeCAD/FreeCAD) which is the same version available in MSYS2.

t = pya.Trans(45, False, 0, 0) # r90 0,0
t = pya.Trans(45, True, 0, 0)  # m45 0,0

The result is behind # simbol above. However, for CplxTrans class.

t = pya.CplxTrans(1, 45, False, 0, 0) # r45 *1 0,0
t = pya.CplxTrans(1, 45, True, 0, 0) # m22.5 *1 0,0

See, the results are not inconsistent. Is this a bug or something? Maybe we should keep these two conventions consistent?

../../../../src/gsiqt/qt6/QtGui/gsiDeclQAccessibleEvent.cc
../../../../src/gsiqt/qt6/QtXml/gsiDeclQDomNodeList.cc:171:50: error: no member named 'operator!=' in 'QDomNodeList'
171 | ret.write ((bool)((QDomNodeList *)cls)->operator!= (arg1));
| ~~~~~ ^
../../../../src/gsiqt/qt6/QtXml/gsiDeclQDomNodeList.cc:209:50: error: no member named 'operator==' in 'QDomNodeList'
209 | ret.write ((bool)((QDomNodeList *)cls)->operator== (arg1));
| ~~~~~ ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -std=c++17 -fvisibility=hidden -O2 -std=gnu++1z -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk -mmacosx-version-min=14.0 -Wall -Wextra -pedantic -Woverloaded-virtual -Wsynth -Wno-deprecated -Wno-long-long -Wno-strict-aliasing -Wno-deprecated-declarations -fPIC -DHAVE_QTBINDINGS -DHAVE_PYTHON -DHAVE_GIT2 -DHAVE_RUBY -DHAVE_RUBY_VERSION_CODE=30403 -DHAVE_QT -DHAVE_QT_UITOOLS -DHAVE_QT_NETWORK -DHAVE_QT_SQL -DHAVE_QT_SVG -DHAVE_QT_PRINTSUPPORT -DHAVE_QT_MULTIMEDIA -DHAVE_QT_DESIGNER -DHAVE_QT_XML -DKLAYOUT_VERSION=0.30.0 -DKLAYOUT_VERSION_REV=LatestSourcePackage -DKLAYOUT_VERSION_DATE=2025-04-29 -DKLAYOUT_MAJOR_VERSION=0 -DKLAYOUT_MINOR_VERSION=30 -DKLAYOUT_TINY_VERSION=0 -DMAKE_GSI_QTSQL_LIBRARY -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_DESIGNER_LIB -DQT_UIPLUGIN_LIB -DQT_UITOOLS_LIB -DQT_OPENGLWIDGETS_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_WIDGETS_LIB -DQT_OPENGL_LIB -DQT_MULTIMEDIA_LIB -DQT_SVG_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_NETWORK_LIB -DQT_CORE5COMPAT_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I../../../../src/gsiqt/qt6/QtSql -I/Users/lycore_ssw/Downloads/klayout-0.30.0/qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/gsiqt/qt6/QtSql -I../../../../src/tl/tl -I../../../../src/gsi/gsi -I../../../../src/gsiqt/qtbasic -I/opt/homebrew/lib/QtPrintSupport.framework/Headers -I/opt/homebrew/lib/QtDesigner.framework/Headers -I/opt/homebrew/include -I/opt/homebrew/include/QtUiPlugin -I/opt/homebrew/lib/QtUiTools.framework/Headers -I/opt/homebrew/lib/QtOpenGLWidgets.framework/Headers -I/opt/homebrew/lib/QtMultimediaWidgets.framework/Headers -I/opt/homebrew/lib/QtWidgets.framework/Headers -I/opt/homebrew/lib/QtOpenGL.framework/Headers -I/opt/homebrew/lib/QtMultimedia.framework/Headers -I/opt/homebrew/lib/QtSvg.framework/Headers -I/opt/homebrew/lib/QtGui.framework/Headers -I/opt/homebrew/lib/QtXml.framework/Headers -I/opt/homebrew/lib/QtNetwork.framework/Headers -I/opt/homebrew/lib/QtCore5Compat.framework/Headers -I/opt/homebrew/lib/QtSql.framework/Headers -I/opt/homebrew/lib/QtCore.framework/Headers -I/Users/lycore_ssw/Downloads/klayout-0.30.0/qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/gsiqt/qt6/QtSql -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk/System/Library/Frameworks/AGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk/System/Library/Frameworks/AGL.framework/Headers -I/opt/homebrew/include -I/opt/homebrew/share/qt/mkspecs/macx-clang -F/opt/homebrew/lib -o gsiDeclQSqlRecord.o ../../../../src/gsiqt/qt6/QtSql/gsiDeclQSqlRecord.cc
2 errors generated.
make[3]: *** [gsiDeclQDomNodeList.o] Error 1
make[2]: *** [sub-QtXml-make_first] Error 2

make[2]: *** Waiting for unfinished jobs....

ln -s libklayout_QtGui.0.30.0.dylib libklayout_QtGui.dylib
ln -s libklayout_QtGui.0.30.0.dylib libklayout_QtGui.0.dylib
ln -s libklayout_QtGui.0.30.0.dylib libklayout_QtGui.0.30.dylib
rm -f ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.30.0.dylib
mv -f libklayout_QtGui.0.30.0.dylib ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.30.0.dylib
rm -f ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.dylib
rm -f ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.dylib
rm -f ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.30.dylib
mv -f libklayout_QtGui.dylib ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.dylib
mv -f libklayout_QtGui.0.dylib ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.dylib
mv -f libklayout_QtGui.0.30.dylib ../../../../qt6Brew.build.macos-Sequoia-release-Rhb34Phb311/libklayout_QtGui.0.30.dylib
make[1]: *** [sub-qt6-make_first] Error 2

make: *** [sub-gsiqt-make_first] Error 2

can you help me to guess where's the problem lies ?

====================================================
ck_layer = input(130, 0)
output = ck_layer.drc(width < 5.um).output(333,1, "violation")

output.not_interacting(ck_layer).output(100, 0)

======================================================

and I got below error msg

I'm looking for a way to flag places where two edges of adjacent polygons touch on the same layer.

For example, it should highlight the following two polygons near where they touch along x=1:
poly1=[0 0 1 1;0 1 1 0]
poly2=[1 1 2 2;0 1 1 0]

I'm aware of the two similar tests:
1. overlap within the same layer - different shapes from the same layer overlap.
2. gap detection within the same layer - different shapes from the same layer are separated by a distance smaller than x.

My thinking was to use either of these operations for the touching operation:
1. Bias the input layer up by a small amount using layer_input.sized(+x) and check for overlaps.
2. Bias the input layer down by a small amount using layer_input.sized(-x) and check for gaps.

However, these solutions don't work because the sized operation appears to merge the shapes before biasing. This method would also assume that the gap/overlap of that size isn't present elsewhere in the layout.

Do you have any suggestions? Am I on the right track or would you recommend an entirely different path?

Thanks in advance,
Adam

Best regards
Sascha

If this method is not generally applicable, I would be interested to know that what parallelization schemes currently supported by KLayout for polygon operations, such as merging, XOR, AND, OR, and NOT.

Thank you.

Would it be possible to add a Load/Save option (to/from text file) in the Layer Stack pop-up window "Edit Technology"? This way you can quickly trace nets in the Default technology while switching between different designs without retyping the layer stack each time or setting up a technology for each of them.

Cheers,

Tomas

Is there a manual on how to run tests? As far as I understand, KLayout officially supports all three major OSes, so I presume that I would have to run a copy of the KLayout reference Linux in a docker (based on python's "manylinux" quasi-distro?), as well as VMs for Windows and MacOS?

As far as I can see, the files are quite scattered over the source directory, with Jenkins, travis, azure, and maybe more ways to run the testsuite, so I would like to ask if there is a "safe choice" way of running tests locally, without signing up for all those "cloud providers" just to run the tests.

Something like "destroy 1 container and two VMs, sping new instances, built, test, print results" in a single script.

So I started by pushing a commit with tag v4.8.0. I understood that KLayout has relatively new feature to pull packages using GIT rather SVN, so I tested succesfully using KLAYOUT_SALT_MINE env var that the package gets pulled correctly if I specify <url> tag in grain.xml as git+https://github.com/iqm-finland/KQCircuits.git/tags/v4.8.0/klayout_package. Then I notice in the SALT package update form that the recommended url form is git+https://github.com/iqm-finland/KQCircuits.git+klayout_package[v4.8.0]. Changing in the form the Package URL value to either url format causes the package defintion link to redirect to the error page with attached message:

So I thought I would power through and submit the form anyway. I received confirmation email, updated KQCircuits is now listed in https://sami.klayout.org/index, but the package link for it doesn't work, and in KLayout app it is not listed.

I thought it fails because git+https://github.com/iqm-finland/KQCircuits.git/tags/v4.8.0/klayout_package format doesn't work, so I pushed a new commit tagged as v4.8.1 where I change the <url> tag in grain.xml to recommended format. Tested using KLAYOUT_SALT_MINE that KLayout pulls correct package. But now as I want to update the package again, the preview link again gives me an error page.

So I thought at this point I should stop and ask for help. Which url format is recommended to use, is the error caused by this or something else?

Thanks,
-Pavel

Would it be feasible to add an undo/redo list with the latest xx actions performed (where xx can maybe be specified in the setup) when selecting Edit > Undo/Redo? Sometimes it is a bit cumbersome to undo/redo many actions, especially when I play a lot with layer visibilities in between editing actions.

Cheers,

Tomas

Now this is obviously unwieldy and many layers have
zero value in any particular activity. Many are just
legacy / artifacts of "how Brand X likes to do things".

I wonder whether there is, or could be, "multiple layer
table views" which make visible, valid, displayed, some
subset of the master layer table which is more compact
and maybe purposeful. Like maybe there's one ".lypv"
for plain polygon pushing, another for DRC that maybe
shows derived layers (?), another for just drawing bond
figures (top metal, pad, bulk and bondWire) or whatever,
that the user / PDK developer could define, save, edit,
and then invoke at will by (say) some layers-window
right-click selector?.