GSoC/2017/StatusReports/LukasHetzenecker: Difference between revisions
No edit summary |
|||
| Line 12: | Line 12: | ||
== Blog Posts == | == Blog Posts == | ||
[https://blog.hetzenecker.me/2017-05-15-hello-gsoc/ 2017-05-15: Making Hi-DPI awesome] | |||
[https://blog.hetzenecker.me/2017-05-15-hidpi-issues/ 2017-05-15: Do you know of any HiDPI issues?] | |||
== Preparation == | == Preparation == | ||
Revision as of 17:47, 25 May 2017
Make High-DPI awesome
As seen on Blog Posts on Planet KDE support for High-DPI monitors has come a long way since Plasma 5.0. And thanks to the work by many dedicated people the situation in Plasma is now almost ideal. But unfortunately, this is not the case for all KDE applications. Support for HiDPI seems to be more of a hit-and-miss for some of them, many crucial for day-to-day workflows (like Okular and Gwenview). Competing desktop environments have nowadays a nearly perfect HiDPI support, so I think it is time to face the remaining problems once and for all.
Therefore I suggest the following approach: My Google Summer of Code project will find HiDPI rendering issues in KDE applications and fix them in a coordinated approach. I will look at applications, which are usually installed on the users desktop, like the Plasma Workspace, Systemsettings and utilities from the kdegraphics module (gwenview, okular, spectacle).
This will also require working together with KDE community members, which report bugs, and application maintainers, to get the submitted patches on the KDE reviewboard in a state that allows them to be committed in their respective repositories.
Documents
Blog Posts
2017-05-15: Making Hi-DPI awesome
2017-05-15: Do you know of any HiDPI issues?
Preparation
Work report
TBD