›

Select and select filter

altoalto
in KLayout Development

Not sure if this problem has been reported already, I did not find anything about it, in the forum.
klayout 30.4 the edit->select allows to set what object get selected. The problem is about 'enable all' and 'disable all' do not update the filters.
filters = the objects that should be part of selection or not.

How to reproduce the problem

  1. enable all (all filters are mark as active, everything is selectable)
  2. disable instance (all filters are mark as active but instance, work as expected instances are not selectable )
  3. disable all (all filters are mark as active but instance ! nothing is selectable )
  4. enable all (all filters are mark as active but instance ! everything is selectable )
  5. enable instance (all filters are mark as active, instance are not selectable)

After I few back and forward between 'enable/disable all' and filter selection, the meaning of the check mark
on the filter is completely out of sync with what happen in the real layout.

I guess the intent was to have 'enable/disable all' to turn ON/OFF all the filters, then use the filter check mark to turn ON/OFF each
individual object selection.

Comments

  • altoalto

    In case the explanation is not clear here is a video of the problem
    https://u.pcloud.link/publink/show?code=XZyvg65Zks7Xt6BjPfbWjpCKJCfb98F7UDwV

  • altoalto

    We ask claude to find out the problem. This is the patch it generated if you are interested.

    https://u.pcloud.link/publink/show?code=XZcVP65Z5aVitmoR2d5ihCyFfSF1LXyDJ9kX

    I verified that fix this problem on 30.4.

    This is the comment added to the patch

    I located the bug in src/laybasic/laybasic/layPlugin.cc. The filter-sync issue is caused by two interacting problems:

    1. set_editable_enabled() (lines 299–309) short-circuits on f != m_editable_enabled.
      Once the cached field drifts away from either the visible checkbox or the Editables::m_enabled
      set, Enable All /
      Disable All iterate and find every guard already satisfied, so no set_checked() call and no editable_enabled_changed_event() ever fire — the UI and the underlying state stay stuck.

    2. toggle_editable_enabled() (line 74) computes the new state as !editable_enabled() (the cached field) instead of reading mp_editable_mode_action->is_checked(). Qt has already flipped the QAction
      before the slot runs, so the QAction is the source of truth; any transient drift puts the two computations out of phase and seeds the drift the first problem then locks in.

      Patch (applied)

      src/laybasic/laybasic/layPlugin.cc:

    • toggle_editable_enabled(): read is_checked() from the QAction (Qt already toggled it) and pass that to set_editable_enabled(). Falls back to the old behavior if the weak_ptr is null.
    • set_editable_enabled(): always assigns m_editable_enabled, always force-syncs the action's checked state when it diverges, and always fires editable_enabled_changed_event(). The listener
      (LayoutViewBase::signal_plugin_enabled_changed) is idempotent — it reapplies every plugin's current state to its Editables — so firing on every call is safe and repairs any prior drift.
  • altoalto

    The patch had fixed some issue like enable all / disable all. But not all possible conditions.
    For instance disable all + enable partial work as expected, + enable polygon does not enable
    polygon selection and partial. Still the filter selection does not reflect the behavior.

  • altoalto

    I take it back, I was testing the wrong case assuming polygon are the same as box but they are not.
    It seems to really fix the problem.

  • MatthiasMatthias

    Sorry, I can't reproduce the problem with 0.30.7, Linux (Ubuntu 24.04, Qt 5.15 and Qt 6.4) and Windows. I also tested with a virgin configuration to ensure that no script of mine interferes. Finally I also tested with version 0.30.6 from the IIC-OSIC-TOOLS docker.

    I all works for me as expected.

    There has not been a change in that code section since 2020, so there is no bugfix that would explain a difference between 0.30.7 and your 0.30.4.

    I disagree with Claude's analysis in several aspects. If Claude had understood my intention, it would have noticed that the "source of truth" is the "m_editable_enabled" member and not the QAction. But instead of looking at the code at that angle, it proposes a change that halfway switches the source of truth to the QAction - so in fact it destroys that concept. It is even aware of that because it proposes to unconditionally emit a change signal to preventing "drifting away". As I can't reproduce the problem I can't say if and why that nonsense of a patch fixes the problem.

    This all confirms my general suspicion towards AI: once you really try to understand what it is doing, you hit a wall of bullshit. AI is just messing with our heads.

    Human intelligence says: if you face a mismatch between actual state and display, that speaks more for a Qt synchronization issue. Maybe some specifically old or new Qt version?

    You can help by giving me some details, like:

    • Does it work with 0.30.7?
    • What is your OS and your Qt? From the video I assume it's Linux, but which?
    • What binary are you using?

    Matthias

    P.S. I have attached a Video of my session. It's embedded inside a .zip file as this forum does not allow attaching webm.

Sign In or Register to comment.
Powered by Vanilla