Skip to content

Tuesday, 13 April 2021

By Allyson Alexandrou

Akademy 2021 - Call for Participation

Akademy will be held online from 18th to 25th June and the Call for Participation is open! Submit your talk ideas and abstracts by 2nd May.

While all talk topics are welcome, here are a few talk topics specifically relevant to the KDE Community:

  • Topics related to KDE's current Community Goals.
  • KDE In Action: cases of KDE technology in real life.
  • Overview of what is going on in the various areas of the KDE Community.
  • Collaboration between KDE and other Free Software projects.
  • Release, packaging, and distribution of software by KDE.
  • Increasing our reach through efforts such as accessibility, promotion, translation and localization.
  • Improving our governance and processes, community building.
  • Innovations and best practices in the libraries and technologies used by KDE software.

Why should I submit a talk?

KDE is one of the biggest and well-established Free Software communities. Talking at Akademy gives you an audience that will be receptive to your ideas and will also offer you their experience and know-how in return.

As an independent developer, you will gain supporters for your project, the insight of experienced developers, and you may even gain active contributors. As a community leader, you will be able to discuss the hot topics associated with managing large groups of volunteers, such as management, inclusivity and conflict resolution. As a CTO, you will be able to explain your company’s mission, its products and services and benefit from the brainshare of one of the most cutting edge community-based Free Software projects.

How do I get started?

With an idea. Even if you do not know exactly how you will focus it, no worries! Submit some basic details about your talk idea. All abstracts can be edited after the initial submission.

What should my talk abstract or proposal include?

This is a great question! To ensure you get your point across both clearly and comprehensively, your abstract should include uses of your idea or product and show what different groups of people get out of it. For example, how can a company, developer, or even a user benefit from using your app? In what ways can you further their experiences?

If you’re still stuck on where to start or what to talk about, take a look at a brief list of talks given in previous years at Akademy:

You can find more Akademy videos on the KDE's YouTube channel.

DEVLOG: Bugfixing the KDE Panel!

Monday, 12 April 2021

As you can see in https://akademy.kde.org/2021/cfp the Call for Participation for Akademy 2021 (that will take place online from Friday the 18th to Friday the 25th of June) is already open.

 

You have until Sunday the 2nd of May 2021 23:59 UTC to submit your proposals but you will make our (talks committee) live much easier if you start sending the proposals *now* and not send them all last minute in 2 weeks ;)


I promise i'll buy you a $preferred_beverage$ for next years Akademy (which we're hoping will happen live) if you send a talk before end of this week (and you send me a mail about it)


If your background includes game development, the concept of a scene should sound familiar. A scene is a way to organize the contents of the screen using a tree, where parent nodes affect their child nodes. In a game, a scene would typically consist of elements such as lights, actors, terrain, etc.

KWin also has a scene. With this blog post, I want to provide a quick glimpse at the current scene design, and the plan how it can be improved for Wayland.

Current state

Since compositing functionality in KWin predates Wayland, the scene is relatively simple, it’s just a list of windows sorted in the stacking order. After all, on X11, a compositing window manager only needs to take window buffers and compose them into a single image.

With the introduction of Wayland support, we started hitting limitations of the current scene design. wl_surface is a quite universal thing. It can used to represent the contents of a window, or a cursor, or a drag-and-drop icon, etc.

Since the scene thinks of the screen in terms of windows, it needs to have custom code paths to cover all potential usages of the wl_surface interface. But doing that has its own problems. For example, if an application renders cursors using a graphics api such as OpenGL or Vulkan, KWin won’t be able to display such cursors because the code path that renders cursors doesn’t handle hardware accelerated client buffers.

Another limitation of the current scene is that it doesn’t allow tracking damage more efficiently per each wl_surface, which is needed to avoid repainting areas of the screen that haven’t changed and thus keep power usage low.

Introducing scene items

The root cause of our problems is that the scene thinks of the contents of the screen in terms of windows. What if we stop viewing a window as a single, indivisible object? What if we start viewing every window as something that’s made of several other items, e.g. a surface item with window contents, a server-side decoration item, and a nine-tile patch drop shadow item?

A WindowItem is composed of several other items – a ShadowItem, a DecorationItem, and a SurfaceItem

With such a design, the scene won’t be limited only to windows, for example we could start putting drag-and-drop icons in it. In addition to that, it will be possible to reuse the code that paints wl_surface objects or track damage per individual surface

Besides windows, the scene contains a drag-and-drop icon and a software cursor

Another advantage of the item-based design is that it will provide a convenient path towards migration to a scene/render graph, which is crucial for performing compositing on different threads or less painful transition to Vulkan.

Work done so far

