-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125871/#review87697
-----------------------------------------------------------
What's the point of client relative geometries?
Afaics, there'll be two "problematic" scenarios.
1) >= 2 taskbars on >= 1 screens, the window is minimized from the taskbar
2) >= 2 taskbars on >= 2 screens, the window is NOT minimized from the taskbar
(but the deco button, or wmctrl etc.)
(1) can be _easily_ resolved by the minimizing taskbar applet updating the (one
is actually sufficient here) geometry right before minimizing the client
The challenge of (2) is to select a taskbar where to minimize to itfp (I guess
one does not want to minimize to two regions at once, seems confusing)
The reasonable approach seems to minimize to any icon rect that is on the same
screen the window is on (WMs free choice), so we need a list of global (or
tagged screen relative) geometries where the WM can look for eg. the closes
match on the current ("active") or the windows screen.
The only benefit of a window relative geometry would be (less overhead on)
tracking a moving client while the window minimizes - but the only scenario I
see here is an autohiding panel and then the only overhead (if one wants to buy
into such feature at all) would be an update of the icon rect from the
on-screen to the off-screen position of the panel.
Otoh, keeping a reference to a surface around
a) requires a surface itfp
b) sounds *extremely* bug prone, eg.:
- I don't see where the surface removal is tracked in the patch, so we could
end up with a dangeling pointer.
- Another case is where the taskbar is moved from eg. a panel to the desktop
- we'd have it in the desktop and -outdated- the panel at the same time)
- Also what if I add a taskbar to the top and the bottom of my desktop?
That's not supported, is it?
=> Imo we *need* one icon rect per screen.
It would be cool to have one "per taskbar" (calc closest distance on unrelated
minimizations)
But I object the approach to assign the rects to particular surfaces.
- Thomas Lübking
On Okt. 29, 2015, 4:59 nachm., Marco Martin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125871/
> -----------------------------------------------------------
>
> (Updated Okt. 29, 2015, 4:59 nachm.)
>
>
> Review request for kwin and Plasma.
>
>
> Repository: kwayland
>
>
> Description
> -------
>
> this exposes the geometry of taskbar entries in plasma-windowmanagement, in
> order to make the minimize effects possible.
> unlike on X11, it takes relative positions and it has one geometry per panel,
> making possible to have multiple taskbars working.
>
> however this is still not completely exposed, as internally kwin has still
> only one geometry, it will need a change in kwin itself (suggestions welcome)
> probably the rotocol will need also a minimizeTo function that takes the
> panel as argument.
>
> another thing completely missing is tests: unfortunately the whole
> plasma-windowmanagement doesn't have any autotest yet :/
>
>
> Diffs
> -----
>
> src/client/plasmawindowmanagement.h abd8fa6
> src/client/plasmawindowmanagement.cpp 1f9674c
> src/client/plasmawindowmodel.h 5a6aac4
> src/client/plasmawindowmodel.cpp 355ef53
> src/client/protocols/plasma-window-management.xml ca6a7cc
> src/server/plasmashell_interface.h 9db3f52
> src/server/plasmashell_interface.cpp d29d7bc
> src/server/plasmawindowmanagement_interface.h 6ccc22e
> src/server/plasmawindowmanagement_interface.cpp ad714a5
>
> Diff: https://git.reviewboard.kde.org/r/125871/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Marco Martin
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
