It looks like you're new here. If you want to get involved, click one of these buttons!
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.
Kyle
Comments
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?
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.
Matthias
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":
Matthias
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.
Matthias
Hello,
Is there a Ruby command that would invalidate the layer from the script rather than the context menu?
Any ideas would be appreciated (-:
Sneha
But this is off-topic for this discussion. Please consider opening a new one.
Matthias
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.
Matthias
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.
Matthias
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
proceed?).
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?