At the end of March, an initial batch of changes to migrate to the item-based design was merged. We still have a lot of work ahead of us, but even with those initial changes, you will already see some improves in the Wayland session. For example, there should less visual artifacts in applications that utilize sub-surfaces, e.g. Firefox.

The end goal of the transition to the item-based design is to have a more flexible and extensible scene. So far, the plan is to continue doing refactorings and avoid rewriting the entire compositing machinery, if possible. You can find out more about the scene redesign progress by visiting https://invent.kde.org/plasma/kwin/-/issues/30.

Conclusion

In short, we still have some work to do to make rendering abstractions in KWin fit well all the cases that there are on Wayland. However, even with the work done so far, the results are very promising!

When your team goes remote or when you are creating a new remote or distributed team, you need to reconsider the most basic ground rules. Most are a given when colocated. One of these ground rules to reconsider is people’s availability.

At the office, you expect people to be available more or less at similar times, even if your organization promotes flexi-time or core hours, such expectation is mostly there. But when you go remote or even in the case of companies moving towards flexi-days (many will after COVID-19) availability is something that needs to be carefully considered and agreed within the context of the team or department.

This article will focus on one of those ground rules, availability, including a simple but powerful way of starting the conversation with your team members about it, which has a major impact in scheduling.

I have written before about the need to redefine those ground rules when going remote in several articles. I list them at the end of this article, in the References section. I mentioned in one of those articles that my former colleague back during my Linaro days, Serge Broslavsky, showed me a visualization to start the conversation about availability that I found so useful that I use it ever since. I have mastered it over time, have used it frequently and even assigned it a name: availability heat map. But before describing what it is, let me start by justifying why you should focus energy in reconsidering availability.

In remote environments, be explicit about availability

When remote, each team member works in a different environment even if they are located in the same geo area, time zone or if they share the same life style. I always assume as starting point that their environments might be very different from each other, so their availability might be too. It needs to be agreed, which requires a careful conversation.

Some people live with others at home (friends, partner, etc), they might have different responsibilities towards them and in some cases, those around them affect the environment in a way that it is not possible to assume that their availability will not be affected. In some cases, people work in cafes, coworking, etc. which involve other constrains.

Another typical case where availability becomes a topic is when having team members from different cultures. Different cultures have different approaches to lunch, for instance. Northern Europeans tend to have lunch very early, Central Europeans usually take lunch in no more than one hour (British even less in general). There are plenty of cultures out there that loves to promote to kill themselves slowly by eating fast and poorly at lunch :-). There are others though that take lunch seriously so they take more time. It is a social activity that, in some cases, is very important for families and at work. Latins tend to fall in that category. At the office, the environment influence these habits making them more homogeneous but that is not necessarily the case when working remotely, at least not on daily basis.

I have managed teams where the availability in summer changed compared to winter for people that lives up north or in very cold or warm areas. They might want to take advantage of the daylight during noon in winter or prefer to work during the mid-day because is too warm outside.

An interesting consequence of revisiting availability that I pay attention to is the expectations out of office hours related with communication channels. I have worked with people used to phone others when they are at the office but their colleagues are not. If I am at the office and the most of my team is too, it is ok to call who is not by phone. The heat map also helps to open a conversation about the consequences of not being available and what to expect. It helps these kind of people to understand which channel should be used to reach out to you and when.

A third interesting case is people that multitask or work in more than one project. Also teams with dependencies on other teams which have a different understanding of availability. This case is very frequent in remote environments. Discuss and agree on availability become a ground rule that should be taken seriously since day one.

What is the advantage of working from home if you cannot make your personal and work life compatible to some extend? A better life balance is a big win for both, the employee and the employer. Having a serious thought about availability is essential for achieving it. As a manager, I have had cases in which the remote workers where in coworkings instead of at home because the company did not provide to them the tools to create such balance. That should be avoided when possible.

My point is that going remote requires a conversation about availability that you most likely do not need to have at the office, so inexperienced managers or teams in remote work often take it from granted. Once they realize the problem, it might be hard to redefine availability or even impossible. In extreme cases, you might only find out when burning out is getting closer. Funny enough, I have found more of these cases among managers and freelancers than employed developers throughout my career. It has to do with team protection.

The availability heat map

In order to start such conversation, ask each member of your team or department to fill out the availability heat map as first step, ideally right after they join your organization. After analysing it, you will have a better idea of the impact that living in different environments as well as other factors like time zones and personal preferences will have over people’s availability. You will be in a much better position to discuss the team or department schedule, which will be reflected in the calendar (if possible), making it compatible with company policy or business needs.

In summary, make the availability explicit, compared to colocated environments, where availability is implicit in general. The availability heat map is a simple initial step to do so.

Who is it for

