sebas added a comment.
Well, the zoom effect is definitely the wrong way, it's broken (can be triggered without moving the mouse, expands windows outside of their allotted area (looks like broken sizing/placement), isn't animated so feels very choppy, isn't using well-known highlight semantics), the result is that it feels unnatural and jarring. To be honest, when I looked at it, I was looking for a bug in the code, e.g. margins not being taken into account. It didn't come up in me that this could be wanted behavior, until I read the code. As to the original commit message: The highlight is useless for this case, as any window can be dragged or activated, highlighted or not. What *could* work is to somehow intensify the colors, but that again would have to be animated, and play well with the ongoing desktop-zoom animation, the mouse pointer location changes relative to the window, so it's really complex to get right. I thought of this for a while, I don't think the complexity that has to be implemented is worth the benefit, because, what does highlighted really mean here? "window is under the mouse" isn't a useful metric, as we don't know if the user is changing desktops or rearranging windows, and "window under mouse" changes depending on the zoom level, "window can be dragged or activated" also isn't a useful metric, as I can do that with any window, anyway. REPOSITORY rKWIN KWin REVISION DETAIL https://phabricator.kde.org/D1209 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: sebas, graesslin Cc: plasma-devel
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
