Created attachment 87293 [details] some expandable being shown, depicting how there's invisible things in the sides (I am talking about that blue line on top of the plasmoids) In the taskmanager the line is grayed when the window is not selected, but plasmoids don't show anything when they don't have the dialog on. Instead, they leave an empty space both in the screens and in our hearts, which makes us things are not properly aligned vertically.
Is the highlight a frame svg? Maybe the top and bottom margin hints are different?
nah, if every icon would have a piece of line it would look very, very cluttered, i don't think this is valid, semantically is more near to the kickoff tabbar. I don't think this is valid. for tasks iirc the idea was to distinguish between normal and iconified windows, and makes the taskbar looks quite busy, but in that case it's justified
Andrew: it's a framesvg, but the plasmoid icons don't use its margins, they always vertically center the cntent, no matter what. (so any feeling of not alignment again is not actually real, but due to maybe different center of gravity in icons or something like that)
Ahh got it thanks Marco. Then any remaining geometrical vertical alignment issues would come from the panel top margin not from the highlight and would apply to everything in the panel. Agreed though that, adding another kind of line is probably the best solution visually.
Maybe we can make a mockup and see how it looks?
Correction: Agreed though that adding another line is probably NOT the best solution visually. That was a typo, sorry. The remaining vertical alignment offset due the panel top margin is, as far as I know, something that's been there since Plasma current. The current highlight line for selected popup plasmoids probably just makes it more perceptible. While it's not pixel perfect alignment, given years of validation in plasma current, I don't think it's something we critically need to address. Separately, I think we can come up with a improved way of showing the selected popup plasmoid. I have a couple ideas that might work and that wouldn't require a massive overhaul. I'll post something shortly.
we could try to remove the top border altogether (or make it one-two pixels) it may look cramped, or maybe not...
(In reply to comment #6) > Correction: Agreed though that adding another line is probably NOT the best > solution visually. That was a typo, sorry. > Maybe you could make a mockup and see? > The remaining vertical alignment offset due the panel top margin is, as far > as I know, something that's been there since Plasma current. The current > highlight line for selected popup plasmoids probably just makes it more > perceptible. While it's not pixel perfect alignment, given years of > validation in plasma current, I don't think it's something we critically > need to address. > In KDE4 times the alignment error was substantially less. I'll attach a screenshot to show what I mean. It may not be correct to infer that because the alignment was off in KDE4 times, if we make it worse in Plasma5, no one will care. They were (probably) fine with it because it was very minor. It no longer is. > Separately, I think we can come up with a improved way of showing the > selected popup plasmoid. I have a couple ideas that might work and that > wouldn't require a massive overhaul. I'll post something shortly. Great. I look forward to solving this before plasma 5.0 is released.
Created attachment 87310 [details] Plasma 4 vs Plasma 5
Vishesh, I can help you make a mockup of your proposal. It should be simple enough that we don't need to make Andrew do it.
(In reply to comment #8) > In KDE4 times the alignment error was substantially less. I'll attach a > screenshot to show what I mean. It may not be correct to infer that because > the alignment was off in KDE4 times, if we make it worse in Plasma5, no one > will care. For clarity, my intention was to suggest that the mechanism driving the remaining alignment error- the panel padding - is the same as it was before. We can reduce the panel padding in the theme to reduce the perceived alignment error, but then we'll return to visuals that appear cramped with no breathing room. The other perhaps more visually correct solution might be to apply the hinted panel padding to the bottom edge to vertically center the content even though the bottom border isn't showing. But I'm thinking that solution would need to account for the potentially reduced FItt's affordance for the panel applets at the screen edges. Visually, yes, I think it should be properly vertically aligned. I won't speak to the implementation challenge to get there but, for the moment, the remaining alignment issue is looking like a collection of trade-offs to me. If I were forced to choose between cramped visuals that come from reducing the padding and the remaining vertical alignment issues for the 5.0 release, I'd rather live with the remaining vertical alignment issue and try come up with a better way of showing selected popup plasmoids (working on it).
Hmm, I was mocking up a simple highlight dot/circle (instead of a line) for the popup plasmoids. I think it would work well, but then I have no idea how to accomplish it using a framesvg. Do we have any options from the implementation side to accomplish something like this?
"Hmm, I was mocking up a simple highlight dot/circle (instead of a line) for the popup plasmoids. I think it would work well, but then I have no idea how to accomplish it using a framesvg. Do we have any options from the implementation side to accomplish something like this?" if is a simple circle either a simple svg or a rectangle element rounded at the point to become a circle
Created attachment 87349 [details] plasmoid highlight dot Would a dot above the plasmoid like shown in the attachment be possible?
i kinda liked the line, aligned to the taskbar one, but yeah a dot would be possible. could be done either as a new theme element or as hardcoded in qml (not sure how to be 100% sure to give it the same height of the taskbar line in all possible dpi sizes in case it's done just in qml)
yeah, the line wasn't too bad. But I'm starting to realize that the highlight line may be providing a little too much visual information; it'd drawing a little too much attention to the bounds of the icon and sets up lots of unnecessary visual reference points that don't really have any credible information value beyond what icons themselves (with their padding) already communicate. I think this kind of visual information is more useful for the task bar where task entry titles be shorter since the line communicates the interactive bounds of each task entry. I'm hoping the dot will do a decent job of communicating which item is selected/active using the common language of color while avoiding the mentioned downsides of the line. I don't have any preference for how it's implemented, as long as there are no essential objections to this visual approach. Just let me know what I can do to help get it in place.
one place where it wouldn't work is probably the systray in two cases: when the whole systray is open but there isn't a sub-applet open (in this case either it completely loses the indicator or the indicator goes only on the arrow) and when an applet inside the systray is open: in this case it was designed to look exactly like the tabbars, because it's exactly what the interaction paradigm is (a dot could be put there, but probably at the little line of separation would have to be removed) probably all of this can be adjusted enough, quite some code changes in the systray tough now that we are very near to release.
Yeah, too many code changes this close to release, I'm fine if we leave this as it is currently. From the visual side, the ideal solution would be simply to change the icon color to the highlight color, which if I read elsewhere correctly might be a possibility after 5.0. I say we take the time to find the right solution and address after the 5.0 release.
"the ideal solution would be simply to change the icon color to the highlight color," that assuming there is a themed and monochrome icon for everything, it would break for icons that come from the "normal" theme and if a theme decides to offer its own colored svg icons
(In reply to comment #19) > "the ideal solution would be simply to change the icon color to the > highlight color," > that assuming there is a themed and monochrome icon for everything, it would > break for icons that come from the "normal" theme and if a theme decides to > offer its own colored svg icons That's why I called it "ideal". :-) Although I should probably have qualified it by saying "ideal visual solution". Another "ideal": bubble pointers. Eek. I can keep throwing out ideas that may or may not work given the underlying implementation, but I'll quit since it's probably no longer helpful at this point. :-)
what i would try to do is the circle, will do some experiments, probably to delay after 5.0, but if by chance it works, will be good
This bug seems not relevant for current releases Plasma: 5.12.1 Apps: 17.12.2 Frameworks: 5.43.0 Qt: 5.10.1 Kernel: 4.14.20-2-MANJARO OS: Netrunner Rolling
This is no longer an issue today.