I have used the availability heat map with the following groups. I assume this extremely simple activity can work for additional groups:

  • Teams with members in different time zones.
  • Multicultural teams.
  • Large remote teams.
  • Teams with members who belong or support more than one team.
  • Teams with strong dependencies with people from other teams.
  • Teams with people with small kids.

Color scheme

I tend to use four colors in the availability heat map. Each color has a specific meaning. The goal is to assign a color to each hour of the day, as shown in the example. I came to this scheme over time. You can adapt it to your experience or environment :

  • Green: you are in front of the computer and available for the rest of the team on regular basis.
  • Yellow: you might be available although it cannot be assumed by default. It might depend on the day, time of the year, workload.
  • Amber: you are usually unreachable at these hours unless it is planned in advance. It is an undesired time slot for you by default.
  • Red: you are available if an emergency or under very unusual circumstances only.

The usual ratios of hours I have worked with in the past are 4-6 green hours, 2-6 yellow hours, 2-4 amber and 8-12 red ones. Do not try to show many green hours at first. This exercise is not to demonstrate you work 8 or more hours a day, which it is a common mistake among junior (i remote work) newcomers when they join a new organization or team. The price in your schedule might be very high and eventually unsustainable over time.

Explain the exercise

My recommendation is that you explain face to face (video chat) to the affected people the exercise, with your availability already introduced, before asking others to fill out theirs. People from different cultures and background respond differently to this activity based on cultural factors or prior experience with managers and remote work. In my experience, some people take at first this exercise as a control one, specially if you are the manager or PO instead of the Scrum Master or facilitator.

The goal is to find out the ideal time slots for scheduling activities but at the same time, as manager, you can take this opportunity to learn about people constrains and desires when it comes to working hours. I use this action as starting point for some 1:1 conversations. I mentioned before that when remote, each employee works in a different environment and such environment affects their performance. As a remote manager, you have to learn about it and provide guidance on how to establish a good balance so they maximize work efficiency in a sustainable way. It is not about interfering into their personal lives. The line is thin.

The example

In this example, we have five team members where the last two live in different time zones, UTC-5 and UTC+2. After each member fills out their desired/expected availability, the conversation about scheduling becomes easier. Each team member as well as managers and other supporting roles have a simple way to understand what kind of sacrifices each member might have to do to be available to their colleagues, making their availability compatible with the business needs as well as their team needs (ideally those should be very similar). The scheduling of the team and department ceremonies and other company activities hopefully become easier now. Understanding when the real time communication is effective and when the work should become asynchronous also become simpler.

In this case, thanks to the fact that Kentavious is an early bird and that Kyle is used to working with people in Europe, from the US East Coast and Brazil, they have already adapted their availability to work with those on these time zones. As you can see, the approach to lunch is different for each team member. In addition, Anthony has to finish work early and Marc prefers to work before going to bed, which is a common pattern among parents with small kids.

According to the map, there are two overlapping hours. If I would be the manager or part of this team, I would talk to them in group to expose that increasing the number of overlapping times bring benefits to the overall performance of the team. I would talk individually then with each member to find out a way to have one or two additional overlapping hours. In general, I would consider three or four hours of overlapping availability enough as starting point in this case. I always favor a homogeneous expectation of availability throughout the week that having “special” days where your schedule changes. In a previous job I had my “Tuesdays for Asia” and my “Thursdays for US” and believe me, it was not fun.

After a conversation and decision process, it would be good to update the availability heat map. I suggest to make it available to others. If your organization or project is formed by many teams, you might want to add the availability heat map to your team landing page. In my experience, it helps when scheduling activities with specific teams by people which are not directly related to them on regular basis.

If you have a tool where you can create and maintain a team calendar, try to add the common available hours there and make them visible to others. If your team is a service or support team to other teams, you might want a more powerful tool to communicate your availability but the availability heat map might do the job at high level.

There are tools out there to accomplish the same goal than the availability heat map, but I like simplicity and I never needed anything more complex, assuming you have a powerful corporate calendaring tool.

Finally, please keep in mind that the availability heat map is a dynamic visualization. Revisit this ground rule on regular basis, at least on summer and winter. Small but significant changes might apply.

Summary

In a variety of use cases, especially related with remote work, there are basic ground rules that need to be reconsidered. Availability is one of them.

The availability heat map is an extremely simple action that can provide a first overview of the overlapping times and can trigger a conversation to increase or adapt those hours, as previous step to define when the team ceremonies might or should take place, how the communication should happen when, etc.. It is also an interesting action to trigger 1:1 conversations with your managee or colleagues. It s simple and easy to adapt to many use cases.

If you have a different way to reach the same goal, please let me know. If you like this idea and will adopt it, please let me know how it goes and which adaptations you did. I am always interested in improving the availability heat map.

Thanks Serge.

References

Previous articles I wrote related with remote work:

