Version: (using KDE 4.2.0) Installed from: SuSE RPMs If you use two monitors with plasma, each monitor is assigned its own activity. This, as I understand it, is intentional behavior and is a good way of doing things in my opinion. The problem arises when you use two monitors with different resolutions. This leads to problems when you switch activities between the two monitors, especially using the activity bar plasmoid. The activities end up the correct size for the new monitor, but the plasmoids in that activity do not change size so you can end up with big empty spaces devoid of plasmoids and/or plasmoids extending off the edge of the screen. Steps to reproduce: 1. Set up two monitors with different resolutions. Have plasmoids on both that extend to near the edges of the monitors. 2. Use the activity bar to switch the activities on the two monitors. If you only have the default pair of activities, switching the activity on one monitor will also change the activity on the other since you apparently can't have two instances of the same activity. What I end up with is a big empty space with no plasmoids on the larger monitor and plasmoids going off the edge of the screen in the smaller monitor. The activities themselves, including the wallpaper, resize properly, but the plasmoids on those activities maintain their original sizes. I think the ideal solution would be that if an activity's resolution changes, it scales the plasmoids so they stay the same size relative to the activity, rather than the same number of pixels. So a plasmoid that is 25% the height of the activity and is position 50% of the way down the activity will remain 25% the height of the activity and 50% of the way down no matter how big or small the activity becomes. This would require people with multiple monitors to have an activity bar for each monitor, but that is a good thing since the activities can be moved between monitors easily. It also will allow things to end up correct if you get a new monitor with much less work on your part. A less flexible but perhaps easier solution is for the activities to know what their appropriate resolution is and only appear on monitors that can display them properly. This would also require the activity bar to only display those activities that would actually work on the monitor the activity bar is on. It would also require an activity bar per monitor. A third solution would be for activities on the two monitors, although separate, to be tied together, so that changing one would automatically change the other. That way there is no way to have activities on the wrong monitor, and would only require one activity bar. It would be less flexible, however, since you could not change the activities on the two monitors independently. I would say this is the worst solution, since it has less flexibility but not additional benefit over the other two and is probably not an easier to program, either (it may even be harder).
I'm still have this problem in 4.3.2 and 4.4 trunk. It makes it very hard to use activities, which is a shame because the desktop mouse control system in 4.4 makes switching activities a lot easier.
This is still a problem in KDE 4.4 final and KDE 4.4.1. It might be helpful if I add some specific use-cases were this is a significant issue. I also have some more thoughts on fixes. Most often I would say this is a problem for laptop users. There are two specific issues that make this a problem. First, laptop users do not have as much flexibility with monitors. They have one fixed screen whose resolution they can not really change. So unlike desktop users who can just buy two screens of the same resolution, laptop users often do not have the freedom to match their screen resolutions. This can be a problem for desktop users as well, though, if the two monitors were not bought at the same time, if there is limited desk space or money available, or if they were scrounged up from stuff laying around an office, for instance. Whatever the reason, having two monitors with different resolutions makes it difficult, if not impossible, to use activities to any significant degree. At the very least it makes mouse and keyboard shortcuts for activity switching completely useless, since you will inevitably end up with the wrong-resolution activity as you try to cycle through them. For the activity bar, you either have to memorize which activity goes to which screen or label them. With the ZUI, when you zoom back in you can't predict which activity will end up on the second monitor, also leading to the wrong-sized activity often. An even more common issue, though, is using laptops with projectors. Projectors have widely-varying resolutions, so any activity set on one projector will most likely be completely messed-up on another. Anyone who uses a laptop with a modern external monitor will almost certainly have the wrong-sized activity for most projectors, modern or older, leading to a terrible-looking desktop the moment they plug in the projector. This is a similar issue for someone who has a laptop with external monitors both at home and at work, chances are they will be different sizes, resulting in activities that only work in one of the two locations. But it is probably a much more common issue with projectors. I listed three solutions initially. One is to have the activities automatically re-scale applets for the current monitor's resolution. The second is for activities to only appear on screens with the same resolution for which they were originally set up. The third is for activities to be grouped, so certain activities on one monitor will always appear with certain activities on a different monitor. On further consideration, the third option will not actually solve many of the problems described here and will make some new problems, and the second has some serious limitations. I now really think the first option is the only effective solution to this problem. The problem with the third option is it only works if you always have the same monitors. If you are moving between monitors at home and at work, or trying to use a projector, you still have the problem I described. What is worse, the relative position of the monitors could change, resulting in you having the activity that was on the laptop's internal screen ending up on an external screen. For instance your monitor at home could be on the left, but your monitor at work is on the right, meaning you would be stuck with the wrong-sized activity half the time no matter what you do. This is worse for projectors, where the projector and podium often have a fixed location so you have no real control over where your monitors are. The problem with the second option is that you would end up with a large number of activities for a bunch of different screen resolutions. Every time you plug your laptop into a projector with a different resolution you would get a new activity. What is more, you would always get a blank activity, which I think is a fairly ugly solution. So I think the first option, automatically re-scaling activities, is the best. I have thought about the implementation and have what I think might be a workable solution, although I know next to nothing about plasma so this may be a terrible idea. The idea is as follows. Currently plasma already stores the size of each activity in plasma-desktop-appletsrc. I assume this is used to get the activity background to re-scale properly on different screen sizes. The idea is that whenever you change activities on a particular screen, plasma compares the actual screen size to the stored size in plasma-desktop-appletsrc. If these match, it does nothing. If these do not match, it re-scales all applets to the new screen size. The settings in plasma-desktop-appletsrc do NOT change, all of the resolutions are kept relative to the stored activity size. Any change in the size of an applet would be re-scaled to match up with the original activity size and would be stored in that manner. If the applets can scale in the two dimensions independently, then they will re-scale so their relative position and size stays the same (rounded to the nearest pixel, if necessary). So if you make a 200x100 applet in a 1680x1050 monitor, and it ends up in a 1024x768 monitor, it gets the size of 122x73. If the applets keep the same aspect ratio, then the center of the applet would keep the same relative position in the activity. To choose which dimension would be used for the scaling, the dimension that would result in the applet being the smallest would be the one that changes. If you went with the larger one, you could end up with applets covering applets where you don't want them to. If you go with the smaller one at the very least you will not have any more overlapping applets then you did before, although you might have less overlapping applets. I think having applets that originally overlapped but don't anymore is less likely to result in problems than applets that did not overlap originally but do now. So using the previous example, if you make a 200x100 applet in a 1680x1050 monitor, and it ends up in a 1024x768 monitor, it gets the size of 122x61 to maintain a 2:1 aspect ratio (as opposed to 146x73, which would be larger). I think this approach would be most likely to result in a usable, consistent, good-looking activity in the most possible cases.
Hello! This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable. Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham