›

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.

  • altoalto

    I do not know about 30.0.7, I do not have it installed.
    My OS is:
    Slackware 15.0
    qmake-qt5 --version
    QMake version 3.1 Using Qt version 5.15.3 in /usr/lib64
    Kernel 5.15.193

    Binary are compiled from source with build.sh.
    Here are the core options used.

    mkdir builddir
    CFLAGS="-O2 -fPIC" \
    CXXFLAGS="-O2 -fPIC" \
    QMAKE_CCACHE=1 \
    ./build.sh \
    -bin builddir/bin \
    -build builddir/build \
    -j4 \
    -libcurl \
    -libexpat \
    -libpng

    Python 3.9.24
    ruby 3.0.7p220

    I will try to compile the 30.7 stand by ...

    Other comments

    The fix on the .cc was a experiment I friend did, I do not know how he drove claude to get that.
    Surprisingly it fixed the problem, at least on my side, without side effect.
    Claude description of the problem is meaningless to me :).
    If it does not make sense, just ignore it.
    But, don't throw the baby out with the bathwater.

    AI is not a good tools if used blindly, but it can be a good tools to learn stuff in area
    where you lack of expertise a bootstrap.

    It is like using wikipedia. It give you an idea of the problem, some time more than that.
    It is not a replacement of reading the books or the papers.

    Well, wiki is way more curated than AI outcome, to be fair, but you got the idea.

    But not everybody need to be proficient on anything is out there, some time you need to know
    I little bit to understand what to do next.

    Claude AI (specifically claude) apply to klayout documentation/code it is a good approximation of
    wikipedia for what I need.

    I use mainly to to generate code example when:

    1. I do understand the documentation (often)
    2. the documentation is not enough
    3. example are in ruby.

    Because 95% of those AI examples work the first time, it is a big help. Even when they do
    not work, they give some inside where to look.

    My target: I have to port many thousand lines of skill code to python

  • altoalto

    0.30.7 does not have the problem.
    0.30.4 has the problem.

  • MatthiasMatthias

    Okay, thanks for letting me know.

    I honestly don't have an idea how that got fixed. There was not a specific bug report for that case. Maybe the fix was a side effect of another fix or feature.

    Thanks and best regards,

    Matthias

Sign In or Register to comment.
Powered by Vanilla