Just yesterday someone joined in Plasma Mobile matrix room, asking for help and support for developing a native Signal client.

The post was immediately responded by some of my fellow developers with the responses which were basically,

  • Why signal when matrix is available and superior to it
  • While signal is open-source it does not provide all freedom to modify/redistribute
  • People should stop using signal

Some of these are important concerns but it made me think about the very initial Plasma Mobile announcement,

Important bits being,

The goal for Plasma Mobile is to give the user full use of the device. It is designed as an inclusive system, intended to support all kinds of apps. Native apps are developed using Qt; it will also support apps written in GTK, Android apps, Ubuntu apps, and many others, if the license allows and the app can be made to work at a technical level.

and

Most offerings on mobile devices lack openness and trust. In a world of walled gardens, Plasma Mobile is intended to be a platform that respects and protects user privacy. It provides a fully open base that others can help develop and use for themselves, or in their products.

Plasma Mobile aims to be not a walled garden, and provides a full control/freedom to users, which interestingly also comes with freedom to use the walled garden inside your open garden.

If user can not have this freedom or is actively being pushed towards ecosystem liked by the developers, then what we have created is a walled garden with illusion of being open garden.

There is also question of the mission for Plasma Mobile,

As a Free software community, it is our mission to give users the option of retaining full control over their data. The choice for a mobile operating system should not be a choice between missing functions or forsaken privacy of user data and personal information. Plasma Mobile offers the ability to choose the services that are allowed to integrate deeply into the system. It will not share any data unless that is explicitly requested.

Where we aim that users have full control over their data and do not use closed systems.

Which is why we need to find a balance between both of this goals/mission. We need to make sure that our default user experience does not make use of closed ecosystem software and at same time if users/developers have preference or requirement of using other systems we enable them to do so to best of our capability.

Day #6 of the #100DaysToOffload series.

After a long break due to some personal stuff I am back to writing for #100DaysToOffload

Sunday, 11 April 2021

I wrote my first Season of KDE blog-post 3 months ago… and have since forgotten to write any updates. It’s time to address that!

Since January, I’ve been working mainly on improving the documentation for Kirigami. Back then, the Develop wiki had some pages teaching newcomers how to create a Kirigami application, but these were a little disjointed and didn’t really lead readers towards any specific goal.

There were also a lot of aspects and components of Kirigami that weren’t properly documented. Some of the existing materials also needed revising in terms of style, structure, and clarity.

Tutorials

Kirigami documentation in the KDE Develop site

Before Season of KDE I’d recently started tinkering with QML and Kirigami. I wanted to create a simple application that would let you count down the days towards a date, like those you can get on your phone, but without all the obnoxious ads. Since I had no real knowledge of these tools, I started following the tutorials on the KDE Develop wiki, which was a great way of finding out what the problems were with these tutorials.

I went with the idea of the date countdown app and used this as the final goal of the tutorial. If you read through the tutorials now, you’ll find that each page builds towards creating such an app. The new tutorials go over all the essentials that you would need to know to create a basic Kirigami application, covering everything from setting up the development environment, to how to use Kirigami components, to how QML signals work, and so on. Care has also been taken to explain concepts that a beginner developer might not know much about, such as the aforementioned signals. I point this out because I, as a beginner, did not know how signals worked. 😬

These new tutorials should make it quite a bit easier for new developers to come in and learn how a chunk of KDE development works. Hopefully we’ll soon have an influx of enthusiastic new developers bringing new applications to KDE, or helping out with our existing apps! 😀

These new tutorials can be found in the Kirigami section of the KDE Develop site. The project I had initially begun before SoK is now called DayKountdown and is part of the Plasma Mobile namespace!

DayKountdown in its starting view.

Beginners

Also helpful to beginners is a new page placed at the end of the new tutorials. This page has been designed to contain everything a newcomer might need or be interested in after creating their first Kirigami application.

Kirigami-based applications for newcomers

Taking a page out of GNOME’s newcomer guide, we have a dedicated section for new contributors. Provided is a summarised list of contribution guidelines, along with active projects that we recommend new developers can contribute to. These projects are organised in terms of complexity and feature useful links where readers can learn more about them. I hope these will encourage readers to become contributors!

There are now also a number of handy links to resources readers can use to learn more about the various tools used in KDE development. We’ve linked to some of the other tutorials available on the Develop wiki, as well as more general resources available elsewhere tackling C++ and Qt. Whereas before readers would have had to search for their own resources, now they will have an index of handpicked websites where they can go and learn more.

This page can be found here.

Component pages

Another big effort has been to expand the number of component pages in the Kirigami documentation. Previously, there have only been a limited number of components explained in the wiki, and as a result, new developers were never made aware of the breadth of components offered by Kirigami. A large part of the work in this Season of KDE project has been to address this problem.

