Prevent inspector from adding itself to the window #5658
Conversation
|
Yup, confirmed, this works! I guess you should apply it to console and joycursor modules as well |
|
I looked at that those but they don't have an 'activated' property, so this
fix is not directly applicable.
Can they be switched on and off like the inspector? If not, they are
probably fine add is...
Richard
ZenCODE
…On Sun, 18 Mar 2018, 13:07 Terje Skjaeveland ***@***.***> wrote:
Yup, confirmed, this works!
I guess you should apply it to console and joycursor modules as well
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5658 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADYDKx8SxqroleLdG6g-WXGfo0gqHiq2ks5tfj_qgaJpZM4Su6N3>
.
|
|
I just noticed those modules appeared to do the same thing
Am I missing something here? |
|
Indeed not. Not sure how I missed those when searching, but nice catch. Thanks. So, when using the console, it appears immediately when the popup does. These changes fix that. When using the joycursor, simply deactivating it throws: These change fix that too. |
Zen-CODE
changed the title
|
Hmm. There is an annoying issue with the travis builds where it seems to hang after the graphical unit tests. Just doing some commits to experiment and see if I can find the issue.... |
|
@Zen-CODE is this still WIP ? |
Zen-CODE
changed the title
|
I think it's ready to be merged. It does fix the issues mentioned above. The reason I was holding it back is that I hit an issue in the travis builds. In earlier commits, it passed all travis tests. Then suddenly, it start hanging on the last 'test_widget_popup' test in kivy/tests/test_module_inspector.py'. It works fine on my machine, but when push to github, it does not get past the last 'self.render(self.root)' call on line 296. The test then times out. But since, I've tested with and without the changes. Both never get past that line. So these fixes do not introduce this issue at least. But it's strange that they did pass initially.... |
|
@Zen-CODE According to travis-ci/travis-ci#6861 the hang may be caused by xvfb background process. It may help to do |
|
@bionid. Is that what you meant? Now we seem to get a a new set of errors... |
|
@Zen-CODE well it needs to refer to the xvfb process that is started here. I'm not sure the exact syntax to stop it correctly, so I left out the rest of the arguments as an exercise for the reader ;-) As a test (or solution..) you could try |
|
This seems like a hack route. I wish there were some way of finding why it does not exit cleanly on the travis builds but is fine on a running locally. It's probably related to the need for this PR. Something in that last 'test_widget_popup' test is different but I cannot see what.... The mocks around the app event loop make it difficult to debug or follow. Not sure what to do from here. It solves the original errors, so is maybe worth merging? Or how to identify to reason for the hang? |
|
@Zen-CODE I have no idea about the details concerning travis, but the fix looks good & resolves the issue, from my perspective good to merge... But this pr is 19 commits for +8-3 lines, better to squash before merge |
|
Will do...:-)
Richard
ZenCODE
…On Sat, 21 Apr 2018, 18:47 Terje Skjaeveland ***@***.***> wrote:
@Zen-CODE <https://github.com/Zen-CODE> I have no idea about the details
concerning travis, but the fix looks good & resolves the issue, from my
perspective good to merge... But this pr is 19 commits for +8-3 lines,
better to squash before merge
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5658 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADYDK8moA7vmLO0BMvP0vbsDZgfaHd4wks5tq2KhgaJpZM4Su6N3>
.
|
Signed-off-by: Zen-CODE <zenkey.zencode@gmail.com>
the root cause of the issue hasn't been identified but: - the render() call blocks, apparently waiting for a window flip event - it's been introduced by commit be1ce, which prevents adding a widget to a window if it already has a parent. - checking in inspector if it already has a parent before adding it to window doesn't seem to fix the issue. see #5645 ##5646 #5658
Based on #5645, I managed to reproduce
the Inspector "already has a parent" error but it happens immediately I pres "Ctrl + e" to open
the inspector and only when a popup has been created.
To debug this, I monitored the 'on_parent' event of the inspector. It turns
our the Inspector binds to the 'children' event of the window and then tries
to add itself when whenever th 'children' Window event` fires.
As the ModalView adds itself directly to the Window, the event fires and the
Inspector adds itself even when it has not been activated. This is clearly
not desired behavior.
THe PR adds a check to the Inpector to detect that it does indeed want to
re-insert itself into the children.
@bionid. Please confirm it fixes #5645 as I
could only reproduce this when creating the popup, not on closing the
inspector as your ticket indicates. It also seems to fix the error in the travis builds, so those should pass if this is merged :-)