Awesome projects blog

GSoC Final report - Part 3: Summary

Tue, 29 Aug 2017 00:00:00 +0200

I can’t believe the three months are already over, the time flies when you’re having fun.

Unfortunately, I couldn’t tackle everything I had planned - the rendering in Okular and Gwenview was much complexer than I anticipated. Once again, it needs much more time to modify existing code than to write new one.

Nevertheless, I enjoyed this challenge and hope the code for Okular will be merged in the next days and can therefore be in the next release - making HiDPI a more pleasant experience for the whole KDE community.

I also have to say this community is great, and I can highly recommend it for future students - you will certainly make many friends here. There are so many people trying to help you and making sure you have a good time. You’ll be challenged, but there is much to learn.

And go to Akademy - there will not only be many interesting talks, but you’ll also get to know your mentor and have great fun there (and it will be in Vienna next year :wink:).

So a huge thanks to my mentor, David Edmundson, to Valorie, for guiding us along the way, to the reviewers of my patches, and to anyone else who helped in the last months.

I definitely want to stay a KDE contributor and continue with the patches, also after my GSoC period is over. For the next few weeks however, I will be traveling without access to the internet. See you in a month!

GSoC Final report - Part 2: Gwenview

Tue, 29 Aug 2017 00:00:00 +0200

Current status

Getting there!

A first revision of my patch is up on phabricator, which works for raster graphics. Your holiday pictures should now open in all their details and no longer be a blurry mess!

Left: HiDPI-scaling enabled version; Right: Non-HiDPI rendering. Look at the tree branches.

What’s left to do?

Besides the RasterImageView, there is also the SvgImageView and the VideoViewAdapter that still need fixing. And the thumbnails.

Difficulties & Lessons learned

This was particularly challenging, because for every QSize that got used in the whole rendering stack, I had to check if the size was in the right coordinates. If it wasn’t, the whole rendering would break. That was pretty difficult for debugging, because garbled pictures meant that at least one size had to be wrong - somewhere in a few thousands lines of code.

GSoC Final report - Part 1: Okular

Mon, 28 Aug 2017 00:00:00 +0200

This is the first post of a 3-part series where I will go into technical details of my summer of code project. I will give a high-level overview about the current state of my written code, show you what’s supposed to work and how you can try that; and what still needs to be done.

Then I will write about some “Gotcha!” moments I have experienced in the past few months and what I could learn from them. Those aren’t in any way ordered and are there to explain why my project turned out like it did - and hopefully even help some future GSoC students along the way.

Enough with the introduction, let’s get into the details…

Current status

Nearly finished!

The review request is up on phabricator and currently in the 4th revision.

By and large there are no more showstoppers present and the code is in mergeable quality. Although there are still a few smaller issues present, I think those could be fixed independently in a later revision.

You are encouraged to test my patch, I’m happy about every feedback I can get!

What’s left to do?

Not much. There are still some rendering bugs in obscure places (e.g. when drawing on the screen while in presentation mode).

I also stumbled upon other bugs (more on that later), but those were out of scope.

Difficulties & Lessons learned

Tracking pixmaps

I’ve described in the examples how enabling HiDPI support basically works. So at first, I thought it was a good idea to track down any place where a pixmap is created, increase its size and set its device pixel ratio to QPaintDevice::devicePixelRatio().

This had several shortcomings: First, I had to track down where every single pixmap of the application got created. Secondly, I had to introduce getters and setters or extend existing method signatures, so I knew the DPR value of the current screen in every class a pixmap is generated. This was not only cumbersome, but also broke the ABI (application binary interface) - one mustn’t extend functions of the library with another parameter.

Therefore I had to look for another approach: Instead at setting the DPR directly after creating, I noticed it was sufficient to do so just before painting the pixmap, because its value is only used for the layout size. I also filled the pixmap cache with images enlarged by the factor QApplication::devicePixelRatio() - this means that the window can be freely moved between screens with differing scaling factors while the cache stays valid and the documents are correctly rendered. Also, the code was much more concise: The only changes needed were in the PixmapRequest, where the larger images were automatically requested; and in the rendering code - pageview.cpp, pagepainter.cpp, pageviewannotator.cpp and presentationwidget.cpp.

