KWin contextmenus usability and window/app specific palettes

[René J. V. Bertin]

Martin Gräßlin wrote:

Oops, this reply sat unsent in the background for a few days as I went off on 
another hunt for something more urgent. KWin5 turns out to have a tendency to 
become unstable on my system, resulting in visual glitches with screen contents 
not being updated properly when I switch virtual desktops or raise/lower 
windows. No idea if that's related to my build, my configuration (very short 
animations, none for raise/lower or desktop change), the DR*, Mesa or Xorg 
libraries or simply the i915 driver's support for the Braswell/CherryView GPU.


>>     bus.connect("org.kde.kwin", "/KWin", "org.kde.KWin",
>> "compositingToggled",
>>                 this, SLOT(compositingToggled()));
> 
> This connect is broken. KWin no longer emits the signal on /KWin and
> neither in the org.kde.KWin interface.

Hmmm, the style is also still used on Plasma4 desktops so I guess I'll have to 
keep it in. THanks for the KWindowSystem replacement info, it appears to work 
even on a Plasma4 desktop and using KWin4.

> KWin no longer takes org.kde.kwin, but org.kde.KWin. So the connects are
> 100 % broken.
> 
>> 
>> The tweak to omit these connects in KWin itself comes from a Debian
>> patch, I
>> just added the connect to themeChanged() myself after noticing in the
>> Aurorae
>> theme sources shipping with KWin 5.9.3 .
>> 
>> Are those connects still relevant, and should they indeed be excluded
>> for KWin
>> itself?
> 
> Whether or not I cannot tell you as I have no idea what QtCurve used to
> do there. KWin does not have any /QtCurve installed. That's a question
> you would have to pass to QtCurve developers.

The problem with that is that the main author who wrote most of this stuff (as 
well as the window decoration code) is MIA. It's not the easiest code the 
reverse-engineer if you're not already well familiar with the APIs it uses.

Either way it sounds like I don't have to bother updating those /QtCurve 
connects for Plasma5. The borderSizesChanged connect still works with KWin4 
though.

In the meantime I have come to see the potential interest in excluding KWin 
itself from processing the signals: preventing loops or at the very least 
preventing the same event being processed twice.

R.