With my last SoK merge request, we will go from having 3 component pages in the wiki to having 12! A range of cool Kirigami components now have their own pages, from inline messages to overlay sheets to form layouts and more. Carl Schwan and I are still working on polishing the merge request and getting it ready, but once it lands, it will really help the documentation take shape. The wiki should become much more useful for those interested in learning more about what they can create with Kirigami.

That’s not to say Kirigami is fully documented yet. It isn’t! But I think it’s a step in the right direction.

My time as a Season of KDE participant

6 months ago, I really didn’t know how to code at all. I’d written a lot about open source in the software in the past — I’ve advocated for it for a long time — but I never really knew how any of it worked.

I still don’t know how most things work, but I can definitely say I have learned a lot about KDE. Working on the Kirigami docs has been a very fun experience, partly because creating apps is fun in and of itself, but also because I can now grasp at how some of the applications on my computer have been made. That feels like a big-brain moment.

I must also thank my mentor Carl Schwan, who has been super helpful throughout these 3 months. Whether it has been combing over my ungainly merge requests, or reviewing the code for DayKountdown, his advice has been great and it has helped me become a (slightly) better coder.

Finally, it’s extremely fulfilling to have contributed to a software project that I have been using for the longest time. Thank you for merging my MRs!!!! I am sure there will be more of them to come, and I am looking forward refactoring lots and lots of my code 😀

 

 

Saturday, 10 April 2021

I recently updated Pixel Wheels banner image on Google Play. That triggered a review of the game: shortly after the update I received a message telling me Pixel Wheels was "not compliant with Google Play Policies". What nefarious activity does the game engage in? Sneak on users? Mine bitcoins?

Nope.

Something much more terrible, as evidenced by this screenshot they sent me:

Rejection screenshots

The Horror

Yes. I confess it. I added a link to my donation page within the game, depriving Google of some precious money it totally cannot survive without! How dare I?!? I am such a bad person.

Since there is no point arguing with them, I am going to have to build a Google Play flavor of the game, where this link is replaced with a link to the game page. Hopefully the Great Algorithm will accept that. We'll see.

Meanwhile you can still get the game from F-Droid or itch.io, since they do not have a problem with a link to a donation page.

This week the Wayland train continued barreling on, full speed ahead! We picked up a bunch of nice fixes and a big feature:

New Features

The “Activities” feature now mostly works on Wayland! There are a few remaining things to implement to make it 100% comparable to the X11 version, but that should get done in time for the next Major Plasma release (Kevin Ottens, Plasma 5.22)

Sticky Note widgets now have an option to change the font size (Shantanu Tushar, Plasma 5.22):

Bugfixes & Performance Improvements

Zooming in and out in Okular now works correctly when using the “Trim Margins” feature (Gerd Wachsmuth, Okular 21.04)

Media9 PDF movie annotations can once again be played in Okular (Albert Astals Cid, Okular 21.04)

When using Okular’s “Invert Luma/Lightness” setting, the loading page now retains its correct color (David Hurka, Okular 21.04)

Ark can now un-archive zip files with Windows-style backslashes used as path separators (João Silva, Ark 21.08)

Fixed a bug in the Breeze application style that could manifest as a big ugly black square appearing in KMail (Fabian Vogt, Plasma 5.18.8)

Fixed one way that Plasma could crash right after login (John Zimmermann, Plasma 5.21.4)

The Plasma Wayland session will no longer crash if you plug in an external screen while in a non-GUI session (e.g. a virtual terminal) (Jan Blackquill, Plasma 5.21.4)

The Bluetooth applet’s tooltip no longer displays the wrong name of the currently connected device. I originally fixed this 9 months ago in Plasma 5.19.1 but somehow the fix was never merged into Plasma 5.20, so it got broken again. That has now been corrected (me: Nate Graham with help from James John, Plasma 5.21.4)

Ultra-wide screens with a 21:9 aspect ratio are now displayed as “21:9” in System Settings’ Display Configuration page, rather than “64:27” (lol) (Felipe Kinoshita, Plasma 5.21.4)

Fixed one way that KWin could crash with certain low-power embedded GPUs (Vlad Zahorodnii, Plasma 5.21.5)

Maximized GTK app windows are no longer positioned too high in the Plasma Wayland session (Vlad Zahorodnii, Plasma 5.21.5)

Discover’s ability to show you an app’s dependencies now works again (Aleix Pol Gonzalez, Plasma 5.21.5)

Disconnecting a screen in the Plasma Wayland session no longer causes all Qt apps to crash (Vlad Zahorodnii, Plasma 5.22)

Global shortcuts are now working even on non-US keyboard layouts (Andrey Butirsky, Plasma 5.22 in conjunction with a Qt version that has this pending patch integrated)

