I like the idea, needs a bit of thinking to work on wayland

btw, this was ignored for a long time as there weren't reviewers specified

Sorry for the delay.

In Wayland there seems to be a problem with QScreen: creating a panel on the second screen crashes plasmashell in QScreen::size(), called by PanelView::panelConfig() (shell/panelview.cpp:130).

In D10344#297751, @hoffmannrobert wrote:

In Wayland there seems to be a problem with QScreen: creating a panel on the second screen crashes plasmashell in QScreen::size(), called by PanelView::panelConfig() (shell/panelview.cpp:130).

While debugging a crash which occured when creating a panel on the second screen, I found that in certain screen/graphics hardware configurations (e.g. two screens connected to integrated Intel graphics controller, no screens connected to ext. Nvidia graphics controller) there are screen numbers like 3 or 4. This cannot work, because QGuiApplication::screens() is a QList and Panel:panelConfig() wants to do QScreen *s = QGuiApplication::screens().at(screenNum):

In Panel::panelConfig():
int screenNum = qMax(screen(), 0); // screenNum is 4 here

if (QGuiApplication::screens().size() < screenNum) { // 2 < 4

return KConfigGroup();      // returns empty KConfigGroup --> Crash in Panel::setHeight()

}

This happens in X11 and in Wayland.

Still looking where these screen numbers come from...

In D10344#299042, @hoffmannrobert wrote:

In D10344#297751, @hoffmannrobert wrote:

Still looking where these screen numbers come from...

working in Latte I had to understand how Plasma is working with screens, it might help you to understand it...

There is a plasma-workspace/app/screenpool.h class which is responsible for the ids you are mentioning.
This class keeps a record and creates a table in form:
ScreenName=id (e.g. 1,2,3,4, ... etc.)

That table can be found at ~/.config/plasmashellrc e.g.:

[ScreenConnectors]
0=HDMI-1
1=eDP-1
2=eDP-1-unknown
3=eDP-1-1
4=:0.0
5=Screen26
6=Screen36

screenpool class is responsible to maintain that table and also to inform applets, containments, coronas etc for
associations between ids and screens

the Corona class has a screenForContainment() function that helps at that communication between applets<->screens

screen() and lastScreen() : functions usually return the id of the screen based on ScreenConnectors

Thank you. If these non-consecutive screen numbers are legitimate, then getting the QScreen via QGuiApplication::screens().at(screenNum) is wrong. I found a solution using ShellCorona::m_desktopViewforId.

In D10344#299287, @hoffmannrobert wrote:

Thank you. If these non-consecutive screen numbers are legitimate, then getting the QScreen via QGuiApplication::screens().at(screenNum) is wrong. I found a solution using ShellCorona::m_desktopViewforId.

yes, QGuiApplication::screens().at(screenNum) doesnt make sense in plasma environment