porting the QtCurve kwin theme

[René J.V. Bertin]

On Saturday July 02 2016 15:55:22 Martin Graesslin wrote:

>One cannot have a wrapper/proxy. KDecoration was modelled around QWidget with 
>KCommonDecoration using QPushButtons for the buttons. KDecoration2 doesn't 
>depend on QWidgets any more and all it has is a QPainter based API for 
>rendering and QEvents for input interaction. Wrapping the old decoration is 
>not possible due to the QWidget dependency, KWin would not be able to render 
>it.

About the only thing I know of QtCurve's window decoration is that it was (once) based on Plastik. I've tried to contact the original author (Sandro Giessl) but he appears to have gone MIA. The common ancestry with Plastik can still be seen in the window titlebars, but QtCurve has added quite a few options to tune the rendering, which can only make a porting process more difficult. Otherwise the fallback approach would be to port the current Plastik style all over again...

>based. A code base which heavily depends on QWidget is difficult to port. A code 
>base which has the rendering abstracted and uses KCommonDecoration is easier 
>to port.

Didn't you say KCommonDecoration uses/d QPushButtons?

>My suggestion for a port is to separate the drawing logic to have it free from 
>QWidgets

That at least sounds like something I could start looking at.  I just hope there isn't too much in the code that will make QtCurve hard if not impossible to port without sacrificing its individuality.

Maybe the following observation sheds some light on this question? As you know I've spent some time recently to provide a QtCurve option to render checkable menu items with only a tick rather than a tickbox or radiobutton. There's no way to toggle the corresponding option temporarily, so I was very surprised to see that the Activities submenu (accessible the context menu obtained via a right-click on a window titlebar) uses tickboxes while all other menus use checkmarks.

Cheers,
R