Bug 272266 - Provide a way to enlarge the visual appearance of the hole workspace and the applications
Summary: Provide a way to enlarge the visual appearance of the hole workspace and the ...
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Unspecified
: NOR wishlist with 102 votes (vote)
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 329518 (view as bug list)
Depends on: 133936 190489 273936
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-02 19:21 UTC by Lukas Sommer
Modified: 2020-08-23 12:19 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Sommer 2011-05-02 19:21:32 UTC
Version:           unspecified (using Devel) 
OS:                unspecified

Use case:

You want to use KDE on your plasma television which is quite big (let's say 42 inch) and has a high resolution (let's say 1920x1080). You want to sit quite a distance away (let's say 6 meters).



Reproducible: Always


Actual Results:  
With the given resolution it is impossible to read the text and recognize the icons at the given distance.

Expected Results:  
There is an option in the system preferences that lets you set something like a representation factor. So you can put this to 2,0 or 2,5 and you see everything bigger.

This issue is about to display the applications and the workspace at a higher resolution. It's not about using applications like a magnifying glass. It's about the possibility that the applications work themself at a higher resolution.

I know that it is yet possible to reach a big part of what I have described here. For example you can change the font sizes (unlimited), icon sizes (limited!), the width of the scroll bars (only for Oxygen widget style, limited), the curser size (only hardcoded sizes available), the window decoration margin (only for Oxygen window decoration, only some predefined values).

However, there are elements which size can't be changed. For example checkboxes and radiobuttons in the widget style. Or the icon size of the applications in the system tray. Or the size of the icons that are displayed for plasmoids to resize them or set their preferences or to rotate them. And often the margins that are used in QLayout are fixed. So the overall impression isn't good at all.

We use non-standard display sizes more and more. So it is importand that KDE supports this usage better than it currently does. It should be easy to specify a factor, so that everything is simply displayed bigger, with the same overall impression. This factor should not be phased, but continiously variable.

I know that this will require work in many different areas of KDE, but I think it is important to have this in mind for further development.
Comment 1 Christoph Feck 2011-05-02 19:38:38 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.
Comment 2 Christoph Feck 2011-05-02 19:52:36 UTC
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.
Comment 3 Lukas Sommer 2011-05-04 11:38:06 UTC
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?
Comment 4 Lukas Sommer 2011-05-07 18:52:25 UTC
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/
Comment 5 Lukas Sommer 2011-05-07 18:57:41 UTC
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")
Comment 6 Lukas Sommer 2011-05-08 18:23:35 UTC
Spinn-off bugs:

Bug 272790 - Make Oxygen style (and window decoration) fully scalable
Bug 272792 - Font DPI isn't fully scalable
Comment 7 Lukas Sommer 2011-05-20 13:58:53 UTC
Spinn-off bugs:

Bug 273723 - KConfigDialog::addPage() requires hardcoded icon sizes
Comment 8 Lukas Sommer 2011-05-23 09:27:16 UTC
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
Comment 9 Christoph Feck 2011-05-23 12:24:22 UTC
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.
Comment 10 Lukas Sommer 2011-05-23 13:48:24 UTC
> 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?
Comment 11 Lukas Sommer 2011-06-10 16:59:09 UTC
273936, 190489, 273938, 272790
Comment 12 Christoph Feck 2014-01-02 12:37:04 UTC
*** Bug 329518 has been marked as a duplicate of this bug. ***
Comment 13 putt1ck 2014-01-02 12:41:29 UTC
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.
Comment 14 putt1ck 2014-01-02 12:48:40 UTC
FYI 133936 (hard coded systray icons) is a blocker for this (duplicate or not)
Comment 15 putt1ck 2014-01-02 13:03:34 UTC
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).
Comment 16 Christoph Feck 2014-01-02 13:44:41 UTC
> 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.
Comment 17 putt1ck 2014-01-02 15:16:05 UTC
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.
Comment 18 Christoph Feck 2014-01-02 15:32:52 UTC
> 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/
Comment 19 Felix Miata 2014-02-02 15:10:30 UTC
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 .
Comment 20 Merike Sell 2014-12-18 21:02:57 UTC
*** This bug has been confirmed by popular vote. ***
Comment 21 Lukas Sommer 2020-08-23 07:56:52 UTC
There is now an option available:

System Settings → Display & Monitor → Global scaling

That seems to work quite well…
Comment 22 Lukas Sommer 2020-08-23 12:19:17 UTC
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.