Scaling icons

Okular includes some app-specific icons, which weren’t yet HiDPI-ready.

So I tried to fix it by generating higher resolution PNGs from the SVG source, and install them via cmake, similar to that:

ecm_install_icons(ICONS
    32-actions-tool-base-okular.png
    64-actions-tool-base-okular.png
[...]
)

Afterwards I should be able to just load the correct version of the icon via QIcon::fromTheme(QStringLiteral("tool-base-okular")), right?

Yes, that works… for simple, square icons. Which the annotation icons weren’t.

So David showed me another nifty trick: If there is a tool-base-okular@2x.png file next to tool-base-okular.png, Qt recognizes this and will automatically load the HiDPI version with the right scaling factor set when requesting this icon.

But when dealing with QPixmaps - instead of icons -, one must directly load this version:

// Load HiDPI variant on HiDPI screen
QString imageVariant;
if ( qApp->devicePixelRatio() > 1.05 ) {
    imageVariant = "@2x";

pixmap.load( QStandardPaths::locate(QStandardPaths::GenericDataLocation, QString("okular/pics/tool-base-okular" + imageVariant + ".png") ) );

Complexity

As already mentioned in my previous post the rendering code is really complex and, in my opinion, difficult to understand in the beginning.

Besides the many different codepaths - depending on the availability of a tile manager, the need for for back buffering or the cases where images are not yet ready - some of the code is also already showing symptom of old age.

It was written for Qt 3.3, and then ported over to newer versions. Nowadays some functions could be much simpler and cleaner. Whenever possible, I tried to modernize the code, but a complete overhaul was out of scope. Thankfully, I was not the only one trying to solve this technical debt though.

Chasing ghosts

A few weeks ago, I was at a state where I could open PDF documents, zoom into them and the rendering worked. I tried to open a PNG images, and that behaved also as it should have. I was pleased with myself.

But for testing, I wanted to make sure every filetype worked. And they all did reasonably well - until I got to multipage TIFF documents.

Those were completely broken, shown in a wrong aspect ratio and generally bahaving quite strange. I was puzzled, because everything else up to that point had worked so well.

I quickly checked the Okular release included in my distribution, noticed that the image got rendered there correctly and then tried to find the bug in my code. If I had been a bit more careful at this step, I could have saved myself several hours of scratching my head and wondering what the hell I got wrong there.

Because, as I noticed after those frustrating hours, my distribution rendered the image using the general “Image Backend”, not the specialized one for TIFFs. As I’ve already checked before the “Image Backend” was working fine, but the TIFF generator had an already known bug - it looks like this hasn’t worked since 2006.

Fractional scaling

As already mentioned, getting fractional scaling correct is not easy. I had to fix many off-by-one and rounding errors and until the rendering finally looked good.

Development setup

For development, I set up a new user account and built the workspace, frameworks and applications with kdesrc-build. But this also had one downside: I once spent many hours narrowing down a crash of the application for seemingly random reasons when calling QAction::setEnabled. Turns out there was a bug in the master branch of KXmlGui.

A good tip for future students is to get acquaint with gdb soon, at least I had to use it heavily.

My setup also included two screens, which also meant a great deal of configuration hassle.

Side trip to the Qt source code

Sometimes, I also had to look directly into the source of the Qt Framework to better understand some things. Luckily, I had compiled it myself, and therefore this was easy.

On one such instance I had to check that the copy constructor of QPixmaps doesn’t perform a deep copy of the whole pixmap data after changing some data. The setDevicePixelRatio method does call detach() when changing the value, but luckily the underlying QPlatformPixmap stays the same.

Testing

I set up a test plan to check that i didn’t break things along the way.

In hindsight, this was a clever thing to do at the start, because it also allowed me to see my progress - which functionality already worked and what still needed to be changed.

You made it to the end of the post, here is a cake for you! :cake: If you’re still reading, the future of Okular has to matter for you. Therefore I would be happy if you could try out my patch and give me a quick feedback how it works for you.

GSoC Status report - HiDPI Howto

Thu, 10 Aug 2017 00:00:00 +0200

I’ve something special planned for this blog post: This time, I will not only describe what I did in the last weeks, but I will go into some detail how I did it.

This blog post is the first one of a two-part-series where I demonstrate my work with practical examples. For the beginning, I don’t want to focus on specific applications (this will follow later!), but demonstrate basic HiDPI concepts with a minimalistic demo application. If you already had to do with HiDPI scaling in Qt once, you can probably skip this post. If you’re developing a Qt application that somewhere deals with QPixmaps directly, this is the post for you!

To make those examples as simple and less verbose as possible, they are written in Python with PyQt. The concepts can be translated to C++/Qt 1-to-1.

Enabling HiDPI

A log of HiDPI handling stuff is already done transparently in the Qt Framework: Starting with Qt 5.6 the framework checks if the environment variable QT_SCREEN_SCALE_FACTORS is set - this variable can be configured in a KDE world using the SystemSettings Display module. Before 5.6 the env variable QT_DEVICE_PIXEL_RATIO (now deprecated!) was checked, but the newer approach not only allows configuring the scaling factor independently for each screen, but - in theory - also supports rational numbers. Why this only works in theory, you can read in a later blog post.

So this means that most of the stuff already works out of the box in Qt - unless an application has specifically opted out of enabling automatic scaling based on the pixel by setting the Qt::AA_DisableHighDpiScaling attribute on a QApplication, like plasmashell does.

Dealing with pixmaps

Here is our requirement for our Proof of Concept: We want to draw a KDE logo, as clear and shiny as possible!

KDE logo, used for the examples below

How would we do this? One possible solution could like this:

import sys
from PyQt5.QtCore import *
from PyQt5.QtGui import *
from PyQt5.QtWidgets import *

app = QApplication(sys.argv)


class Window(QMainWindow):
    def __init__(self, parent=None):
        super(Window, self).__init__(parent)

        pixmap = QPixmap("./kde.png")

        label = QLabel(self)
        label.setPixmap(pixmap)

        self.setCentralWidget(label)

    def contextMenuEvent(self, event):
        action = QAction(QIcon("./kde.png"), "KDE", self)

        menu = QMenu(self)
        menu.addAction(action)
        menu.exec_(event.globalPos())


w = Window()
w.show()

app.exec_()

Starting this piece of code with scaling enabled (python QT_SCREEN_SCALE_FACTORS=2 demo.py) results in the following output:

Huh, what’s going on here? Haven’t I said that Qt is able to figure out all basic scaling stuff on its own?

Yes, it does.. but we have to tell Qt explicitly to enable this setting via Qt::AA_UseHighDpiPixmaps:

Make QIcon::pixmap() generate high-dpi pixmaps that can be larger than the requested size. Such pixmaps will have devicePixelRatio() set to a value higher than 1. After setting this attribute, application code that uses pixmap sizes in layout geometry calculations should typically divide by devicePixelRatio() to get device-independent layout geometry.

This was made opt-in, because the returned pixmap can be larger than the requested size and therefore break existing code. Applications that opt-in to this feature need to make sure that they actually provide large enough pixmaps.

Enabling this …

app.setAttribute(Qt.AA_UseHighDpiPixmaps, True)

… improves things a bit:

At least the icon in the context menu is now drawn without blurrying.

But what can we do with the main pixmap? Let’s simplify the code first:

l = QLabel()
l.setWindowTitle("Pixmap")

pixmap = QPixmap("./kde.png")
l.setPixmap(pixmap)

l.show()

Qt uses two coordinate systems internally: the device independent pixels coordinate system, which is used for the gemoetry of widgets and items; and the device pixels coordinate system, which translates to the rendered output, that corresponds to the display resolution. The ratio between the device independent and device pixel coordinate systems is the devicePixelRatio. QPixmap does not know what this ratio should be and therefore can’t take it into account automatically. For this reason the devicePixelRatio also needs to be set:

pixmap.setDevicePixelRatio(l.devicePixelRatioF())

This results in the correct scaling (QSize layoutSize = image.size() / image.devicePixelRatio()) of the pixmap:

Side note: Have you noticed we used the devicePixelRatioF method? This is a new method since Qt 5.6, which returns a real value, instead of the old integer value of devicePixelRatio. Use the real variant, whenever possible!

Multiple monitors with different scale factors?

As I’ve seen while working on Okular and Gwenview, pixmaps often get cached.

Their implementation is vastly more complex than the example given below, but this implementation shows a simple caching strategy:

class Window(QMainWindow):
    def __init__(self, parent=None):
        super(Window, self).__init__(parent)
        self._width = 200
        self._height = 200
        self._pixmap = None

        self.resize(self._width, self._height)

    def paintEvent(self, event):
        if self._pixmap is None:
            dpr = self.devicePixelRatioF()
            pixmap = QPixmap("./kde-large.png")
            self._pixmap = pixmap.scaled(self._width*dpr, self._height*dpr, transformMode=Qt.SmoothTransformation)
            self._pixmap.setDevicePixelRatio(dpr)

        p = QPainter(self)
        p.drawPixmap(0, 0, self._pixmap)

        print("Pixmap DPR: %s / PaintDevice DPR: %s" % (self._pixmap.devicePixelRatioF(), self.devicePixelRatioF()))

This already looks quite good. But can you guess what could still go wrong here?

In Qt we can have different screens - even with different ratio between device independent and device pixels. If the second screen has a higher DPR value, the cached pixmap is too small.

Here is a demonstration:

As a workaround, we can use the highest DPR value of all screens for the caching of the pixmap. In Qt, this is available via

dpr = qApp.devicePixelRatio()

Returns the highest screen device pixel ratio found on the system. This is the ratio between physical pixels and device-independent pixels.

Use this function only when you don’t know which window you are targeting. If you do know the target window, use QWindow::devicePixelRatio() instead. Qt documentation

And now we finally have the shiny KDE logo in all its glory!

Akademy 2017.. and 2018!

Fri, 04 Aug 2017 00:00:00 +0200

Quick stop in Malaga, before getting on a bus to Almería

As a Summer of Code student, I used the opportunity to meet my mentor David and many other members of the community at this years annual Akademy conference in Almería. This was the first year I attended, so I didn’t know the people I’ve communicated with over IRC and mailing lists in person before. It really helped that I am now able to put faces to the screennames on IRC. And big thanks to David, that you introduced me to a lot of them.

The talks were genuinely informative, I especially enjoyed the wonderful future we will see in Plasma Mobile, and how we can enlarge our (developer) community by supporting further international writing systems. Features of new C++ releases were shown, we got on overview on how we can make use of functional constructs and got some insight into debugging QML. There were so many informative talks, I unfortunately can’t list all of them!

I also had the oppertunity to meet Vasudha, another GSoC student working on a QML interface to Rocket.Chat. I think we two were the only current GSoC stundents present. I can only recommend to future students to go there, it helped me a lot. Not only that you get to meet new friends, but also to hear about the challanges they had when implementing something similar.

Almería, as seen from San Cristóbal

A huge thanks to all of the organisators, without you this wouldn’t have been possible! I hope I can speak for everyone when I say we really enjoyed our time there!

And lastely, I had the pleasure to announce at the conference that next year Akademy will be going to Vienna, Austria. I will be co-organizing the event with Horrendus and other members of our local KDE community.

I'm going to Akademy

Tue, 04 Jul 2017 00:00:00 +0200

As briefly mentioned in my last blog post, I will attend this years Akademy conference in Almería.

Are there other KDE GSoC students that also will be going there? If yes, it would be great if we could organize some kind of get-together to exchange experiences and socialize. What do you think of this idea?

GSoC Status report - Okular

Fri, 30 Jun 2017 00:00:00 +0200

In this post, I want to show you what I did during my first two weeks of the Google Summer of Code.

Okular before adding support for HiDPI

As you can see in the screenshot, Okular unfortunately is one of the applications that still has rendering problems on HiDPI screens. That’s bad for me, because I use Okular regularely for reading scientific papers. To be fair, there is a workaround to create a wrapper script which unsets QT_SCREEN_SCALE_FACTORS, but this also means everything is displayed unscaled.

So I decided to focus on the applications in the kdegraphics module - beginning with okular in the first phase of the GSoC program.

And - drum roll please! - this is the result of two to three weeks coding:

Okular after adding support for HiDPI

As you can see, the rendering does now work (if you don’t see the difference, open the images in fullscreen). :-)

