Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
PCell tweaking UI/UX issues, ideas & proposals
Hello,
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:
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.
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.
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
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
Comments
Hi Gerard,
thanks for these deep thoughts and the detailed explanations.
Here are my comments:
The object properties dialog is a much different beast than the editor options. It allows for example to edit multiple selected objects at once and supports multiple types of objects. Maybe it's possible to reflect the properties of a single selected object in the editor options, but I can't say without further analysis.
The object properties window is modal currently. Without that, a lot more of synchronization needs to happen between the properties window and the layout view. Again, the properties window is a complex thing, so carrying that complexity two ways is rather challenging. Not impossible, but will be a major change.
But I can't confirm the properties window goes to the back. At least on Linux, it's always on top.
Because the window is modal, mouse events don't reach the main window and scrolling/zooming is not straightforward to implement. As in proposal #1, having a kind of interactive properties window would solve that situation, but at the price of higher implementation complexity.
BTW: you cannot open a window in a separate thread. Not in Qt.
Free styling of the PCell parameter page was already requested some time ago (https://github.com/KLayout/klayout/issues/1478). Yet it's some implementation effort I was not able to invest so far.
The PCell does not live in the current layout, so it can't interact with it. It lives in the library it is defined in and there is a one-directional connection only: the layout sees the PCell, but the PCell does not see the layout. That isolation is crucial for caching and state management, so it can't be dropped.
The Layer type is no exception, only the drop-down button is configured for convenience. But the information is an abstract layer descriptor without a connection to the layout.
Technically, all information a PCell is needed is presented at the time of the various callbacks (like produce_impl). This keyhole concept allows caching as it is guaranteed that the results will only depend on the information presented. This implies that the PCell implementation must be stateless - i.e. does not store data anywhere else, similar to a function implementation that does not use global variables.
I'd love to work more on the UX features, but KLayout still is a single-person spare-time project, and there are more important things to worry about currently.
Matthias