Protocol for external dock/panel apps to publish their geometries to Plasma
Open, Needs TriagePublic

Description

As discussed at D15702 and https://bugs.kde.org/show_bug.cgi?id=391073 there is currently no way for Plasma to know the geometries of docks and panels that live outside plasmashell. As a solution a protocol is discussed here in order for plasmashell and external processes to solve this issue.

Acronyms:
*P -> PlasmaShell
*L -> Latte dock or any external app that will support the protocol

Must be considered:

  • A. The communication is going to be taken place through dbus or in other way?
  • B. How the geometries are going to be published from *L to *P?
    • B'1. *L publishes all geometries and their updates at the same time, e.g. if Latte is showing 2 docks and 1 panel then each time it communicates with *P it sends all three geometries even if some of them do not have any changes
    • B'2. *L publishes for each dock or panel its geometry separately and that means that sends updates to *P only when there are any changes
  • C. What happens if *L crashes unexpectedly? shouldnt *P drop all relevant *L geometries?
  • D. How is this going to be multi-screen aware? are the panel/dock geometries enough for this?

Proposal [B'1]: Has the benefit that *P will identify all panel/docks based on the app they come from
Proposal [B'2]: For each dock/panel of each *L an id should be probably shared between *P and *L in order for updates/removals etc. to be tracked down.

I would love to hear your ideas in case I could present something for this.

PS. Latte currently supports panel/docks that live under different Activities my proposal is to not make the protocol activity-aware. If Latte updates the geometries that is sending to *P based on the current Activity I dont think there would be any problem.

A. The communication is going to be taken place through dbus or in other way?

Generally, I love DBus for everything, but given we have struts we can use the same serialisation with a subtly different property name. It has the advantage of clearing when the client dies - has the multi screen issue on X if placed between monitors.

One thing I want to make sure of is that we share the same code paths for plasma panels and external panels, even if it means a bigger more invasive patch, it'll be less code overall.

trmdi added a subscriber: trmdi.Apr 8 2019, 10:06 AM

@mvourlakos

KRunner (Alt+F2) can somehow know about Latte and displays below Latte. Can you apply what Krunner does to the Folder plugin?

@mvourlakos

KRunner (Alt+F2) can somehow know about Latte and displays below Latte. Can you apply what Krunner does to the Folder plugin?

KRunner is just using the struts infrastructure and its approach under wayland environment breaks.
Only what @davidedmundson has proposed is a good approach for this but personally this period I dont have neither interest nore time to play with this...
Until something changes in that front the only feasible solution is D15702.