This took more time then I hoped it would, due to two reasons:
Most of the code that is responsible for the rendering dates back to 2005 - a time, where Qt still belonged to Trolltech and Qt 3.3 was just released. Of course it was ported over to Qt5 and still works, but sometimes I thought there would be a more efficient/simpler solution today. Unfortunately this was out of scope for this project, so there are still many places where the pixels of QImages are modified directly.

The painting of the individual pages also turned out be be difficult to understand. It basicially happens in one, big, complicated, 1000 line long function. This function contains many if statements to handle special cases - e.g. there are many blocks that are only executed if there is a tile manager, or if the image needs to be back-buffered (if it contains highlighting or annotations), or if the page is not yet loaded and a loading icon is drawn (with, again, a fallback if this fails too).

That means testing will also not be that straightforward - in the coming days, I will make sure that all the features still work as expected: all the different document types, with annotations, while zoomed in…

If you want to try this out, the patch is already up on phabricator. Please also leave feedback after testing, this would help me tremendously.

I'm sure there are still a few bugs in here - the first person to spot one will get a beer at Akademy

At this point I wanted to tell you about gwenview - the next application I’m tackling in the kdegraphics module. But unfortunately, my patch isn’t ready yet and has to wait for the next blog post…

GSoC preparation - Plasma Toolicons - A journey down the rabbit hole

