1

Hello folks

I really love KDE. But my experience is plagued by the multi-monitor wearisome behavior.
There are numerous reports of issues involving multi-monitor setup after resuming from powersave mode, disconnecting and reconnecting a monitor, rebooting, etc.
This amount of bugs might be an indicator of a design challenge. Its underlying complexity might not have met the endeavors it requires, which is highly understandable for a free and open-source project.

In this working draft, I want to share my perspective and ideas about these issues and how they might be addressed. I am not part of KDE team, and am very welcoming to any criticism and suggestions, especially from KDE contributors. Also, English is not my native language! Please feel welcome to find replacements for words I have picked and definitions I have offered.

Because I am more familiar with markdown, I have posted the draft on reddit. Feel free to comment here or on Reddit. I will edit and version it as I dig deeper into the issue and gather more feedback.

>I am not part of KDE team,

Something worth fixing!
Clearly you have a lot of thoughts, and plenty of drive. Happy to have you participate.
We also started by addressing things we think suck in programs we use.

In terms of moving forward I would really encourage you to read over the current code, and not just link to a general category of bugzilla, but be the guy on top of that section. I tend to know if someone has read the reports because there'd be some activity reporting what things are dupes and/or not relevant

All proposals that I've seen go anywhere tend to be in the format. "we do X, this fails because of Y, therefore....", rather than opening with "we should do Z" - and not try and take on 10 different issues at once.

Addressing your proposal:

>End-user can populate a virtual screen with panes and widgets. During this process, plasmashell MUST emulate the minimal resolution.

Currently initial population is handled by a user-swappable JS script, it has access to your actual resolution at the time of first run.

In your report there's a lot of focus on the config file. This isn't too relevant. Ultimately this gets loaded once, and stored into a different format in the code. We don't really have any issues with deserialising - but tackling what we do with that information.

You're right that it's a difficult area to get right.

There are a lot of places where it's hard to say what is the correct course of action. Plugging into a projector is a wholly different experience to plugging into your own personal second display at home. Swapping laptop and monitor positions shouldn't swap the panels in some situations, sometimes it should.

Yet equally we don't want to overburn panel placement with a mandatory form about how this panel should react to future changes.

---

If I read you correctly the main point is that you're effectively suggesting an extra layer of indirection between the monitor containments are assigned and the actual monitor ID. Right?


>Make the coordinate relative to the closest edge. Since the virtual screen is guaranteed to meet the minimal resolution, the layout will remain resilient to resolution changes.

Heh, there's a branch that does that already.