mvourlakos added a comment.
In https://phabricator.kde.org/D3355#62804, @mart wrote: > 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. this is true, I have just checked it... >>> - 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? I dont think so but I cant even imagine... so many corner cases that I can not think of... Taking the fact that plasmoids are animated and open other windows also e.g. the compact represation case... >> - 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) > > 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. I can understand the concerns but being honest... I think that this is a lot above my programming expertise and taking the fact how many things must be adjusted by the fact that this is going to be a fake panel above a real panel, it looks enormous and advance for me... Exhausted only to think it... I will probably leave it that way if anyone wants to try any future roadmaps... 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
