https://bugs.kde.org/show_bug.cgi?id=498035
Oswald Buddenhagen <o...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
Resolution|NOT A BUG |---
--- Comment #2 from Oswald Buddenhagen <o...@kde.org> ---
> Also panel de-floats when a window is touching the panel.
uh, yeah, it does (which i didn't notice, because i disabled the floating as
the first thing). what is the justification for such plainly weird behavior?
> And of course you can drag your window over that panel. You don't lose any
> window content in this case.
no, i can't. that would be "windows can cover" mode, which was intentionally
removed with a rather poor justification.
in fact, it behaves like "windows go below", which is the central point of this
report.
maybe you should rename the mode, for example "make windows dodge" to contrast
it with "dodge windows". i think i've seen it named "exclude windows"
somewhere, but that's an equally bad name, as it can be understood only once
one already knows what it does.
but even then it's still not clear why dragged windows don't actually respect
the border and just slide under the panel. i thought that this might be the
effect of a kwin setting, but that doesn't appear to be the case.
so at the very least the combos should have tooltips which explain the full set
of behaviors and what external influences exist.
and why does "windows go below" also apply to maximization? there is no
sensible use case for such behavior (as opposed to manually sliding part of the
window below the panel). either the panel or the window should dodge (probably
the latter).
--
You are receiving this mail because:
You are watching all bug changes.