Plasma no longer lags or hangs when displaying a massive number of tooltips for grouped Task Manager tasks (Aleksei Nikiforov, Plasma 5.22)

The kglobalaccel5 daemon can no longer block re-login by crashing on the previous log-out and then getting stuck (David Edmundson, Plasma 5.22 or Frameworks 5.82; whichever one you get first)

When using a multi-screen setup, the lock screen no longer only displays typed text on the text field of the left-most screen, even if you clicked on the text field on a different screen (Aleix Pol Gonzalez, Plasma 5.22)

The Task Manager’s “Highlight windows when hovering over tasks” feature now works in the Plasma Wayland session (David Redondo, Plasma 5.22)

Kate and other KTextEditor-based apps no longer crash if you delete an open file on disk and choose the “Close file, discarding contents” option in the warning message that appears in the app (Christoph Cullmann, Frameworks 5.82)

Fixed a rare case where Kate and other KTextEditor-based apps could crash when dragging text (Waqar Ahmed, Frameworks 5.82)

Context Menus for text fields inside Kirigami overlay sheets are no longer displayed below the sheet content (Noah Davis, Frameworks 5.82)

In Kate and other KTextEditor-based apps, the code completion pop-up no longer sometimes take up the whole screen width (Waqar Ahmed, Frameworks 5.82)

Text in Plasma tab buttons (such as in the new Kickoff menu) now gets elided when there’s not enough space, rather than overflowing (David Edmundson, Frameworks 5.82)

User Interface Improvements

Konsole’s “Edit Profile” window now displays errors inline, rather than using an ugly modal dialog window (Ahmad Samir, Konsole 21.04):

Okular’s “Continuous” mode is now considered to be a document-specific setting (like the zoom settings are), rather than a global setting (Mahmoud Khalil, Okular 21.08)

Items in the System Settings KWin Scripts now use the “pending deletion” pattern used in many other pages, whereby deleting an item only marks as it as in a “pending deletion” state and it only actually gets deleted when you click the “Apply” button (Alexander Lohnau, Plasma 5.22)

System Tray applets now receive keyboard focus when opened, so they can be interacted with using the keyboard (Eugene Popov, Plasma 5.22)

Hover buttons in the Clipboard System Tray applet’s list items are now top-aligned for tall ones, so that the trash button doesn’t shift around according to height, which makes it easy to click on that button repeatedly to manually prune your history list (me: Nate Graham, Plasma 5.22):

Discover no longer shows a huge weird rapidly-disappearing tooltip while loading the Updates page if the cursor is over any part of it (me: Nate Graham, Plasma 5.22)

The tooltip for the window decoration button used to keep a window above all others now makes its purpose more clear (me: Nate Graham, Plasma 5.22):

The previously somewhat confusing “Keyboard Indicator” applet has been renamed and given a UI overhaul to clarify what it is and what it does (Andrey Butirsky and me: Nate Graham, Plasma 5.22):

The Task Manager tooltip now visually indicates when it’s scrollable by displaying a visible scrollbar (me: Nate Graham, Plasma 5.22)

When using the systemwide double-click mode, it’s now possible to disable “click a selected file’s label to rename it” feature for desktop icons, just as it is in Dolphin (me: Nate Graham, Plasma 5.22)

Discover’s view of an app’s dependencies has received a visual overhaul and now also shows you the exact name of the package for the app in question and also groups the dependencies by installation status (Aleix Pol Gonzalez and me: Nate Graham, Plasma 5.22):

Looks like this will install all of GNOME; guess I don’t wanna do that

All the grid view pages in System Settings now sort items case-insensitively (me: Nate Graham and Alexander Lohnau, Plasma 5.22)

Plasma list items now have left and right margins that are consistent with their top and bottom margins (Noah Davis, Frameworks 5.82)

Various message dialogs throughout KDE software no longer display pointless tooltips saying, “Yes” and “No” when you hover your cursor over buttons whose own text may already be “Yes” and “No”! (me: Nate Graham, Frameworks 5.82)

Web Presence

Check out Niccolò’s video about how to set up a development environment and submit a merge request. Very handy for audiovisual learners!

…Read that as “dev env” not “ded end” lol

…And everything else

Keep in mind that this blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org/, where you can find blog posts by other KDE contributors detailing the work they’re doing.

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Saturday, 10 April 2021

KDE today announces the release of KDE Frameworks 5.81.0.

KDE Frameworks are 83 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version

Baloo

  • [SearchStore] Explicitly narrow timestamps for range query
  • Add now mandatory args parameter to QProcess::startDetached()
  • [MetadataMover] Update filename terms when moving/renaming file (bug 433116)

BluezQt

  • Fix unity compile support

Breeze Icons

  • Added branches with leaves to Kmymoney icon
  • Add a few symlinks for “configure” and “help-donate” (bug 435150)
  • Add KMyMoney Pie-Chart Icon
  • Link svn-* icons to new vcs-* icons
  • Add vcs-* icons for Kate
  • Make lock icon filled status consistent (bug 244542)
  • Remove 22 brightness icons in 16 size folder
  • Fix location of brightness icons
  • Add high-brightness and low-brightness icons

Extra CMake Modules

  • ECMGenerateExportHeader: do sanity check for version argument values
  • Fix warning about wayland-scanner code arg

KActivities

  • Activate activity manager asynchronously

KAuth

  • Un-overload HelperProxy::progressStep() signal

KCMUtils

  • Add loaded signal to KCModuleData to handle delayed loading

KCompletion

  • Un-overload KLineEdit::returnPressed(const QString &) signal => returnKeyPressed
  • Un-overload KCompletionBox::activated(const QString &) signal => textActivated
  • Un-overload KComboBox::returnPressed(const QString &) signal, by deprecating returnPressed()

KConfig

  • Relicense file to LGPL-2.0-or-later
  • kconfig_compiler: Explicitly open input file for reading
  • kconfig_compiler: change how paramString() creates strings

KConfigWidgets

  • Introduce KHamburgermenu (bug 368421)

KCoreAddons

  • Enable Unicode support in QRegularExpression where needed

KCrash

  • Document why we close FDs

KDED

  • Make kded shut down cleanly during systemd session teardown

KDELibs 4 Support

  • KComponentData: add a link to the KF5 porting notes

KFileMetaData

  • Enable Unicode support in QRegularExpression where needed

KGlobalAccel

  • Only use unistd/getuid when available
  • Don’t let kglobalaccel run if KDE_SESSION_UID mismatches

KHolidays

  • Make it compile with unity cmake support
  • Handle negative years in easter and pascha calculations (bug 434027)

KIconThemes

  • Revert “avoid race condition on loading the plugin”
  • Revert “add private header to avoid extern in .cpp file”
  • Don’t register our engine per default
  • More robust handling of missing global KDE themes
  • Ensure qrc + QDir::searchPaths work for icons (bug 434451)
  • More robust and complete setup of the scaled test environment
  • Produce output with the request devicePixelRatio
  • Properly render non-square icons
  • Remove the assumption that SVG icons are squares in icon loading
  • Retain non-square icon sizes in KIconEngine::actualSize()
  • Revert icon size behavior changes
  • Align handling of non-square icons with how Qt behaves

KIO

  • FileCopyJob: fix regression when copying a data: URL
  • Handle errors during xattr copy in a more robust way
  • Port ktelnetservice away from kdeinitexec
  • Handle .theme files correctly (bug 435176)
  • Remove KCoreDirListerCache::validUrl, let the job emit error instead
  • PreviewJob: Initialize cachesSize with 0, only pass size > 0 to shmget, improve createThumbnail (bug 430862)
  • KNewFileMenu: use destination side to stat destination (bug 429541)
  • MimeTypeFinderJob: don’t put job on hold for local files
  • FileCopyJob: port to the async AskUserActionInterface
  • Fix crash in ApplicationLauncherJob(service) when service is null
  • Don’t try to get mimetypes on empty urls
  • Fix appending file extensions in KFileWidget

Kirigami

  • Add a humanMoment unit to Kirigami.Units
  • Make the luma conversion of a color api accessible
  • Auto fire SearchField’s accepted, with optional extra delay (bug 435084)
  • Make globaltoolbar colorset customizable
  • Lower duration to change color for ActionButton
  • Fix focus handling in OverlaySheet to be managed as one FocusScope (bug 431295)
  • BasicListItem: partially silence binding loop
  • [FormLayout] Use layout boundaries on twin layout hints (bug 434383)
  • Make SwipeNavigator only allow the active page to be focused
  • Consider Ubuntu Touch to be mobile
  • [controls/Avatar]: Get rid of ‘both point size and pixel size’ set warning
  • Remove link to deprecated ApplicationHeader
  • the visible part should always at least be as tall as item (bug 433815)
  • Fix potential crash in SizeGroup (bug 434079)
  • turn contentItemParent into a FocusScope (bug 433991)

KJobWidgets

  • Introduce KUiServerV2JobTracker

KNewStuff

  • qtquickengine: Do not forward intermediate states
  • quickengine: Emit entryEvent signal with enum which is exposed to QML
  • Create a NewStuff.Action component, add NewStuff.Settings global
  • Less risk of infinite spinner on uninstalling KPackage based things (bug 434371)

KNotification

  • Relicense files to LGPL-2.0-or-later
  • Don’t close resident notifications when action is invoked
  • Implement inline replies on Android
  • Add an inline reply notification to the example
  • Add KNotificationReplyAction for using inline-reply Notification API

