Re: Proposal: Kirigami, QQuickStyle, Window backgrounds

Hi,

in general I am in favor of removing excessive overdraw (cf. [1]), 
putting a background rectangle in when we can instead adjust the window 
color. In fact, I did that in KClock [2] but had to revert it after 
Kirigami introduced the new page transition.

However, I am not sure the added complexity and performance impact, 
especially the shader stuff (that won’t work with software renderer) is 
justifiable.

Cheers Kai Uwe

[1] 
https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-renderer.html#visualizing-overdraw

[2] 
https://invent.kde.org/utilities/kclock/-/commit/dcf179fcb6e1daeaa625fee7b213c6289ec17f9e


Am 31.01.26 um 01:21 schrieb Michael Martin Moro:
> Hi !
> 
> Some time last year, I implemented a very simple QQuickStyle for Oxygen. 
> However, Kirigami applications wouldn't display the iconic gradient 
> background, as Kirigami Pages feature their own background. Upon further 
> inspection, I figured a/the reason why that background was enforced: 
> StackView transitions between pages required it, as a transparent 
> background visually breaks the transitions.
> 
> I came up with the following patch:
> https://invent.kde.org/plaristote/kirigami
> 
> First thing it does, is getting rid of the Page's custom background, 
> which allows the Window's background to be visible (at least when the 
> Window component is used, which isn't always the case: I believe 
> systemsettings is an instance of that).
> 
> Since that breaks the page transitions, it also uses ShaderEffect on the 
> Page element, which duplicates the Window's background, as an underlay, 
> updating the offset as the transition updates, so the background remains 
> still. The effect gets enabled when the StackView status for the page is 
> either Activating or Deactivating.