layer shell meeting notes

[Vlad Zahorodnii]

## Intro

- layer-shell: https://wayland.app/protocols/wlr-layer-shell-unstable-v1
- plasma-shell: https://wayland.app/protocols/kde-plasma-shell
- Was challenging to switch to layer-shell in Qt 5 times, but should be 
doable in Plasma 6 and Qt 6.5+


## DesktopView:

- the simplest case, only need to set the appropriate layer and scope + 
handle popups
- complication: can't move DesktopViews between outputs
   - should be fixable by hiding and showing the view like what 
gtk-layer-shell does


## QtWayland shell integration

- annoying requirement on wayland: plasmashell must be able to use 
**both** xdg-shell and layer-shell
- in Qt 6.5, we introduced QWaylandWindow::setShellIntegration() to 
address that
- popups are still an issue even with the new API, we may need more 
changes in QtWayland
- fork xdg-shell shell integration plugin and add necessary layer-shell 
glue code in meanwhile
- https://invent.kde.org/vladz/plasma-shell-integration


## PanelView:

- similar to DesktopView, except
- need to set exclusive zone, currently it's implicitly computed by kwin 
based on org_kde_plasma_surface::set_panel_behavior
- need to auto hide itself (extract panel-auto hiding from the 
plasma-shell protocol in a new protocol or play with margins?)
- complication: can't move PanelViews between outputs
   - should be fixable, e.g. hide() and show() the view

- panels can be dragged
   - as an option: change the ui to match the technical limits
   - another option: create a fake panel window and drag it around instead

- panel can be configured, currently it creates a second window
   - can be a popup
   - or part of the panel window, just set the exclusive zone accordingly
   - or create a new layer surface that's stacked on top of the panel


## yakuake/krunner

- should be an easy one
- the only blocker is that it depends on PanelView being ported to 
layer-shell; otherwise it will ignore struts

- struts handling:
     - wayland: delegate to layer surface
     - x11: read _NET_WM_STRUT_PARTIAL


## PlasmaCore.Dialog

- used by
- task switcher (as a side panel)
- widget explorer (as a side panel)
- osd (floating)
- notifications (the system tray can "push" them to avoid covering them)
- applets (mostly for overlay content)
- task manager's group dialog
- kickoff, system tray, and other panel popups

- sometimes it's used as a toplevel, sometimes it's used as a popup
- when it's used as a popup, it can be interactively resized, i.e. 
applet popups

- already supports some sort of relative positioning, i.e. 
PlasmaCore.Dialog.location, but we need more to match the layer-shell protoc
ol


## Potential ideas

- Introduce window types representing toplevel or popup roles

- New dialog should use semantic/relative positioning exclusively, i.e. 
no absolute x/y coordinates


## plasma-shell protocol

- open under cursor (klipper thing): what should we do?
    - add a new protocol?
    - implement it as a kwin script?
    - implement it as a virtual keyboard thingy?

- open under cursor is similar to application menu
   - application menu is implemented as an external popup because of 
blocking calls in libdbusmenu

- set role: can be reimplemented using layer surface scopes?


## Potential roadmap

- start with rolling out our own xdg-shell integration plugin
- look into porting desktopview and krunner when Qt 6.5 is released 
(https://wiki.qt.io/Qt_6.5_Release in  April)
- port PanelView to the layer-shell protocol, and the kde-screen-edge-v1 
protocol
- roll out new "shiny" Dialog that can co-exist with the old one
   - we can't port plasmashell to new dialog all at once, it's a too 
monumental task
   - create an issue on invent to discuss the potential new api and 
perhaps have a followup call?
- port plasma one by one to the new Dialog
- once plasmashell has been fully ported to the new dialog, drop the old 
one, and drop plasma-shell protocol support in kwin \o/
- panel shadows should be okay as the org_kde_kwin_shadow protocol is 
agnostic about the surface role, we may consider using client-side drop 
shadows in the future though