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:
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:
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
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!
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.
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
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:
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)
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):
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!
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
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
veggero
TSDgeos
