Any way to lock or restrict the movement/ dimensions of cells/shapes?

I am working on a code that will take input from a Qt window and automatically generate some shapes in the current view. Just for clarity, I'm basically just generating a couple rectangles where the user will later place down smaller shapes on top and then run some rule checks. I know that I can hide some cells, but the whole point is that the user needs to be able to see the borders of the background rectangles / other shapes and be able to place the smaller shapes along that border if needed. So it would just be easiest if those shapes were not movable or editable to avoid accidental movement while still being able to snap onto those edges.

I looked through the documentation but couldn't find anything that would allow me to lock the location and dimensions of a shape I've created. The closest thing I could find was the basic editor options, but the user would need to select those options manually -- and even then, they are still allowed to edit the dimensions of the shapes. If possible I'd like to lock the dimensions & locations of a few shapes, and in another case only lock the width of the shape and allow the user to edit the length but dragging the edge like usual. Are there any methods for this? If this is something that the program was not intended for then I understand - just figured I'd ask in case I was missing something obvious.

Thanks for your time & help.



  • This is something I've been interested in. My thinking has more
    revolved around the selection process and how to make it
    "maskable". But this could take several forms.

    You could add a "lock position", "lock properties" bit(s) to the
    instance properties list (whatever form that takes). Select
    functions I expect could be taught to respect that. But this is
    probably not a basic feature of GDS-II database and might
    get lost across import to another tool, even if faithfully
    exported such that klayout could open later with functionality
    there, intact.

    Another thing I like (one of the few, about Brand X) is how they
    used to purpose the instance/drawing layer to define a cellview's
    selectable extents. Absent, the computed data extent as rectangle
    is actively selectable. Place an instance/drawing object and that
    then becomes the selectable area. I would always put the cell
    label text inside such a box, so you have to click on the label to
    grab the object - handy when there's lots of kooky overlapping
    shaped objects, or objects on top of objects.

    And then you could consider taking this further, like if you did
    have a placed instance/drawing rectangle in the cell, then how
    about "compound logic" like, inst/dwg defines selectable area
    but such a polygon, texted by "lock" text on inst/dwg, will "see"
    where selection would be allowed, but also recognize that this
    should be inhibited from above (but then, how would you get
    back in there to remove it if need be? Some special "select
    because I said so!" function that acts just like the present
    select mechanism, ignoring all the added modalities?

  • edited July 2022

    That sounds super interesting. But I guess there's no way to do any of this already then.

  • Don't take my word for what's possible or practical.
    Only what I've seen, and what I'd like to see.

    I imagine that a smart guy could code up a script to
    perform a "masked select" and then it would be easy
    (I'm told) to add it to your private macro set, or for
    developers to take it up as (say) a menu option, maybe
    a "checkbox" option to use "smart select" over "select"?

  • Maybe making the layer "invalid" is what you need?

    Invalid layers are visible (unless hidden), but shapes on invalid layers cannot be selected or manipulated. They are basically just background drawings. So shapes on these layers are "locked" if you want.


  • Yes thank you, that would probably help me too. From what I've seen, there isn't a way to snap the edges of shapes to other edges when doing move/partial operations in the editor, so I don't think that would create any problems for me anyways. Or is there actually a way to do that?

  • Oh, there is. "Snap to other objects" in "Basic Editing Options":


  • Thanks not sure how I missed that. But for some reason I can't get that to work for me -- it doesn't change anything. I think I'm using it wrong. Do you have any tips? Do the shapes have to be in the same cell? I'm trying to use the Move and Partial tools.

  • Suspect that this pertains to polygon objects sharing the same level of hierarchy? Or, needs the "deep" selection mode turned back on (but that might get real messy)?

  • I forgot mention that this only applies to drawing shapes, not when moving them :(
    That is actually a good suggestion. I have not thought of this so far.

    But at least object snapping is independent of whether you have "deep" or "top level" selection mode.


  • Hello,
    Is there a Ruby command that would invalidate the layer from the script rather than the context menu?
    Any ideas would be appreciated (-:

  • RBA::LayoutView::current().selected_layers().each { |i| i.current.valid = false }

    But this is off-topic for this discussion. Please consider opening a new one.


  • edited March 1

    I would still like to get to a "masked selectability" behavior /
    feature similar to how Brand X used the instance/drawing layer
    (until recently - I have been seeing PDKs where this is damaged
    by the instance/drawing layer being inactivated).

    I would like to be able to (in klayoutrc, or something in the DB)
    define "the" selection mask layer/purpose, and for any layout
    object have its selectable extent be that rectangle or polygon
    (Brand Z only seems to look at rectangles, or the rectangular
    extent of a non-rect polygon).

    This can eliminate "select target confusion" when instances
    overlap extents. I prefer to place the instance box around the
    cell's text label as a dead-obvious, limited-extent select target.

    Perhaps this could be a modality in the Select ribbon menu?
    Maybe a pop-out with a "sticky" layer/purpose entry field that
    you can set once and forget, at least for the session's duration
    (if not DB-bound; maybe don't force a specific layer/purpose
    since we may not know what numbers, instance/drawing
    comes out on - an interest being, to mess with Brand X
    sourced GDS files in all their detail and functionality).

  • I see. Problem is that there is no annotation in GDS that allows me differentiating a layer for a specific purpose. So this can only work with a specific layer properties file.

    I think of allowing layers to adopt some special purpose - maybe also in terms of snapping targets, pins, comments, etc. Still they can be/have to be mapped to a GDS layer/datatype to make them persisted. So you can mark certain layers as defining the "selectable cell extent", at least in "top level only" mode.


  • I'm thinking that this goes to the "selection process" and any
    old layer/purpose pair would do (although for general Brand X
    compatibility I'd default to named "instance/drawing" absent
    any overriding declaration of "selectionOutlineLayer".

    The selection, rather than highlighting raw cell extents, would
    highlight "(raw_extent AND selectionOutlineLayer)" instead. Then
    act upon that/those in the usual way. Only selectionOutlineLayer
    rectangles / polygons at the "candidate object"s' top level apply,
    nothing higher or lower in the hierarchy (until you change
    present-level, then refilter).

    That seems like a "compartmentalized" logic change. Or one
    that could be part of an add-on script, perhaps?

  • That feels more like it should go into a technology option.

    The code changes will affects many places, so that isn't a straightforward change, but manageable. Some functions such as the Fill (tiling) or the Adjust cell origin function already allow using a specific layer for the boundary. But editing/selection is not doing so.


  • Well, let's dial it back to the most basic - what about "just"
    making a "masked select" (point, area, all) function which
    could sit alongside the existing, but do that one thing?
    While leaving the as-was selection code and what might
    depend on it, intact?

    That's what I was thinking might be "just a script" (though
    among the many missing clues, is whether that itself is
    a practical thing; could a "rogue script" reach into the
    "selected set" and then klayout proper, recognize and

    Or since many (though, last I looked, not all) of the
    bindkeys can be redefined maybe such a script, plus
    a klayoutrc redefinition (?) could retarget selection
    commands to an alternate (masked) version? Or have
    a toggle that defaults to as-was?

Sign In or Register to comment.