It looks like you're new here. If you want to get involved, click one of these buttons!
I'd like to suggest a couple of "minor" enhancements to the command / function set. These stem from my past-life memories vs present day klayout work, where I have to keep a lid on "muscle memory". Not helped any, by picking up a couple of jobs recently where I was put back in the Brand X saddle. Dissonance galore.
If "masked selection" (i.e. a layer which determines what region of an instance is selectable) is not practical or interesting, I could use a "lock coords" property that prevents movement. I keep stumbling over the flickering back & forth of the Select and Move bar-items, moving when I thought I was selecting and vice versa. In many cases I want certain things to stay put and with overlapping selection-fields collisions and "spurious selection" cause me a lot of back-up-and-do-over. I especially would like to be able to lock a background image to its placed 0,0 center coords because it is selectable -every-damn-where- and I keep tagging it which messes up my efforts to duplicate a "found transistor" from microscope photo to a klayout cell. The "benchmark" function seems to require an object of reference. If locking position against move, or making a background image a non-selectable object are practical then this would suit me fine. But a benchmark object, itself could be carelessly moved and then same problem as present.
I still believe that the "extents" figuring on hover before selection, could efficiently be made to "AND" that result with a found layer rectangle. Though not by me. An adjunct Python "mselect" (masked select) script or an options toggle + layer-field to enable select-masking might be approaches. So could be a more accessible toggle for instance (and maybe other object-class) selectability, like maybe atop the layer table?
I would like a "m" (move) and a "c" (copy from-to) bindkey, same deal. Infix preferably. With repeat a F3 cyclic. For that matter I would like to rejigger the bindkeys with 100% access (believe some were "frozen" when I tried early on in my klayout adventure, and were ones I really wanted as they were common actions in my Brand X days). Having to hit the bar for select and moce and so on, is a real "stride breaker" when you've internalized bindkeys. You have to leave your layout location and sometimes this is disruptive. I could also use a "z" (zoom in, from-to, infix) and Z (zoom out, from-to, infix) as the mouse wheel is pretty "notchy" and yet can take a lot of turns and multiplle recenterings, to get what I could with one key and one click.
I mentioned recently elsewhere, a graphical PCell editor which could be used on gdsii layouts to add stretches, fingering, conditional elements (like for example a MOS tap / bar / ring as options, commonly seen) and compile-to-code to work as presently. Never have, never plan to do a code PCell from scratch - I'd be better off making a library of 1X layouts, time-spent and hair-lost-wise.
I would like text selectable area (now almost the flip-side of instance "too easy", near-impossible to point-select from any "altitude" and requiring a drag-select) to become the origin +/- text-size-property (Y) and text-size-property-times-char-count (X) - that is, the visible extent, not a dot (with a settable window, true).
Well I guess that's enough of a Christmas list since I've been a naughty boy again this year.
Comments
Hi @dick_freebird
Many thanks for your suggestions. I value such inputs, although I'm aware that such things enter the code at a slow pace. There is simply too much on my plate
Regarding the topics:
There is the option to make layers invalid. For images you can disable them becoming selected by using "Edit/Select" + uncheck "Images".
So I understand you would like to have a additional state like "locked" (selectable, but not moveable). Or is "invalid" / "remove from selection targets" good enough in parts?
For images, it will be possible to provide a "locked" flag on a per-object basis. For shapes it rather isn't, only for a layer as a whole.
If I understand that correctly you'd like a more sensible selection of instances. So is the problem that it is basically too easy to selection an instance without wanting too?
"Infix move" and "infix copy" is available, although not with F3 for repeat.
They are somewhat hidden in the "Customize Menu" setup at the end (they cannot be bound to menus) in the "Key Binding Targets" section and are called "duplicate_interactive" and "move_interactive".
Zoom in and out is available as "zoom_menu.zoom_in" and "zoom_menu.zoom_out" in "Main Menu".
That is not impossible and I personally like to do that, yet it's some effort. I can't promise such a feature will come soon. But I understand the wish to lower the barrier for enabling PCells.
That is a difficult topic as texts do not have an extent in the database structure, but I understand the concerns. The texts extent is not fixed as the font may be non-scaling or the text size is externally defined. This became necessary as OASIS does not feature text size. It is basically possible to mitigate the effect under certain circumstances - e.g. the presence of not too many texts inside the view.
A problem that will be very hard to overcome is the text visibility - when the origin leaves the viewport, the text is not longer seen by the drawing routine and the reason is that texts are point-like objects in the database sense.
Best regards,
Matthias
I'll address the segments individually since it was long to begin with...
Regarding the topics:
My "issues" are really with instances. Polygons, you can see what you are getting. Instances, you can select even on "white space" and multiple "white spaces" overlap, so selection is at best cyclic and sometimes you seem to never get the right one.
I believe you understand the Brand X select-masking and its singular use of the instance/drawing named layer. I am after an ability to (and/or) define a helpfully-constrained selection "handle", or prevent movement of a spuriously selected object that I declared to be "sit tight (for now)". To explain, I keep tripping over "selecting something that then moves, when I thought I was moving what's already selected". Part of this is that the Select and Move bar-items seem to "make up their own mind" what's in process. So I much prefer an explicit, key-bound invocation. More on that....
Yes, the proiblem is unintentional point-selection, or too many options from one point. That is what I used to use the instance-box for in all my own layouts. It creates the "handle" just where I say, and I can ensure that there is no overlap of "selectability". By a personal style of putting the instance box tight around the cell's text label, the location of that handle is obvious. And of course if you don't like it, doing nothing of the sort remains as-is.
If you are busy creating layout art, infix bindkeys are -much- more efficient than leaving the active window to traverse menus and then find your way back to where you wanted to be and do the additional coords-click. I'd say about 4:1 best case, the amount of manual events to arrive at the same result.
I guess if these things exist, but not in a form that can be key-bound, then my interest is in overcoming -that-. Or perhaps even more generally, that a key should be able to be bound to any native command -or- a user-identified script (perhaps from a specific script-corral?).
I have seen the zoom in, zoom out under Display (I do not see a "main menu" head-of-the-tree anywhere?). It works like the mouse wheel does, only without the recentering - in a series of steps, the size of which I do not control. Many times I know exactly what the zoom-to extents are that I want, but I will take a dozen wheel increments and mouse-positionings to even get close, and only as close as the "zoom granularity" wants. One key and one click would do it.
I wonder if there's a way to make an instance, with a text underneath, that takes its size and value from instance properties? Yeah, more instance select-collisions. But at least full-extent-selectable. Too bad I know nothing about how (say) a "text PCell" could be constructed.
@dick_freebird Thanks for your comments! I guess I understand the motivation. Let's see what can be done.
Best regards,
Matthias
I have had another thought regarding the selection / selectability
problem where multiple candidates exist at a location.
How about generating a list of "all presently-selectable-@"
and pop a checkbox-form, only in the case of multiple
valid possibilities? Then the user could say which, with one
click (or N, if multiple objects are desired). If only one, then
do nothing beyond present behavior.
I observe that point-select in such cases seems to be "cyclic, sorta"
and "almost" repeatable enough, that I have adopted a style of
shift-clicking until I see "instance master texts" start to pile up,
then deselect (ctrl-click) until the later one I want is all that's
left. Seems like the "cyclic" works the same order for deselect
as select. Mostly. If I'm lucky there's only two mashed up and I
either get what I wanted, or have to repeat and then deselect
the first. Still this "breaks my stride" often enough.
So seems like collecting the "@ point" set is easy-ish; building the
form and executing it when appropriate, seems like effort. But
maybe less than other approaches, with a useful result (i.e. I
get to say what I meant, directly, when there is doubt).
I like that idea. I'd just propose to make that a bindkey / modal function - people tend not to like popups if there was none before.
Like "Select from point"?
Or: there is the "Alt" key which is not used for selection yet. So when you press "Alt" and click somewhere you get a selection popup?
Matthias
Bindkey would be fine - I'm habituated to 'a' (add@point), 'shift-a'
(area-drag), 'ctrl-a' (deselect@point). Still not used to there being
alt- option to key bindings but that would be a fine place to start
(and maybe build out some of the other notions - I don't think I have
seen much use of alt-bindings.
Certainly there needs to be a division of effort between developer
creation of functions, and users learning how to use in a way that
makes development efficient.
So let me also suggest that the "alt rack" of key bindings, be set up
to let users (those capable) to link their own (or contrib) scripts to
a key, "choose your own adventure" style.
And then, mind wanders all the way back to SDA and Brand X early
vintage, how the CIW could be "harvested" for script-snippets and
those code-bits pasted under the menu buttons (which menus were
straightforward to edit and extend, through the same GUI). And
wonders, whether the foreground GUI menu / mouse actions put
out a command stream, which could be similarly "snipped and
wrapped" to sit behind a key-binding. I have not noticed a log window
or references to any such. Nor for that matter any primer on how to
edit and make permanently defaulted, altered binding-sets.
Oh, and other stray thought - what does "alt-click" presently do?
I could go either way, alt-a or alt-click (or both).
Just on the off chance that you haven't jumped up to humor
me just yet, here is another stab at "masked selection" (sorta)
which might solve the "stuff gets moved for being selected by
mistake".
That is, in the instance properties (or anything that uses this
kind of form, a "simple addition":
The operation would be that any object with this property set,
would be selectable but will not change its physical form / place
without explicit unsetting.
Then I can use hierarchy (Z) and locking (X, Y, theta) to keep
things in their places, one by one when they are done.
I imagine that this would "touch" property editor, and the Move and
Partial commands. I might suggest that Duplicate ought to reset
the "Lock P / R / S" property.
It might be much lower "overhead" than making select-hover scan
for next-layer-down polygons as part of preselection-highlight all
the damn time. Only comes into play when a few specific commands
are invoked.