Version: (using KDE 4.1.0) Installed from: SuSE RPMs OS: Linux If one has a panel of ~200 pixel at the right edge of the desktop, the tasks and clock etc. look really nice. One cannot yet use it, since windows cannot overlap it and it wastes too much space, but time will tell. However, both the kickoff-launcher and the solid-notifier use the full width of the panel, although they only need a width of their icon-size. As a result a lot of vertical space is wasted. Expected behaviour, arrange icon plasmoids next to each other and make better use of the horizontal space in a vertical panel's row.
I would add that using wide vertical panels will happen more and more often, as 16:10 monitors become the standard. As vertical space becomes precious, one cannnot afford horizontal panels wasting it, thus one would use vertical panels instead. And as their length is shorter, they would need more width to compensate. Of course, that only makes sense if there is a way to use the width efficiently (for instance by allowing several icons on a line, and definitely not with wasteful 200 pixel high icons!).
sorry to reask, but just to be sure; if a panel is vertical you like to be able to e.g. put the kickoff-icon and the device-icon side-by-side horicontal to waste less vertical space. So, all in all, there should be n vertical columns for the items, right?
Columns sounds like a fixed size, which would not be optimal. It should be like a text that wraps the line if the item does not fit anymore. So if you have a panel of 100 Pixel and two plasmoids with 40 and one with 20px width, they would all fit into the same row. Alternatively one could stick to rows, i.e. if the user places three icons with a width of 48pixel into one line, the last one is partly invisble, but that's the user's fault. He could simply drag it into the next line. The advantage of the first approach is that is is more flexible and adapts to the panel size if it changed. The problem is that the user might want to only have one icon in the first row and needs to add a spacer after it to make the next icon move into the next line. The advantage of the second approach is that it does exactly what the user wanted, i.e. does not change any positions automatically. The disadvantage is that if the user might resize the panel and thereby hide a plasmoid completely. The basis of all this is of course that applets only take the horizontal space they need, i.e. an icon only demands and gets only 48x48pixel.
Here is a screenshot to show how much space is wasted. If you have a look at the icons, the should be placed next to each other, since it does not make sense to use the full horizontal width. For the other plasmoids, like the taskbar, it does obviously make sense to use the whole width.
Created attachment 30932 [details] screenshot
A quick search gave me 6 copies of this bug, but I can't mark them as duplicates. It seems a lot of people have this problem. Duplicates: bug 173949, bug 182193, bug 183519, bug 167132, bug 187767
Bug 173949: Many bugs in one, marked as dupe of Bug 193015. Bug 182193: Requests that individual widget sizes be configurable. This is a dupe of that bug, marking as such. Bug 183519: Complains that button size is not variable, it's a dupe or been duped by me, I will look for it and mark one as such. Bug 167132: Complains that some plasmoids are specifically too big. Not a dupe. Bug 187767: Dupe of Bug 182193.
*** Bug 183519 has been marked as a duplicate of this bug. ***
This is fixed in trunk and probably even 4.3 or before
Not completely fixed: some plasmoids, like the battery applet still have the old behavior (using all the width with proportional resizing). Moreover, icon plasmoids, like the K menu and the new peripherals icon, sure do not resize anymore above some threshold, but do not either change their layout so that they are organized in columns (or some more advanced layout, as suggested by the opener). At least this is as I describe in 4.3. Are those other aspects fixed in trunk? If not, please reopen!
I'm using 4.3.1 and this definitely isn't fixed here. Just checking, you are talking about what this report is actually about, or did you misread the original post, and think that this was the problem "since windows cannot overlap it and it wastes too much space". That's the only way, that I can think of, that you'd think this was solved so early... If it is indeed fixed in trunk, then awesome, I've been waiting a while for this, and there are a whole lot of other bugs that are probably solved by the same solution.
ok, i'm doing a huge amount of bug triaging right now, but a quick test in trunk showed me that it should work (but could be that i misread the post). So i open again, and if somebody can test with trunk, would be great
Might bug #165792 be solution to this issue?
That's exactly the kind of solution I've been looking for. Obviously I can't speak for everyone else here, but I'd be very happy if that was implemented.
> Obviously I can't speak for everyone else here, but I'd > be very happy if that was implemented. Yes, so would I. It looks like this issue may even be a dupe, if one considers the terminology changes for vertical and horizontal panels. What sayth the OP?
If the "solution" is to have two vertical panels instead of a wider one it's not a duplicate. Widgets like the analogue clock or a post-it etc. should be able to use the whole width while simple icons including things like the device-notifier should arrange themselves next to each other. If one had two panels every widget could only use half the width.
> Widgets like the analogue clock or a post-it etc. should be able to use the > whole width while simple icons including things like the device-notifier should > arrange themselves next to each other. Thank, Burmeister, I mentioned that on bug #165792.
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