This repository has been archived by the owner on Aug 10, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 100
Glitches upon the closure(destory) of a window in macOS 11.4 #39
Comments
Can you start WEKA without any installed packages and try to reproduce this? I could not reproduce the behavior in your video (using the same version of the OS and the same version of WEKA). Did you perhaps run WEKA on an external display? That is the only other possible difference I can currently think of. One way to start a clean version of WEKA is to rename the wekafiles folder (or delete it). |
I was using an external display, but I've tried it with only the build-in display, still didn't work out. and then I tried to open .jar file in the terminal, it threw an exception every time I click the dead window. demo: weka.mp4terminal exception outputjava.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062)
java.awt.Component.getLocationOnScreen(Component.java:2036)
sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:418)
sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:416)
sun.lwawt.macosx.LWCToolkit$CallableWrapper.run(LWCToolkit.java:597)
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
java.awt.EventQueue.access$500(EventQueue.java:97)
java.awt.EventQueue$3.run(EventQueue.java:709)
java.awt.EventQueue$3.run(EventQueue.java:703)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
java.awt.EventQueue$4.run(EventQueue.java:733)
java.awt.EventQueue$4.run(EventQueue.java:731)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
at java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062)
at java.awt.Component.getLocationOnScreen(Component.java:2036)
at sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:418)
at sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:416)
at sun.lwawt.macosx.LWCToolkit$CallableWrapper.run(LWCToolkit.java:597)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
at java.awt.EventQueue$4.run(EventQueue.java:733)
at java.awt.EventQueue$4.run(EventQueue.java:731)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) I will get along with this problem but can see if more feedback related to this arises from others. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I think this problem is UI related, please fix it, it deducts the user experience. It happens on my machine, I am not sure for other system like Windows.
Recurrence
Open any one window that in applications and close it, the window will be frozen but still be displaying on the screen.
Screen.Recording.2021-07-07.at.6.40.44.PM.mov
And when opening a new application window, the previous one that has been closed will disappear(be destoryed).
It seems to be a new window is invoked, the previous one is destoryed to some custom java windows. The LogWindow totally has not a problem related to this, and the LogWindow can only have one instance, instead of like that can hold multiple Package Manager, which confused me. (Logically I do think the Package Manager shoulld have only one instance, also for some other utils)
Same thing happens to the other window in Tools. The Memory usage window also has this problem.
Analysis
There must be some logical problems with the closure confirming.
Firstly, some of windows should not have multiple windows, there's no reason for it, like Package Manager or Meomry usage.
The problem occurs in any window that can have multiple instances, and they all go with a closure confirming window, like this:
The LogWindow only has one instance, it will be closed immidiately when click the close button. The open file window has no confirm and it will close immediately as well. As shwon in the screen recording above, when close a window but the window is still upon the screen, create an arbitrary window will ensure the closed window is "destoryed". To clarify, the arbitrary window can be another application, or LogWindow, etc. and the closure confirming window is counted among it, and the screenshot below is a "About GUIChosser" window, that works as well. (I think this window might be different from the Windows.)
Another one is, when close a window and it has not been destoryed, switch to other apps and switch back, it might be destoryed by then. It happens sometimes. If it still exists there, click the button to close again it may close immediately or create a new window to have the same effect.
Workaround
Create any new window can destory a closed window. If create a new window that does not have the closure confirming then we can close the new window immediately.
The text was updated successfully, but these errors were encountered: