| Summary: | Provide a way to enlarge the visual appearance of the hole workspace and the applications | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Lukas Sommer <sommerluk> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | cfeck, cputtick, lukas.schneiderbauer, mrmazda, robertmuil, sommerluk |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | 133936, 190489, 273936 | ||
| Bug Blocks: | |||
|
Description
Lukas Sommer
2011-05-02 19:21:32 UTC
> With the given resolution it is impossible to read the text and recognize the icons at the given distance.
The problem is that font sizes (and icon sizes, using the "right" style, such as Skulpture) are DPI sensitive. If you are using a HDTV or projected screen, setting the DPI values to actual/real values does not make sense, as the text would appear as small as with a normal display (in terms of millimeters/inches, not in term of pixels).
It is suggested to set your DPI values in a way that "usual" font sizes (such as 10pt) map to an actual pixel size comfortable to reading. Depending on what the video driver or X server reports for the screen dimension, it could be actual values, or "virtual" values.
To clarify further: The "scale" factor you mentioned should directly control what the display server reports as the DPI value. In other words, it would probably have to be supported downstream. Having another (KDE-specific) value would only result in a mess with some applications having big text and some not. If I basically understand you, this feature has to be implemented mainly in the widget styles. So the widget style should be completely DPI sensitive (and therefore resolution independent). Not only font sizes (and icon sizes) should be DPI sensitive, but also all UI elements like check boxes, radio buttons, default margins, scroll bars... This would make work out of the box all applications that don't use hardcoded pixel sizes (and that use this DPI aware widget style). After this, it will be necessary to do some downstream fixes for hardcoded pixel sizes. Settings like the size of scroll bars in Oxygen or the size of the shadow effect in the composite manager should not be pixel values but "scale factors" that are DPI sensitive. For example using "100%" for the default value, and the percent value can than be incremented and decremented. And finally we would have to scale the cursor theme. Is this correct? I've opened an openSUSE build service project that provides skulture (and also the plasma theme Atelier) as binary packages for some distributions: http://download.opensuse.org/repositories/home:/sommerluk:/skulpture/ The X display server provides two different DPI values: One for the "display resolution" and another one for the "font resolution". I've noticed that Skulpture scales according to the "font resolution". Which of the two values should be mandatory? In the case that the font value is mandatory, it would be sufficient to enhance the font module in systemsettings to provide the scale factor that this bug is requesting. (Currently the module only provides "Unchanged", "96 dpi" and "120 dpi") Spinn-off bugs: Bug 272790 - Make Oxygen style (and window decoration) fully scalable Bug 272792 - Font DPI isn't fully scalable Spinn-off bugs: Bug 273723 - KConfigDialog::addPage() requires hardcoded icon sizes Spinn-off bugs: Bug 273936 - The Oxygen cursor themes aren't scalable Bug 190489 - General DPI setting should work and should be more configurable Bug 273938 - Get rid of hardcoded icon sizes You can add those bug numbers to "Depends on" field instead of adding a comment for each. This automatically creates a "Blocks on 272266" in those bugs, so you don't have to add a comment for the "backlink" on each of them. > You can add those bug numbers to "Depends on" field
Thanks for the advice. However, I didn't figure out how to do this. Maybe because I don't have the corresponding rights?
273936, 190489, 273938, 272790 *** Bug 329518 has been marked as a duplicate of this bug. *** Not convinced this is a direct duplicate of the bug posted by myself. If it is then for sure it should be marked as a much higher priority because it's not receiving much love as it is, despite it causing significant usability issues approaching non-functionality. FYI 133936 (hard coded systray icons) is a blocker for this (duplicate or not) NB since this bug was created the resolution issue has moved to normal use, with multiple laptops on the market with DPI at 235 and screen resolutions of QHD+ (3200x1800). > it's not receiving much love
If you read the comments, you will see that a many issues have been addressed already. For "more love", provide patches.
Don't go there. Surely there are not many people left who believe that the only contribution of value to an open source project is code. I can test, I can design, I can't code. I can also provide an excellent perspective on what should take priority in terms of general development; in this case, being a GUI, bugs regarding how the product looks on all targeted displays, large, small, high resolution and low resolution, should be seen as a "Grave" issue and development prioritised. > I can also provide an excellent perspective on what should take priority in terms of general development That's a nice way to put it. We all have our vision of a perfect system. But the simple truth is, that software needs to be written, and if there is nobody willing to do it, no "perspective" will ever help. For further discussion, please use http://forum.kde.org/ Note that DPI amounts to a knob one can turn to scale the whole desktop regardless of DE used. Those using proprietary NVidia drivers can set DPI directly in xorg.conf. Those using other video drivers can do it indirectly in xorg.conf* using DisplaySize. Example resolution and display dimension combinations with their DPI equivalents for those not wishing to do the math required to achieve any particular DPI can be found in http://fm.no-ip.com/Share/DisplaySize . *** This bug has been confirmed by popular vote. *** There is now an option available: System Settings → Display & Monitor → Global scaling That seems to work quite well… Removing “Bug 272790 - Make Oxygen style (and window decoration) fully scalable” from dependency list. Oxygen is not default widget style, so this is not a blocker. Removing “Bug 273938 - Get rid of hardcoded icon sizes” from dependency list. While icons are still pixel, and not vector graphics, the global scaling works nevertheless (though not as nice as it could with vector graphics). Closing as RESOLVED FIXED. |