| Summary: | Initial panel thickness does not scale with systemwide scale factor on X11 with Plasma scaling | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Felix Miata <mrmazda> |
| Component: | Panel | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aseigo, aspotashev, kde-2011.08, nate, wang.zk |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 6.0 | |
| Sentry Crash Report: | |||
|
Description
Felix Miata
2011-01-18 17:24:33 UTC
pt can be used for calculation, but in the end all values must end up as pixels as that's what is used for geometries on-screen. which means there's very little benefit to using pt as it needs to be later translated to pixels anyways. that said ... i'd be very happy to either accept a patch, or add it myself to the relevant scripts, which implements a variable default panel height based on screen resolution and DPI (it needs to be both, imho, since a high DPI but low resolution probably shouldn't trigger a massive panel). if you would be interested in doing the "fiddle work" of determining which panel sizes work "better" on different resolutions, we could go from there. "there wouldn't need to be a separate configuration branch according to whether desktop or netbook." the difference between these scripts is far more than just how big the panel is. the contents as well as the panel containment plugins used are completely different. (In reply to comment #1) > a high DPI but low resolution probably shouldn't trigger a massive panel Having just overhauled http://fm.no-ip.com/PC/displays.html less than 24 hours ago, I'm having a hard time contemplating any conditions that would cause such a result. Low resolution does not go hand-in-hand with high DPI; it's generally quite the opposite. DPI is a density measure. Resolution is an absolute with limited meaning absent knowing the space in which it fits. Originally I was going to use "initial height should be based upon DPI" as summary, and this highlights why it might have been better. By "total screen height" I mean physically, not measured in pixels, which vary in density according to hardware. Choosing based upon DPI, this request, is about having a nice initial size _regardless_ of hardware configuration. > ...fiddle work... Knowing what I know about fonts, I have to think 28/27 currently specified infers a 23px or 24px icon plus 2px padding each top & bottom for 96 DPI. I would expect satisfactory breaks at 25% increments, or 30+4 covering a 120 DPI range (108-131), 36+4 covering a 144 DPI range (132-153), 42+4 or 42+6 covering a 168 DPI range (154-179), 48+6 or 48+8 covering a 192 DPI range (180-203), etc. > the difference between these scripts is far more than just how big the panel > is. the contents as well as the panel containment plugins used are completely > different. I still think the overall width between desktop and netbook need differ none if this is implemented. Still desirable for v5. The initial thickness is a fixed height for design reasons, but that initial thickness size does scale with the screen scale on Wayland. The fact that it doesn't on X11 with Plasma scaling is a bug. (In reply to Nate Graham from comment #4) > The initial thickness is a fixed height for design reasons, but that initial > thickness size does scale with the screen scale on Wayland. The fact that it > doesn't on X11 with Plasma scaling is a bug. This problem also exists for existing panels when we change the scaling factor of the screen in X11. The height of the existing panel is measured by raw pixels regardless of the scaling factors, resulting in very small panels on the high resolution screen. Yes, that's the bug I mentioned. Plasma scaling is no longer supported in Plasma 6, and this is fixed with Qt scaling, so marking as fixed in Plasma 6. |