Sun, 25 Jun 2017 00:00:00 +0200

Before writing about my actual Summer of Code experiences, I wanted to briefly share what I worked on before the official coding start.

Plasma toolicons

Can you see these ridiculously small toolicons next to the Media frame plasmoid? I’m talking about the icons which allow you to Resize, Rotate and Remove the Plasmoid. Compared with other icons, these are clearly too small.

So, as preparation for GSoC, I wanted to know why this happens, and what would be required to make them bigger. Thus my journey into the (Plasma) rabbithole began…

Tracking down where the containment is defined was relatively easy, and shortly after i found the code responsible for the ActionButton:

PlasmaCore.ToolTipArea {
    id: button

    location: PlasmaCore.Types.LeftEdge
    mainText: action !== undefined ? action.text : ""
    mainItem: toolTipDelegate

    //API
    property QtObject svg
    property alias elementId: icon.elementId
    property QtObject action
    property bool backgroundVisible: false
    property int iconSize: 32
[...]

Huh, the iconSize is 32px? Well, that was easy to fix, surely this should be set to units.iconSizes.small and this problem is gone…

… or so I thought. No, this didn’t improve the situation, back to square one.

Is it overwritten by the look and feel theme? plasma-workspace/lookandfeel/contents/components/ActionButton.qml at least doesn’t - and it also happens with the style set to Oxygen.

While looking at this, I also noticed that units.iconSizes.small returned 16px on my system. This seemed odd, because the scale factor was set to 1.8x, so I would have expected bigger icons.

Where is this icon size calculated? Ah yes, in the file units.cpp, method Units::devicePixelIconSize.

int Units::devicePixelIconSize(const int size) const
{
    /* in kiconloader.h
    enum StdSizes {
        SizeSmall=16,
        SizeSmallMedium=22,
        SizeMedium=32,
[...]
     };
    */
    // Scale the icon sizes up using the devicePixelRatio
    // This function returns the next stepping icon size
    // and multiplies the global settings with the dpi ratio.
    const qreal ratio = devicePixelRatio();

    if (ratio < 1.5) {
        return size;
     } else if (ratio < 2.0) {
         return size * 1.5;
     } else if (ratio < 2.5) {
[...]
}

Ok, my devicePixelRatio is 1.8 and therefore the icon size of a small pixmap gets multiplied by 1.5 and a request for a small (16px) pixmap should return a 24px pixmap.

But it doesn’t…

Debugging suggested that my devicePixelRatio is NOT 1.8, but rather around 1.4. How did that happen, isn’t the scale factor from the KDE settings used?

Oh, the comment in updateDevicePixelRatio() mentions that QGuiApplication::devicePixelRatio() is really not used:

void Units::updateDevicePixelRatio()
{
    // Using QGuiApplication::devicePixelRatio() gives too coarse values,
    // i.e. it directly jumps from 1.0 to 2.0. We want tighter control on
    // sizing, so we compute the exact ratio and use that.
    // TODO: make it possible to adapt to the dpi for the current screen dpi
    //  instead of assuming that all of them use the same dpi which applies for
    //  X11 but not for other systems.
    QScreen *primary = QGuiApplication::primaryScreen();
    if (!primary) {
       return;
    }
    const qreal dpi = primary->logicalDotsPerInchX();
    // Usual "default" is 96 dpi
    // that magic ratio follows the definition of "device independent pixel" by Microsoft
    m_devicePixelRatio = (qreal)dpi / (qreal)96;

Hmm, yes, that was the case in earlier Qt versions when devicePixelRatio still returned an integer - but nowadays the value is a real number.

So, instead of calculating dpi / 96 I just changed it to return primary->devicePixelRatio().

Which now, finally, should return a devicePixelRatio of 1.8 and therefore result in bigger pixmaps.

Compiled it, and confident of victory restarted plasmashell… only to notice, that it still didn’t work.

What could there still go wrong?

So I got back to debugging.. to notice that primary->devicePixelRatio() returns a scale factor of 1.0. Huh? Isn’t this supposed to just use the QT_SCREEN_SCALE_FACTORS environment variable, which gets set to the value of the “Scale Display” dialog in the Systemsettings? If you want to know, the code for setting the environment variable is located in plasma-workspace/startkde/startplasmacompositor.cmake.

But why isn’t the problem gone, is there something in Plasma that overwrites this value?

Yes, of course there is!

The only way this value can be overwritten is due to the Qt attribute Qt::AA_DisableHighDpiScaling.

Grep’ing for that one pointed me to plasma-workspace/shell/main.cpp - the base file for plasmashell:

int main(int argc, char *argv[])
{
//    Devive pixel ratio has some problems in plasmashell currently.
//     - dialog continually expands (347951)
//     - Text element text is screwed (QTBUG-42606)
//     - Panel struts (350614)
//  This variable should possibly be removed when all are fixed

   qunsetenv("QT_DEVICE_PIXEL_RATIO");
   QCoreApplication::setAttribute(Qt::AA_DisableHighDpiScaling);

I looked into the mentioned bugs. What should I do now? Re-enabling the HighDpiScaling-flag so the real devicePixelRatio is returned in Qt, and therefore I can use this value to calculate the sizes icons should be and then have the bigger Plasma ToolIcons? At least QTBUG-42606 seems to be fixed…

Oh boy, what have I gotten into now…

It was time to talk to my mentor!

David Edmundson quickly noticed that there should be no mismatch with the dpi / 96 calculation. Something fishy seems to be going on here…

What is this dpi value anyway? This is the one reported by xrdb -query |grep Xft.dpi and managed in the file $HOME/.config/kcmfonts.

And that value - as you probably can guess by now - did not make any sense. It didn’t match the expectation of being scaleFactor * 96, the value it should have been set to.

On we go to the location where the scaling configuration is set - scalingconfig.cpp in the KScreen KConfig Module.

void ScalingConfig::accept()
{
[...]
   fontConfigGroup.writeEntry("forceFontDPI", scaleDPI());
[...]
}

qreal ScalingConfig::scaleDPI() const
{
    return scaleFactor() * 96.0;
}

This scaleDPI is then applied with xrdb -quiet -merge -nocpp on startup.

So Xft.dpi is set to 1.8 * 96.0, or 172.8.

Have you spotted what is going wrong?

I did not, but David noticed…

The X server can only handle real values - and therefore 172.8 is simlpy discarded!

A few moments later this patch was ready…

… and I was finally able to enjoy my icons in all their scaled glory! And you can too, because this patch is already in Plasma 5.10.

Do you know of any HiDPI issues? - Help me to help you

Mon, 15 May 2017 00:00:00 +0200

In my proposal I have linked to a few rendering issues on HiDPI screens, and presented an initial timeline how I plan to fix them.

But I can still shift my proprities, depending on your input! Do you have any rendering problems with KDE applications on a HiDPI screen? Tell me!

Just write a comment to this blog post with your most annoying problems, and chances are good that they’ll get fixed during my GSoC time. If there’s already an open issue on the bug tracker, feel free to link to it. Otherwise, please also state which version of the application you use and what your scale factor (Systemsettings -> Display and Monitor -> Scale Display) is.

I’ll collect those issues on my Summer of Code Status Report page.

Making Hi-DPI awesome - Hello GSoC!

Mon, 15 May 2017 00:00:00 +0200

As already introduced by Valorie my proposal was also selected for this years summer of code! :tropical_drink::cocktail::beers::tada::confetti_ball:

Okay, before celebrating too much prematurely, I should better get started with coding. So what will I work on during the next 3 months?

Not so long ago, I decided to treat myself with a brand-new 4K monitor - just to improve my productiveness of course. Thanks to many dedicated people the situation was not that bad. Of course, here and there were some quirks, but that’s what you get for living on the bleeding edge, right?

To my horror it happened that I stumbled upon competing desktop environments (it happened by accident, I swear!) and noticed that the situation there was even a bit better. There were no blurred images when opening my last holiday pictures in my favorite image viewer, not even unreadable documents when I’ve quickly have to proofread my paper after nearly missing a deadline!

So, I asked myself, why can’t we have all the nice things too? Well, first of all, because suitable HiDPI support in Qt landed just fairly recently. Secondly, not everyone owns a high-res screen yet (unfortunately!) and therefore might not even be aware of some rendering issues. And thirdly, getting HiDPI rendering correct can be hard (except for the times when it’s really easy).

I thought about it and decided that it would be best if the remaining issues would be fixed in a coordinated approach. This way, I can build up enough knowledge about the current HiDPI situation, which I then apply to different applications - details about that can be found in my application here.

And hurray! - this proposal really got selected. And what’s even better - it will be mentored by David Edmundson, the guy that’s already worked on HiDPI support for Plasma and other projects for years.

I’m really looking forward to the next few months and promise to keep you updated with regular blog posts!

Hello World!

Fri, 12 May 2017 00:00:00 +0200

Hello World!

Right now there’s not yet much to see here, but this is going to change soon: I was selected as Google Summer of Code student and will be working for the KDE project. More details will follow in the next few days.

Besides my work for KDE, I’ve also planned to post about some ofter projects.. there’s so much awesome stuff to write about, so just subscribe to the feed to stay updated.

Lukas