fidzu : kde

Today, on September 18th, 2018, the Russian-speaking KDE community launches its updated website on KDE.ru.

The new website serves as the main page for the Russian-speaking community. It provides localized information about the community, product download links and the list of social network pages we maintain. It is also meant to help new members get involved in KDE's projects, particularly in our translation and promotion efforts.

The website was created by me and Alexander Potashev on top of Jonah Brüchert's work for plasma-mobile.org. It uses Jekyll and is now hosted on official KDE servers. It replaces the old forum that has significantly lost its users in the past years.

If you like our work, please share the website with your friends and subscribers! If you find mistakes, report them in VK group messages, contact me or open a Phabricator revision with a fix.

We would like to thank Ben Cooksley for his help with website deployment, all the users who participated in beta testing, and everyone who helped polish the content.

18 Sep 2018 1:47pm GMT

Krita's 2018 fund raiser is all about fixing bugs! And we're fixing bugs already. So, let's take a non-technical look at a bug Dmitry fixed yesterday. This is the bug: "key sequence ctrl+w ambiguous with photoshop compatible bindings set" And this is the fix.

So, we actually both started looking at the bug at the same time, me being Boudewijn. The issue is, if you use a custom keyboard shortcut scheme that includes a shortcut definition for "close current image", then a popup would show, saying that the shortcut is ambiguous:

The popup doesn't tell where the ambiguous definition is… Only that there is an ambiguous definition. Hm… Almost everything that does something in Krita that is triggered by a shortcut is an action. And deep down, Qt keeps track of all actions, and all shortcuts, but we cannot access that list.

So we went through Krita's source code. The action for closing an image was really created only once, inside Krita's code. And, another bug, Krita doesn't by default assign a shortcut to this action. The default shortcut should be CTRL+W on Linux and Windows, and COMMAND+W on macOS.

Curiously enough, the photoshop-compatible shortcut definitions did assign that shortcut. So, if you'd select that scheme, a shortcut would be set.

Even curiouser, if you don't select one of those profiles, so Krita doesn't set a shortcut, the default ctrl+w/command+w shortcut would still work.

Now, that can mean only one thing: Krita's close-image action is a dummy. It never gets used. Somewhere else, another close-image action is created, but that doesn't happen inside Krita.

So, Dmitry started digging into Qt's source code. Parts of Qt are rather old, and the module that makes it possible to show multiple subwindows inside a big window is part of that old code.

/*!
    \internal
*/
void QMdiSubWindowPrivate::createSystemMenu()
{
...
    addToSystemMenu(CloseAction, QMdiSubWindow::tr("&Close"), SLOT(close()));
...
    actions[CloseAction]->setShortcuts(QKeySequence::Close);
....
}
#endif

Ah! That's where another action is created, and a shortcut allocated. Completely outside our control. This bug, which was reported only two days ago, must have been in Krita since version 2.9! So, what we do now is to make sure that the Krita's own close-image action's shortcut gets triggered. We do that by making sure Qt's action only can get triggered if the subwindow's menu is open.

    /**
     * Qt has a weirdness, it has hardcoded shortcuts added to an action
     * in the window menu. We need to reset the shortcuts for that menu
     * to nothing, otherwise the shortcuts cannot be made configurable.
     *
     * See: https://bugs.kde.org/show_bug.cgi?id=352205
     *      https://bugs.kde.org/show_bug.cgi?id=375524
     *      https://bugs.kde.org/show_bug.cgi?id=398729
     */
    QMdiSubWindow *subWindow = d->mdiArea->currentSubWindow();
    if (subWindow) {
        QMenu *menu = subWindow->systemMenu();
        if (menu) {
            Q_FOREACH (QAction *action, menu->actions()) {
                action->setShortcut(QKeySequence());
            }
        }
    }

That means, for every subwindow we've got, we grab the menu. For every entry in the menu, we remove the shortcut. That means that our global Krita close-window shortcut always fires, and that people can select a different shortcut, if they want to.

18 Sep 2018 10:37am GMT

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn't mean we don't care for it while we still need to. KDE4 was released on January 11th, 2008 - I still have the T-shirt - which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 - certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too - FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we're seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That's a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio's KDE1 efforts, though)

So, while we're counting down to removing KDE4 from the FreeBSD ports tree, we're also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there's lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn't comparable to the integer 0. Suffice to say I've spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

18 Sep 2018 9:26am GMT

All Systems Go! 2018 Tickets Selling Out Quickly!

Buy your tickets for All Systems Go! 2018 soon, they are quickly selling out! The conference takes place on September 28-30, in Berlin, Germany, in a bit over two weeks.

Why should you attend? If you are interested in low-level Linux userspace, then All Systems Go! is the right conference for you. It covers all topics relevant to foundational open-source Linux technologies. For details on the covered topics see our schedule for day #1 and for day #2.

For more information please visit our conference website!

See you in Berlin!

10 Sep 2018 10:00pm GMT

Last month KDE Akademy was held in Vienna. It was the first Akademy I visited and there wasn't yet time to write a bit about the impression I got from it, judging what was nice and what could be improved from the point of view of someone new to it. Time to catch up on that.

Akademy came at a bad point in time for me. I was right in the middle of writing code for a larger feature in KWin's Wayland session: drag-and-drop support between Wayland native and Xwayland windows. When I began the work on this feature back in July I hoped that I could finish it until Akademy. Not being able to do so felt demotivating, but I have to admit my plan was way too optimistic anyways. Only now, several weeks after Akademy, I feel comfortable enough about my code to use it on my work system without constant anxiety for fatal session crashes. But anyway, I went to my first Akademy with a bit less enthusiasm, as I otherwise probably would have shown. On the other side this gives me maybe also a more neutral take on it.

Akademy is basically split into two phases: the talks at the beginning on Saturday and Sunday and the BoFs for the rest of the time from Monday till Friday.

The talks

This is basically what you expect from a conference. Talks by people involved in the community or friends from the outside about different topics related to KDE. And these topics were very different indeed, what shows how large the KDE community and its reach really is. Often KDE is identified with the desktop environment Plasma alone, but there is much more to it. Having this kind of diversity in topics is a great plus to Akademy.

Still one has to say that Plasma is KDE's flagship offering and by that deserves a central spot in the lineup. So judging from a Plasma dev point of view was this the case at this Akademy? That's difficult to judge. There were interesting longer talks by David and Nate about the core Plasma Desktop experience, David's talk technical, Nate's talk on a broader more visionary note they both presented a path forward for Plasma. There were also talks about Plasma in other contexts, for example by Bhushan about Plasma on Mobile.

So judging by quantity there were enough Plasma talks I would say. Also I can't really complain, since I personally did not contribute to increasing the quantity by submitting a talk proposal myself. The reason was just that on my first Akademy I wanted to be a listener only. So let us say quantity was fine and quality from what I can tell as a listener as well.

Still there was a distinct feel of too few, too disconnected, and I believe especially too disconnected describes it correctly, not only in regards to Plasma. The talks were spread out over two days in two different sized rooms somewhat randomly. There was no noticeable order to them or a grand arc connecting them besides being somewhat KDE related. One could argue this is a direct result of the KDE community being so diverse in interests and topics. But I believe with good planning by some key figures from the different parts of the community the talks could have been placed better and feel less disjointed. Also more relevant key notes would have helped. They could have provided for example an overarching focus point of the conference interconnecting the talks.

The BoFs

The second part of Akademy were the BoFs, what went for a full workweek. BoF means Birds of a feather and it denotes an informal discussion group about a specific topic. There were many BoFs, often in parallel, and I visited lots of them.

I won't go into detail for all of them, but a general impression I got was that there is no clear definition of what a BoF should be and what should happen. What is kind of the point of a BoF but somewhat still often disappointing. In an extreme case a BoF I visited was more an internal discussion of a team of half a dozen people working closely together and left everybody just interested in learning more about the project on the outside since they did not know enough about the project's internals yet. The BoF itself was not named as such and outsiders visiting out of interest were for sure disappointed. Other BoFs were more welcoming to newcomers, but still lacked a guiding structure or just someone moderating the discussion efficiently.

A plan to improve the BoF sessions could be the following: split them up into a mandatory common / introductory part and an optional team / current progress / special topic part, and advertise them as such to conference attendees. While both parts would still be open to anyone, the common part would be specifically suited for newcomers to the project while the team part can be used to discuss current topics in-depth. This at first sounds like it is double the work for project members, but the common part could be simply some reusable presentation slides explaining the core structure of the project together with a Q&A session. So I believe the additional amount of work is small. Also people would know what they get into and could plan their time efficiently. Besides one person from the team, which would probably most often be the maintainer or project lead, others could avoid the introductory part and newcomers could avoid the team part if they don't yet feel knowledgeable enough to follow the discussion.

The organisation

In general I felt the conference was well organized for being done by volunteers, who were by the way super friendly and keen on helping and solving problems. There were a few issues ranging from non-functional printers to a way too small social event site, but they were so minor to not be worth delving into them more.

But there is one large issue that can not be ignored, and this is the availability and quality of videos form the conference. The videos have just been published recently and I think this is too late. They should be online not later than one week after Akademy.

