Closed e-calder closed 2 years ago
Thanks for reporting. Could you also report the enaml version, the Qt library, the python version and the OS you are running on ?
Hey, thanks for the speedy response.
enaml==0.12.0 (I know this isnt the most up to date version, we haven't updated to it yet... so it's possible it might be fixed there?)
PyQt5==5.14.1
Python is 3.8.10
OS is Windows 10 Pro, 64 bit
Cheers
I'm able to reproduce it here...
Does it make sense to check if the handle is valid or is there a better way to do that?
Eg, this fixes that particular case https://github.com/nucleic/enaml/commit/c21605ac2348495627e38f004f11791262f3329c
Thanks for reproducing @frmdstryr. I will investigate but enaml should prevent the need to explicitly checking the widget state.
Since I am not sure when I will time to dive deep enough to figure this out, I will spell a bit my guesses regarding what may be happening in case somebody else wants to have a look.
Typically enaml will have the backend (Qt) forward any closing request to the front-end (Enaml widget) which ensures that the back-end does not disappear without the front-end not knowing about it. However in this issue it is typically what happens.
~My best guess is that in the case of floating dock-window which are not backed by an actual enaml widget part of that logic fails when multiple dock-items are involved. Actually I think it would be worthwhile checking if vetoing the closing of a floating dock-item works at all and if it works hen multiple items belong to the same window. This is likely the easiest way to check if the front-end get the messages as it should. The relevant parts are under enaml/qt/docking, I think that the dock_manager, q_dock_window and q_dock_container are the most likely to be relevant.~ Actually the confirmation works, however I can reproduce and I found another issue when maximizing an element from a notebook when only the notebook exists in the area.
This seems to have been fixed. I attempted to replicate the crash but could not. Should we close this issue?
Hey,
I've noticed a crash related to maximised floating windows within a group... to reproduce:
1) Run
examples/widgets/dock_area.enaml
2) Drag out 2 or more dock items so they are floating, and group them into their own floating dock window (terminology might not be accurate, please excuse)3) Maximise one of these dock items within the dock window, then close the dock window via the outer red cross (circled).
4) This results in a hard crash, killing the application:
Thanks in advance!
Emy