decoration.h | [was: Review Request for KDecoration]

[Thomas Lübking]

On Donnerstag, 6. November 2014 13:58:24 CEST, Martin Gräßlin wrote:

> It's the "titleBarRect" - buttons and caption. The idea is to 
> have the backend 
> know which are is the titlebar, so that it can react on mouse clicks 
> accordingly. While writing this I realize that it might not be 
> needed at all.

I'd say we need to know which edge is the titlebar one (for keeping it in sight on restricted moves), but not the actual rect.
About input management: the core needs to distinguish beween
- move
- resize 1D
- resize 2D

Whether and what is required here is matter of what we want to support ;-)
In theory, one could declare a global behavior, like eg. the wing quarters of all edges perform 2D resizing while the inner half performs 1D resizing.
One could also declare the outer 4-6px (or pt) to perform resizes while the inner rest performs moving on every edge (ie. if you've a 20px wide frame, 14px are used to move the window) and also eg. if the border width is <= 6px, the 1D resize turns into movement.

In this case, the core doesn't require any hint from the deco.

The alternative would be to pass entire control to the decoration (what also implies different behavior for different decos) adn would then require either a list of offsets or ask the decoration for "virtual . windowFrameSection(const QPoint &localPoint)" on every mouse move.

> yes I thought about that as well when writing the code. But I didn't find a 
> class to friend with.

you could make it friend to some global "void _kwin_setDecoSettings();" or similar. Eg. compare QMenu which has
friend void qt_mac_menu_emit_hovered(QMenu *menu, QAction *action);

The function only exists in in the cocoa platform

QT_BEGIN_NAMESPACE
extern void qt_mac_menu_emit_hovered(QMenu *menu, QAction *action);
QT_END_NAMESPACE

.............


QT_BEGIN_NAMESPACE
void qt_mac_menu_emit_hovered(QMenu *menu, QAction *action)
{
    emit menu->hovered(action);
}
QT_END_NAMESPACE


> yes that might be an option. Do you think that Decorations 
> could benefit from that information?
Aside the generic clipping overhead (see Milian's mail), the information would (in this case) actually be provided in the QPainter::clipRect(), but explicitly passing that information stresses that only a part needs to be done (w/ zip overhead by re-using the same rect that was used for the clipregion anyway)
Telling the decoration what needs to be painted in this pass can provide some performance benefits as eg. painting the titlebar might include expensive operations (blurring the caption for a halo/shadow etc.) while the result is actually dropped.


Cheers,
Thomas