And watching these videos is no fun at all. The talk recordings have a low resolution, filmed from way back in the room, and the voice quality often is abysmal. In comparison to last Akademy the vidoes already have improved, but they still lack the quality you would expect from an open tech community having the web as the main communication channel.

As an example what a good recording looks like take a look at this talk out of the chamber of darkness. I personally would take some of the Pineapple money and pay a team of professionals at next Akademy to record the talks in HD and upload them timely if we can not do it on our own. Enabling people who can not travel to Akademy to watch the presentations pleasantly and the additional exposure are always worth it.

The social and unofficial program

Of course technical topics are not everything about Akademy. The conference exists also to connect like-minded people and let otherwise semi-anonymous contributors meet each other in person, what often enables them to work better together on KDE projects in the future. Overall for me personally this was fine. I know most of the Plasma devs already and we just had a meeting in Berlin a few months ago. So there was not really that much need to talk in person again, although it helped for some current hot topics of course.

But there were some members of the VDG I was really looking forward to meet in person and the discussions we had were very fruitful. Also it was great to get to know Carlos from the GNOME project. I hope we can improve the collaboration of our communities in term of Wayland in the future. What I missed was talking more with some of the KDE Apps and Frameworks devs. I am not sure why this was. Maybe my personal area of work just does not intersect that much with apps developers at the moment.

Conclusion

This article was in some parts quite critical to Akademy, but that does not mean the conference was bad. Quite the contrary, I enjoyed meeting all the members and friends of the KDE community and I can recommend going there to anyone from user to maintainer of KDE software. It doesn't matter what kind of KDE offering you use or contribute to, you will find sessions that interest you and people who share that same interest. Next Akademy is in less than a year and I look forward to meeting you there again or for the first time.

09 Sep 2018 11:00am GMT

TWIV3D has been inactive for a bit, because I've been inactive for a bit. On August 15th, we added Moss Anholt to our family:

So most of my time has been spent laying around with them and keeping us fed instead of writing software.

Here and there I've managed to write some patches. I've been working on meeting the current GLES3 CTS's requirement for a 565 window system buffer being available. We don't expose those on X11 today, because why would you? Your screen is 8888, so all you could do with 565 is render to a pixmap or buffer. Rendering to a pixmap is useless, becasue EGL doesn't tell you whether R is in the top or bottom bits, so the X11 client doesn't know how to interpret the rendered contents other than glReadPixels() (at which point, just use an FBO). My solution for this bad requirement from the CTS has been to add support for 565 pbuffers, which is pointless but is the minimum. This led to a patch to the xserver and a fix to V3D for blending against RTs without alpha channels.

I'm particularly proud of a small series to create a default case handler function for gallium pipe caps. Previously, every addition of a PIPE_CAP (which happens probably at least 10 times a year) has to touch every single driver, or that driver will start failing. It's easy to forget a driver, particularly when rebasing a series across the addition of a new driver. And for driver authors, you're faced with this list of 100 values which you don't know the correct state of when starting to write a driver. The new helper lets CAP creators set a default value (usually whatever the hardcoded value was before their new CAP), and lets driver authors specify a much smaller set of required caps to get started.

Just before Moss arrived, I had landed some patches to VC4 to improve texture upload/download performance. Non-GL SDL apps on glamor were really slow, because the window wouldn't be aligned to tiles and we'd download the tile-aligned area from the framebuffer to a raster-order temporary, store our new contents into it, then reupload that to the screen. The download from write-combined memory is brutally slow. My new code (mostly a rebase of patches I wrote in January 2017!) got the following results:

• Improves x11perf -putimage10 performance by 139.777% +/- 2.83464% (n=5)
• Improves x11perf -putimage100 performance by 383.908% +/- 22.6297% (n=11)
• Improves x11perf -getimage10 performance by 2.75731% +/- 0.585054% (n=145)

I also wrote a followup patch to avoid the copy from the user's buffer into the temporary in the driver for texture uploads, for another 12.1586% +/- 1.38155% (n=145)

Other things since my last post:

• Fixed VCM cache size setup and the V3D driver's idea of the VPM size.
• Fixed a leak of X11 pixmaps backing pbuffers on DRI3.
• Fixed vc4_fence_server_sync() on pre-syncobj kernels.
• Fixed vc4 uniform offsets after a sampler in a structure.
• Improved vc4 uniform upload performance.
• Fixed vc4 MSAA tile loads when both Z and color are needed.
• Fixed vc4 rendering to cubemap EGL images.
• Fixed vc4 leak of the no-vertex-elements workaround BO.
• Fixed some v3d register spilling bugs.

07 Sep 2018 12:30am GMT