mart added a comment.
In https://phabricator.kde.org/D3355#62769, @mvourlakos wrote: > In https://phabricator.kde.org/D3355#62728, @mart wrote: > > > another thing, even if the input mask is correct, it would still not work correctly: both window maximizing and snapping would go to the real geometry of the window, making the "trick" obvious. window maximization could be fixed by setting different struts, but that would *not* work on wayland. > > > Isnt possible for kwin to take into account the mask used in the panel in order to provide correct maximizing and snapping? as far i know, no > One more point, the issue for the maximizing and snapping refers only to "Always Visible" panel state, the other three states "Windows can Cover, Autohide etc." do not have any issue... Most of my dock users do not use at all "Always Visible" state... Most of them use "Below Active" state which is not supported yet (I was hoping that I will make a patch for this in the future) and they live happilly with "Windows Can Cover". windows can cover have problem with snapping as well. >> - now it can animate and zoom where it wants, anywhere in the screen >> - when the cursor goes away the icons area, the icons animate to small again, then gets reparented to the real panel again, the second window gets hidden again > > I am not that sure about the above... > > - how fast can all this be in order to catch up and not create glitches? I don't know: only way would be trying it (preferably with a small test case before going full scale) on plasma mobile seems to work quite well. (worst case scenario this external window would be always visible? > - how from my qml container will be able to disable blur and contrast effects for this window and how this window will know the x,y coordinates of the panel(dock) in the screen? probably you would have to write your own c++ part that would register a c++ based qquickwindow subclass that would do all you need to make the thing seamless enough (if your c++ implementation has pointers to the object you need to reparent and its normal parent, then tracking the real panel geometry is easy) > So, do you have concluded that this patch isnt going to be accepted in Plasma? the thing is: in itself kindof makes sense, but i think that following this approach is technically impossible to arrive to something that works well enough, since there is no way to make the window manager to play well enough with windows with a "fake" size. I think a different way should be tried beforehand. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D3355 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mvourlakos, #plasma, davidedmundson Cc: mart, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
