Using kde-workspace-4.9.2-1.fc19.x86_64 Reproducible: Always Steps to Reproduce: 1. Group two windows 2. Close the _left_ window-tab Actual Results: The window border does not repaint correctly See screenshots
Created attachment 74252 [details] Screenshot: two window tabs
Created attachment 74253 [details] Screenshot: left window tab closed, incomplete repaint
Oh, to reproduce: the right tab needs to be focused when the left one is closed.
do I see correctly that you do not use compositing (desktop effects?)
No, I am using compositing, though even without the issue still is present.
please post the output of qdbus org.kde.kwin /KWin supportInformation check whether the issue remains when you change the graphicssystem (NOT the compositor backend)
Created attachment 74259 [details] supportInformation Yes, the issue is present with both Native and Raster subsystems.
@Martin revert the recent deco pixmap repaint redirector patch - the bug is there w/o just as the "weird" titlebar updating in the uncomposited resizing case. Even "worse" - the close button in the deco is still "operative" (hovers until the next repaint) and if you click it, you close the remaining window. @Hugo Is there any reapint triggered behavior in the oxygen deco and/or some extra animation beyond the configurable one? Esp. try the deco w/o compositing.
forgot attaching...
seems to me like we need to trigger a full repaint whenever the tabs change.
Should be done by the deco, though. It's imo not the cores job to cause random updates on the deco, not even on resizes - the deco know that sth. changed and whether that's relevant for its graphics. Splitting the duties and have the core update the deco for "some" reasons that might affect it sounds like begging for errors as too many or few repaints.
@Thomas, I agree. In the "old" implementation though, I think I remember that there was issues with that though, in the sense that at least some times, the client was not aware of the other being closed. I'll double-check whether its still the case.
... in fact, there was several issues with alerting the client that its "tab buddies" have changed anyhow, which is why tab geometry is currently updated in ... paint Event (which is suboptimal if you ask me). Again, I'll see if this can be improved (on the oxygen side). ... in case you have any advice or insight on the matter.
On Monday 01 October 2012 17:56:50 you wrote: > ... in fact, there was several issues with alerting the client that its "tab > buddies" have changed anyhow, which is why tab geometry is currently > updated in ... paint Event (which is suboptimal if you ask me). Again, I'll > see if this can be improved (on the oxygen side). ... in case you have any > advice or insight on the matter. yeah the old way s***** There are now a few virtuals available which should do for the task.
... trying to connect an "update" on tabCloseButton clicked signal does not work (is never called, possibly because the event is eaten by parent class event filter) Trying to trigger update in own event filter (even after parent class eventFilter is called) does not work either: at that time, the tab has apparently not been closed yet, and so there is no valid update ... Apparently an update is needed after the client has been actually closed, and I don't know how to trigger on that from within the (surviving) client. Any advice ?
Hmmm, just had ported what was there ;-) Actually the tabgroup repaints the decoration whenever it believes that's necessary, but that is of course rubbish. We "emit tabGroupChanged();" from the Client whenever that happens (and it does also happen when removing a tab), but so far the deco cannot connect that (neither is it passed through a virtual) However: the decoration repaint _does_ get triggered when (after) removing the tab. Together with the redraw issue many decos show w/o compositing, but bespin does not, i wonder whether there's some bug in kcommondecoration (the redraws seem like updates on resizes, ie. you get one when remaining at a size for a short moment)
Hello, after adding some printouts in oxygen client, it appears that at the time an "update()" is called to the surviving client, both tabCount() and my internal counting of types are stil set to 2. Hence the glitch. This only happens if you close an *inactive* client. If you close an active client, then the surviving one, (which becomes active) has the right number of tabs at the next repaint (and is therefore repainted proporly). I hope this helps. Thomas ? Are you experiencing the same with bespin ? Hugo
i can confirm for 4.10.95 too
The bug is still present in 4.13.1.
Unfortunately the rework in decorations in KWin 5 resulted in the window tabbing feature to be lost. We still want to bring this feature back, but after several versions it still hasn't emerged yet. Given that I think it is time to adjust the status of this bug report. The new implementation would be different anyway and it's questionable whether this report would still apply to it.