Bug 370257 - [OS X] weird window "dissociation" glitch
Summary: [OS X] weird window "dissociation" glitch
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: 16.04.1
Platform: Compiled Sources macOS
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-07 16:58 UTC by RJVB
Modified: 2020-11-21 17:57 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot showing the glitch (85.00 KB, image/png)
2016-10-07 17:01 UTC, RJVB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RJVB 2016-10-07 16:58:29 UTC
I'm seeing a really weird graphic glitch in which almost the entire content of kate's window is duplicated when I move the application while it's starting up.

Kate must do something different, because it's also the only application which I've seen printing Qt warnings like below. The setScreen() attempt isn't a direct cause btw, because those warnings are printed instead of any actual work being done by the function.

QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.
QWidgetWindow(0x7fc40ce07a90, name="mainToolBarWindow") ( QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a child window.


Reproducible: Always

Steps to Reproduce:
1. start Kate with a document from a terminal ("kate foo.txt")
2. move the window before the document has been opened


Actual Results:  
See screenshot. The contents are shown twice, once where they belong, and once where they would have appeared if the window hadn't been moved.

Expected Results:  
no such weirdness.

This makes one wonder if kate always maintains 2 views, which only happen to be superimposed because the window usually doesn't move in between the successive creations.

- this situation can be rectified by going into and out from fullscreen mode
- moving the window moves both "areas"
- kate is the only application in which I've been able to provoke this behaviour.
Comment 1 RJVB 2016-10-07 17:01:39 UTC
Created attachment 101475 [details]
screenshot showing the glitch
Comment 2 RJVB 2016-10-07 17:07:37 UTC
I cannot reproduce this when starting Kate through the Finder; in that case its window also opens with the document already open. It is thus faster to start, but also faster to quit. And finally, when I start kate with a document from a shell, I'm seeing messages (when quitting) in the system.log:

Oct  7 19:00:45 Portia.local WindowServer[139]: _CGXRemoveWindowFromWindowMovementGroup: Window not in group

They also appear when I open a document directly in Kate
Comment 3 Justin Zobel 2020-11-13 03:26:02 UTC
Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
Comment 4 RJVB 2020-11-21 17:57:16 UTC
I don't understand how I could ever manage to move the window before the document opened. At least in the current version of the app and frameworks there is no more delay.