Sadly I have had to disable comments in my previous blog because there is a being [that probably passes by human if you look at them] that started with insults, continued with more insults and then graduated to physically threaten me.
I always thought it was obvious, but if you insult people or try to cause them phisical harm, they are usually less prone to think "oh you're right, you've convinced me" and more prone to think "this human needs to stop harassing me and sort out their problems".
Take the file from poppler issue 1126. It's a file that doesn't look super complicated, a map of some caves.
With Poppler 21.08 it took 46 seconds to render in my relatively powerful i9-8950HK
Thanks to a patch from Thomas Freitag that time got reduced to 28 seconds by not recalculating again something we had already calculated and just copying it. Huge improvement! [This patch was developed prior to the filing of issue 1126, i guess Thomas had found similar issues on his own]
Then issue 1126 was created yesterday and it was clear that we were still super slow, mupdf/gs/firefox/chromium can render the file almost instantly, and we were at 28 seconds :/
So i had a look at the code and thought, why are we even copying the data if that data never changes? So I made a patch that brought rendering time down to 2.8 seconds :)
And then i had another look at the code and realized we were copying some more data that was never even used
After patching that we're standing at 1.5 seconds
The 3 combined patches have reduced the rendering time by more than 95%
P.S: This only applies to the Splash backend (used by Okular), the Cairo backend (used by Evince) is at 120 seconds, so someone should have a look because probably similar improvements can be made.
During Akademy some members of the community said stuff like "app/library XXX and YYY are not maintained even if we ship them in KDE Gear".
Which is not true, everything released in KDE Gear is maintained, there may not be an explicit maintainer, but there is shared community maintenance.
When confronting a particular person about it, they said "but look, there has not been any new commit that isn't either translation improvements or adapting to code deprecations/etc.", to which i said, "yes, that is exactly what maintenance means".
Road maintenance doesn't mean adding more lanes to the road every month, just means making sure the road does not break and fixing it a bit when/if it happens.
The same applies to software maintenance, the fact that there are no new features does not mean the software is not maintained.
Now, it is true that with community maintenance it's possible that the greater we has missed that something has stopped working, in that case, please raise it up, and we'll evaluate whether it's fixable or if indeed we want to declare that particular bit of software as unmaintained and stop shipping it in KDE Gear.
It is available at the usual place https://community.kde.org/Schedules/KDE_Gear_21.08_Schedule
Dependency freeze is in four weeks (July 8) and Feature Freeze a week after that, make sure you start finishing your stuff!
But in Okular we don't use Qt Quick you'll say!
Well, we actually use Qt Quick in the mobile interface of Okular, but you're right, this was not a patch for the mobile version, so "But in Okular we don't use Qt Quick!"
The story goes like this.
I was reviewing https://invent.kde.org/graphics/okular/-/merge_requests/431 and was not super convinced of the look and feel of it, so Nate gave some examples and one example was "the sidebar in Elisa".
So I started Elisa and saw this
You probably don't speak Catalan so don't see that lesquerra is a mistake it should be l'esquerra.
Oh the translators made a mistake i thought, so i went to the .po file https://websvn.kde.org/trunk/l10n-kf5/ca/messages/elisa/elisa.po?view=markup#l638 and oh surprise! the translators had not made a mistake (well not really a surprise since they're really good).
Ok, so what's wrong then?
I had a look at the .qml code https://invent.kde.org/multimedia/elisa/-/blob/release/21.04/src/qml/MediaPlayListView.qml#L333 and it really looked simple enough.
I had never seen a Kirigami.PlaceholderMessage before but looking at it, well the text ended up in a Kirigami.Heading and then in a QtQuick Label. Nothing really special.
Weeeeeeird.
Ok i said, let's replace the the whole xi18nc in there with the translated text and run elisa. And then i could see the ' properly.
Hmmmm, ok then the problem had to be xi18nc right? Well it was and it was not.
The problem is that xi18nc translates ' to ' to be more "html compliant" https://invent.kde.org/frameworks/ki18n/-/blob/master/src/kuitmarkup.cpp#L40
And unfortunately Qt Declarative 5.15 Text item default "html support" is something Qt calls "Styled Text" that only supports five HTML entities, and apos is not one of them https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/util/qquickstyledtext.cpp?h=5.15.2#n558
So where is the bug?
The Text documentation clearly states that ' is in the list of supported entities.
One could say the bug is that every time we use xi18nc in a Text we should remember to change the "html support" to something Qt calls "RichText" that actually supports '.
But we all know that's never going to happen :D, and in this case it would actually be hard since Kirigami.PlaceholderMessage doesn't even expose the format property of the inner text
So I convinced our friends at Qt that only supporting five entities is not great and now we support six ^_^ in Qt 6.2, 6.1 and 5.15 (if you use the KDE Qt patch collection) https://invent.kde.org/qt/qt/qtdeclarative/-/merge_requests/3/diffs
P.S: I have a patch in the works to support all HTML entities in StyledText but somehow it's breaking the tests, so well, need to work more on it :)