KParts

  • Add a new signal to replace the now deprecated completed(bool)

KRunner

  • Deprecate concept of delayed runners & related methods
  • Deprecate methods to remove matches in RunnerContext

KService

  • Deprecate KPluginInfo::fromKPartsInstanceName, completely unused

KTextEditor

  • Don’t warn about unsaved changes when closing if blank and unsaved (bug 391208)
  • Use QPalette::highlight for the scrollbar minimap slider (bug 434690)
  • Avoid gaps in indentation line drawing
  • Don’t use F9 & F10 as shortcuts
  • Use Okular’s QScroller settings
  • Add basic touchscreen support
  • [Vimode] Improve sentence text object
  • [Vimode] Fix paragraph text object in visual mode
  • Restrict horizontal range of cursor to avoid unintentionally wrapping (bug 423253)
  • Turn on line numbers & modification markers
  • Update remove-trailing-spaces modeline
  • Add option to keep spaces to the left of cursor when saving (bug 433455)
  • Remove unneeded options setting
  • Search: Enable Unicode support in QRegularExpression
  • [Vimode] Show search wrapepd hint for # and * motions
  • [Vimode] Use ViewPrivate::showSearchWrappedHint() for consistency;
  • Move showSearchWrappedHint() to KTextEditor::ViewPrivate
  • [Vimode] Only display “Search wrapped” message for n/N motions
  • Ensure we use unicode regex where needed
  • Fix spellcheck word detection for non-ASCII (bug 433673)
  • Fix auto-completion for non ASCII words (bug 433672)

KTextWidgets

  • Deprecate the KFind::highlight(int, int, int) signal
  • Deprecate the KFind::highlight(QString &, int, int) signal
  • Enable Unicode support in QRegularExpression where needed

KWallet Framework

  • Un-overload OrgKdeKWalletInterface::walletClosed(int) signal

KWayland

  • Bump required PlasmaWaylandProtocols
  • Fix DTD check errors and a typo
  • Add the activity management protocol client implementation

KWindowSystem

  • Add MediaPause key to mapping (bug 403636)

Plasma Framework

  • Deprecate AppletScript::description()
  • [widgets/arrows] Fix viewBox size and naturalSize in SvgItems
  • Add a humanMoment unit to the various Units
  • Add PageIndicator
  • [pluginloader] Add methods to list containments using KPluginMetaData
  • Deprecate PluginLoader::listEngineInfoByCategory
  • Mark Plasma Style as internal
  • Add notes about classes that will hopefully be dropped in KF6
  • [lineedit.svg] Remove empty space around borders and use 3px corner radius
  • [PC3 TextField] set on placeholder text
  • [PC3 TextField] mirrored -> control.mirrored
  • [PC3] Refactor TextField
  • Make compositing-off margins in the panel same size of compositing on
  • widgets>lineedit.svg: remove double ring
  • Change ContrastEffect check to AdaptiveTransparency in A.T. check (bug 434200)
  • Revert recent theme changes (bug 434202)
  • Port to singleton Units

QQC2StyleBridge

  • Respect highlighted property (bug 384989)
  • Fix size of toolbuttons
  • [DialogButtonBox] Improve implicit size behavior

Syntax Highlighting

  • LaTeX: allow Math env within another Math env
  • java: add assert and var keywords
  • cmake.xml: Updates for CMake 3.20
  • PHP: add preg_last_error_msg() function and classes that was previously a resource
  • Js: numeric separator ; fix Octal ; add new classes
  • Try to fix Qt 5.14 based compile
  • Make it possible to compile with Qt 6
  • Fix #5 and add Path style with alternate value (${xx:-/path/})
  • Python: add match and case keywords (Python 3.10)
  • Bump rust.xml to version 12
  • Do not spellcheck in Rust code
  • Markdown: add folding in sections
  • Fix BracketMatching color in Breeze Dark theme
  • Added more checking and number support
  • Added proper escaping support with error handling
  • Yet another DetectSpaces at MultiLineText
  • Removed Variable context; not needed
  • Added Error displaying for Placeables
  • Included ##Comments
  • Optimisations (DetectIdentifier, etc.)
  • Fixed Attribute handling
  • Added support for identifiers
  • Multiline text is now working
  • Added support for fluent language files
  • Add findloc Fortran function

ThreadWeaver

  • exception.h: fix export header include to work in namespace-prefixed include

Security information

The released code has been GPG-signed using the following key: pub rsa2048/58D0EE648A48B3BB 2016-09-05 David Faure faure@kde.org Primary key fingerprint: 53E6 B47B 45CE A3E0 D5B7 4577 58D0 EE64 8A48 B3BB