Working to solve multi-monitor pain-points.
There are really quite a lot of components that intersect the behavior here which are currently working together a little less than ideal. Some ideas from issue 24 are too valuable to just lose.
there is a "Window Placement" combobox on the "Window Behavior" KCM. Directly under it is the checkbox "Allow apps to remember position", something that would be fine for a VERY small number of apps (music players, chat windows) but is extremely counter productive for apps like dolphin or konsole.
For two screens this gets worse, as you can't assume that both screens have the same width and height. For instance I prefer one screen to be 90 degrees rotated.
For two screens setup most people have a certain workflow. A second screen is never simply more screen real-estate. This is especially true for laptop users as the external screen tends to be bigger. What all this means it that the current KDE assumption that the screens are simply interchangeable is wrong. The idea that an application opens based on where the cursor is is in many cases counter productive and makes for a very nervous user (move the cursor quickly!). Especially those that use the keyboard to start apps.
It used to be so (a couple of years back) that starting an application on virtual desktop one, and before the window is open moving to virtual desktop 3 will still open the window on VD1. The same as the above point of deciding which screen to open on based on the cursor position is training people to wait for their computer in order to avoid more window management tasks. Both of those could be fixed with some simple suggestions at the bottom of this long post.
Second point; multi screen plasma configs
first of all, this is known to be buggy. No hard feelings, just realize that people complaining about creating a nice setup may simply be hitting bugs and the UX is blamed instead.
Each screen has a containment, each containment is assigned to a specific monitor. In an ideal non-buggy world, a user can know for sure that the containment she calls "primary" is always going to be visible. Which has the nice effect that it makes it possible for a user to make the external screen the one with the taskbar and start menu, but after unplugging that screen those move to the laptop screen.
As Nate pointed out, this does mean that if a user manually moves all those core panels to the non-primary screen they could be left with a surprise after unplugging. I don't see that as needing any magic behavior on the side of Plasma, afterall the user (in a world where container-to-monitor assignment works much better than today) can simply adjust his setup for this and have another start menu.
With regards to the suggestion of having one panel on both screens, I believe that altering the plasma config is so rare that a simple "duplicate panel" feature would be enough to satisfy those users without making the positioning logic more complex. Having a single panel that shows on two screens via some setting doesn't sound like the way to go, different resolutions and similar changes typically make users want to change one anyway.
Suggestions (conclusions, arguments above!);
- make primary screen mean two things:
- open new application windows on this screen.
- make this screen have the primary containment.
- re-instate the feature that start menus tell the runner which desktop they were on when starting an app and make kwin place it on that desktop.
- remove from the KDE setup the default that apps save their position and make apps do this explicitly in code. Making clear that from a UX perspective which apps benefit (most don't).
- Add 'duplicate panel' option somehow. My first thinking is that on a setup with more than one screen the "add panel" has a feature allows selecting an existing next to the default two options today.
- a containment that is marked "primary" will move to the "primary" monitor. I expect a series of monitor-setups to be saved and each to have a "primary".
- plasma container to monitor assignment is in need of a fix. I suggest to save for the currently seen hardware a series of features. From serial ID to resolution and naturally monitor brand etc. Then next time plasma wants to find out where to place a containment it first looks for the serial number and if that fails it can try to match other properties.
Notice that the goal is not to never assign a containment to the wrong screen, as that would constitute as loss-of-data, instead it is to come closest to ideal. So for instance if your second monitor has 1080p and your config says its a different screen but the resolution is the same then by all means match that containment and show the users configured desktop there.