Vlad Zagorodniy <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #5 from Vlad Zagorodniy <> ---
(In reply to Martin Flöser from comment #3)
> We might have to fork the effect and have it work differently for X11 and
> Wayland windows.

IMO, that's wrong. Maximize effect do scaling and translation in a virtual
space, that's all! It doesn't need to know whether it's Wayland or X11 or

The root of the problem is manual tracking of window geometries. KWin knows
what previous geometry was so it should provide it to the effect. I'd taken
this approach in

Beside, the maximize effect tracks all geometry changes, that's totally wrong,

Another problem is that in some cases KWin changes geometry multiple times
behind scenes. This leads to "visual artifacts".

Yet another problem is cross fading. "Note: the window pixmap is not kept
forever even when referenced". This is a broken contract between effects and
core KWin.
Also, it doesn't work on Wayland.

In the best scenario, each window should have a state log so effects could look
up previous state and do whatever they want. E.g. 

auto currentGeo = w->stateLog()->current().geometry();
auto prevGeo = w->stateLog()->previous().geometry();
morphGeometry(w, prevGeo, currentGeo);

But this would be really big change also it's not really clear how to handle
state log(e.g. how to merge states, etc). Yet, I wish KWin had this.

I suggest to change windowMaximizedStateChanged's prototype to

void windowMaximizedStateChanged(EffectWindow *w, const MaximizeChangedData

struct MaximizeChangedData {
    bool vertically;
    bool horizontally;
    QRect oldGeometry;
    QRect newGeometry;

so effects have at least minimum required information. Also, it would break
compatibility with third-party effects. But if I were asked to choose between
working effects and compatibility I would choose "workking effects".

You are receiving this mail because:
You are watching all bug changes.

Reply via email to