Monday

11 May, 2020

This landed in my mailbox today:

Notification Your Google Cloud Project api-project-XXX

Request Granted

Since I wrote about this back in january we have still had the occasional inquiry about the state of Kontact, KMail and Akonadi with regards to Google’s GMail service. The wheels over there grind very slowly, it seems, but eventually manage to make a full turn.

Dan Vrátil tells me that KMail can log into GMail again using OAuth, and this should become available to everyone automatically, no action to be taken.

Read about it at Reddit from Dan’s own pen.

This week, I introduced a new feature in DigiKam, that allows the user to reject the Face Suggestions made by the Facial Recognition Algorithm.

The Issue

Every Face Icon in DigiKam is provided with a useful Overlay whenever the user hovers over the Icon. The Overlay is convenient for the user to Confirm the Face Suggestions. However, currently there is a redundancy in functionality, since the ✖ and ⛔, both perform the same functionality, which is to delete the face from the database.

Instead it’s much more intuitive for the ⛔ button to perform the exact opposite of the ✅ button. It should “Reject” the suggestion, and not delete it!

The Implementations

I’ll try to explain my understanding of the DigiKam code-base, in the hopes that a future contributor finds this useful. Feel free to skip this section, if you just wish to find out about the new feature.

AssignNameOverlay is the class used to create the overlays, which consists of an AssignNameWidget. The AssignNameWidget holds the core confirm/reject buttons, as well as the Line Edit used to enter the Person name, and communicates with the Overlay through signals. At the top level, AssignNameOverlay is instantiated in DigikamItemView, which is responsible for the main view. All signals initially emitted by the Widget, eventually get connected to slots of the Item View.

The Reject signal of the AssignNameWidget, had been mapped to DigikamItemView::removeFaces(), which wasn’t ideal since the User only wishes to reject the face. Hence, I created a new method rejectFaces().

To implement rejectFaces(), I had to implement another method editTags() in FacePipeline, and it was all due to this helpful comment 😄

               else if (it->assignedRegion.isValid())
                {
                    add << FacePipelineFaceTagsIface(utils.changeRegion(*it, it->assignedRegion));

                    // not implemented: changing tag id
                }

Tiny as it may seem, this comment made me realize that a change in tagId from “Unconfirmed” to “Unknown”, is all that a rejection of suggestion really is!

The Feature

After all said and done, this is how the new feature turned out!

For sake of demonstration, assume that the face hovered over, is not the person suggested by the algorithm. I’ll proceed to Reject ⛔ this suggestion.

The suggestion is deleted, and the Face moves to Unknown! You can notice the changes in the counters as well.

Even though this feature is a fairly simple one, getting down into the code-base and understanding how everything comes together was really fun!


DigiKam is the ultimate cross-platform application for digital photo management. Download it for free! : https://www.digikam.org/download/

Everyone uses deevad's pics for Krita's building instructions 😄 Credits: David Revoy, CC-BY-4.0

Hi all! As part of our Community Bonding period, I wanted to share my experience setting up a development environment for Krita. We already have David Revoy’s post and the official, updated documentation. However, they only cover the setup process in Linux.

I’ll show you how to set Krita up in Visual Studio Code, under the three major desktop OSes: Linux, Windows, and macOS. For the latter two, I’ll show you how to use the same build scripts maintainers use for building the releases. We’ll take advantage of Visual Studio Code’s Tasks, so you do the hard work once, and then you’ll be able to compile dependencies AND run Krita in a few keystrokes!

Today’s post will tell you how to set Visual Studio Code up in Linux.


In the spirit of David’s post and Krita’s docs, this post has the following sections:

So, without further ado, let’s begin with Linux!

A warning: this is a distilled version of the official, updated documentation. It’s optimized to set you up under Visual Studio Code.

Preparing your development environment

As I’ve said previously, the process in Linux is really well documented, so I’ll go straight into the itty bits.

Credits: David Revoy, CC-BY-4.0

We’ll set up a main folder called krita in our home directory. Inside it, we’ll create the following subfolders:

  • $HOME/krita/build – the build files
  • $HOME/krita/install – the installation directory
mkdir ~/krita
cd ~/krita
mkdir ./build
mkdir ./install

Getting the Source Code

Credits: David Revoy, CC-BY-4.0

We’ll grab a copy of the source code from KDE’s GitLab instance. Install Git from your package manager, e.g. for Debian or Ubuntu, sudo apt-get install git, and sudo pacman -Syu git for Manjaro and Arch). Then, let’s go to our krita folder

cd ~/krita

and run:

git clone https://invent.kde.org/kde/krita.git src

Getting the Libraries

Credits: David Revoy, CC-BY-4.0

Each Linux distribution has its own way to get Krita’s dependencies. In Debian-based distros, you should be able to pull them all at once, by running:

sudo apt-get build-dep krita

For others, like Manjaro (the one I’m using right while writing this post), you’ll need to get the list of dependencies from your package manager. For instance, in Manjaro you can use the expac tool:

expac -S "%D %o" krita

We set the -S option to query the sync database itself, and the string "%D %o" tells expac to list all dependencies, both required (%d) and optional (%o). Now, you can feed the list to pacman for installation by running:

sudo pacman -Sy $(expac -S "%D %o" krita)

Before moving on, make sure you have a working compiler! In Debian-based distros, run:

sudo apt-get install build-essential

In Arch and derivatives,

sudo pacman -Sy base-devel

should do the trick.

Configuring the Build

Credits: David Revoy, CC-BY-4.0

This is, by far, the most difficult part of our journey. You must install first the CMake build system (sudo apt-get install cmake, sudo pacman -Sy cmake), and inside Visual Studio Code, the CMake Tools extension.

Now, open our krita folder under Visual Studio Code,

code ~/krita

open the Command Palette (Ctrl+Shift+P), and select Preferences: Open Workspace Settings (JSON).

A JSON file will open, where you can set this workspace’s preferences. These are its contents on my machine:

{
    "cmake.configureSettings": {
        "BUILD_TESTING": false,
        //"PYQT_SIP_DIR_OVERRIDE": "/usr/lib/python3.8/site-packages/PyQt5/bindings/",
        "BUILD_KRITA_QT_DESIGNER_PLUGINS": true,
    },
    "cmake.parallelJobs": 12,
    "cmake.configureOnOpen": true,
    "cmake.clearOutputBeforeBuild": true,
    "cmake.installPrefix": "${workspaceFolder}/install",
    "cmake.sourceDirectory": "${workspaceFolder}/src"
}
  • The cmake.configureSettings variable sets configuration-time environment variables.
    • BUILD_TESTING tells CMake to build Krita’s testing suite. I’ve set it to false so that it’s skipped.
    • PYQT_SIP_DIR_OVERRIDE is a fix you’ll need if you want to build Krita with Python support. Since Manjaro moves Python libraries where Krita cannot find them, I have to tell it where they are first. If you find this error: sip: Unable to find file "QtCore/QtCoremod.sip", uncomment this line.
    • BUILD_KRITA_QT_DESIGNER_PLUGINS tells CMake to build Krita’s UI components so that you can use them with Qt Designer. Disable if you won’t do UX development.
  • cmake.parallelJobs sets how many parallel jobs you want your CPU to run. Mine is a 8-core, 16-thread Ryzen box, so I set 12 to have some breathing space. Set to 0 if you want to let CMake decide.
  • cmake.configureOnOpen runs the configuration step every time you open this workspace.
  • cmake.clearOutputBeforeBuild cleans the Output tab before starting the build.
  • cmake.installPrefix tells CMake to install Krita to the ~/krita/install directory we created earlier.
  • cmake.sourceDirectory tells CMake where we cloned Krita’s repository to.
Credits: David Revoy, CC-BY-4.0

With everything set, open the Command Palette again, select CMake: Build Target, install, and off you go!

Running Krita

Credits: David Revoy, CC-BY-4.0

You’ll probably want to run Krita inside a debugger. Good news is that you can do it from the comfort of Visual Studio Code, through a Launch task!

Open the Command Palette again, and select Debug: Open launch.json. My configuration adds a target called (gdb) Start:

{
    // https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Start",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/install/bin/krita",
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [
                {
                    "name": "LD_LIBRARY_PATH",
                    "value": "${workspaceFolder}/install/lib/"
                }
            ],
            "externalConsole": false,
            "internalConsoleOptions": "openOnSessionStart",
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty printing for GDB",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
        }
    ]
}

The most important bits are:

  • program: it points to the krita executable, installed inside our install subdirectory;
  • environment: we have to show our debugger the right path to Krita’s libraries, through the LD_LIBRARY_PATH environment variable.

After this, you can launch Krita by just pressing F5! Or also by opening the Command Palette, and selecting Debug: Start Debugging.

Credits: David Revoy, CC-BY-4.0

Updating

Credits: David Revoy, CC-BY-4.0

Thanks to Git, this is really easy. Go to our src folder and pull the last changes:

cd ~/krita/src
git pull

If you have a branch, check it out first:

cd ~/krita/src
git checkout MY_BRANCH
git pull

Then build and install Krita. Open the Command Palette, select CMake: Build Target, install.

Troubleshooting

Credits: David Revoy, CC-BY-4.0
  • Sometimes, you’ll be unable to set Build tasks up. If this option doesn’t appear, it’s usually because your Visual Studio Code has User tasks already configured. Try opening the suggested “echo” task, delete it, and try again.

Tomorrow, I will tell you how to do these steps under macOS. If you experience any issues, please do ping me! amyspark @ #krita on Freenode.

Cheers,

~amyspark

Could you tell us something about yourself?

I’m Jeff, a brazilian animator and character designer (sometimes illustrator). I have a bachelor’s degree in biology and cinema, the latter one being completed in 2019, specialized in animation.

Do you paint professionally, as a hobby artist, or both?

Both, it’s a bit odd, you know, your profession and hobby all mixed together, I’m trying to get back to playing video games and trying to read more non-related things. It’s good to get a bit out of the bubble.

What genre(s) do you work in?

I love to draw animals and make creatures. But recently I’m drawing a lot of people to get better at it, normally some fantasy or superhero themes in urban context.

Whose work inspires you most — who are your role models as an artist?

Hmm, the first to come to mind is Chuck Jones, it was the first name I recognized again and again in cartoons and as a child I had thoughts like “he must be the most amazing guy” And after reading his book Chuck Amuck and The Noble Approach by Maurice Noble it turned out to be true.

How and when did you get to try digital painting for the first time?

My first experience was with an illustrator on a very bad “CGI” course. But what I liked the most was the flash. In this course I received classes in almost the entire suite of Adobe and Maya, all in 2007. In 2009 I went to college, on the biology course, and stopped studying animation and drawing. After 3 years of biology I returned to digital art with pixel art and vectors in inkscape and aseprite.

What makes you choose digital over traditional painting?

In the beginning it was fear, with pixel art and vectors I had all the control. After that was because of animation, doing 2d animation on paper needs a huge setup and you know what Uncle Ben said, “with big setups comes a big bill to pay”. Nowdays I still do animation, but I don’t make a choice, I do what each project needs, recently I directed a stop-motion short because it was the right language for the message.

How did you find out about Krita?

I use Linux as a main OS from time to time, in 2016 I was searching open source alternatives for drawing, back in the days I was using MyPaint, I never liked Gimp for drawing, so I used an “alternative” copy of other software, but not Photoshop, I never liked to draw with Photoshop. Then I found this piece of software that looked like a good alternative and tried. It fit all my expectations.

What was your first impression?

Wow, it’s like Photoshop, hey, the right click what…

What do you love about Krita?

Tough one. Can I say David Revoy? or Wolthera? I learned so much from those two. Ok, enough kidding, I love the layer management. I don’t have to use the mouse to quickly rename and organize everything, I worked in an office where I had to use Photoshop, and man, oh man, I suddenly realized why every artist ever who uses Photoshop doesn’t rename layers, it’s just terrible.

What do you think needs improvement in Krita? Is there anything that really annoys you?

The Windows port, it’s just slow. I had to get back to Windows a year ago and with a better configuration it’s slower than the Linux version. It was the most difficult thing I had to cope with when trying to make some friends get into krita, it’s like flipping a coin, sometimes it works, sometimes not.

What sets Krita apart from the other tools that you use?

The organization of the tools, whenever I’m teaching about Krita, I had the time to “get into the mindset”, you don’t need a tool for everything, open a dock and a tool has many ways.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

My static favourite is the version of the lofi girl I did for a twitter thread. I used all my knowledge of art and krita to make it: filter layers, g’mic, collage, masks, textures, brushes et cetera.

My animated favourite is a short animation about coffee making where I made a texture with used coffee filters.

Café from Jefferson Nascimento on Vimeo.

What techniques and brushes did you use in it?

I try to be simple. I use some layers, but not many and sometimes I use photobashing because I like to get the mixing of cartoons and photos. As for brushes, I love the recent pack of David Revoy. I like the rough ones, tons of texture in my line.

Where can people see more of your work?

Twitter: @jeff_lhama
Instagram: @jeff_lhama
Vimeo: jeffanimation
Behance: jeffsn

Anything else you’d like to share?

I have this story where I managed to install Krita, Blender and OpenToonz on all computers at the college. My college is UFPEL (Federal University of Pelotas), a public institution, there we have a lot of freedom to use the tool you want, for good and for bad at the same time. In my first semester, I made a small pen drive with all the necessary software; whenever we had some work to do in the classroom, I would turn on the unit and use one of them. Some teachers started asking me from time to time what I was doing and I explained all the advantages. In my second semester we had a great job, making a 2D animation short. At that point there was the addition of the animation tools to Krita and the launch of OpenToonz and I convinced my team to use them, because I was using Linux and I have no option of using flash, Toonboom or even Photoshop at home; therefore, for compatibility reasons, we had to work with these tools. At the moment, I already had a lot of knowledge about the tools, I had a YouTube channel about OpenToonz and Krita. So it was easy to get the team on the boat. After a while, one of the team colleagues asked the professor responsible for the software to install Krita and OpenToonz, because it would be easier to work on any computer. The professor came to me and we installed Krita, OpenToonz and Blender in two laboratories. After the end of the semester, at the beginning of the third, I was surprised, all the computers got Krita, OpenToonz and Blender. And I received invitations to hold workshops on the use of Krita and OpenToonz. Today, most of the short frame-by-frame animations made here are powered by Krita. (And a secret, I helped to change the 3d workflow from Max to Blender too)

Sunday

10 May, 2020

KDE Frameworks 5.70 was just released and should be trickling out to users of rolling release distros at any time. Various Arch users who have already received the update have been complaining about slow animations in Plasma, and I wanted to write a blog post to explain what’s going on here. It is a bit technical so let me start with the TL;DR version: “releasing software is complicated and this will be fixed once Plasma 5.19 comes out next month.”

For the longer version, allow me to explain:

This is caused by an unfortunate timing problem stemming from the different Plasma and Frameworks release schedules.

Plasma and Kirigami-based apps use standard duration values for animations (e.g. units.shortDuration, units.longDuration, etc.) to keep animation timings relatively consistent. These duration values are set in the respective Frameworks: plasma-framework and kirigami.

I recently discovered that Plasma units were far shorter than Kirigami units. For example a Kirigami units.longDuration unit is 250ms, while a Plasma units.longDuration unit was 120ms–over two times faster. A Kirigami units.shortDuration unit was 150ms, while a Plasma units.shortDuration unit was 24ms–almost too fast to see. In practice the Plasma units.shortDuration value was useless and always had to be multiplied by something. Even most of the longDuration values were being multiplied by random numbers too. So we wound with animated transitions throughout Plasma having timings like units.shortDuration * 4 or units.longDuration * 3. It was a classic problem of badly-chosen library constants that force apps to work around them and munge them this way and that, totally defeating defeated the purpose of using standardized values in the library in the first place. There was not actually any standardization at all!

I needed to fix this as a part of my introduction of a new animation-using component, the ExpandableListItem (which I keep meaning to blog about): https://phabricator.kde.org/D28033

I fixed the Plasma units to be the same as the Kirigami units in https://cgit.kde.org/plasma-framework.git/commit/?id=0739113a4477e1eb25bf13b0040af5a502d3ef0a, and then fixed Plasma itself to no longer multiply the units in a series of other commits. However this presented an issue: Plasma and Frameworks have different release schedules! So people will not get both aspects of the change at the same time! This means that for a time, some people would have animations that were undesirably slower or faster. How should this be handled?

Unfortunately there is no easy way to do conditionals depending on a frameworks version in QML code as we can in C++ code, so that easy option was not available. Probably something to look into implementing.

So we had a few options. One was to avoid solving the problem until Plasma 6, several years in the future, at which point we could do everything at once. This was not deemed satisfactory, as the issue was blocking the ExpandableListItem patch which was needed for a task targeted for Plasma 5.19. Another option was to leave the existing units alone for Plasma 5, and add new units with different names now, and have Plasma 5.19 use those new differently-named units. This would have avoided the issues you’re all experiencing, but would have resulted in terribly confusing code. In the end we decided to spare ourselves the potential for new bugs stemming from that.

The final option was to wait to make the Frameworks change in a Frameworks release that lines up as closely as possible with the Plasma 5.19 release. Plasma 5.19 depends on Frameworks 5.70, but always releases about a month later, at which point Frameworks 5.71 will be out. This option therefore presented two sub-options: put the units change in Frameworks 5.70 or 5.71?

If we did it in 5.70, there would be a one-month period in which people using rolling release distros suffer from slow animations, because they have Frameworks 5.70 but not Plasma 5.19 yet.

If we did it in 5.71, the period of time in which people suffered from this issue would still exist, but it would potentially be shorter. However depending on distro release schedules, if a distro released Plasma 5.19 *before* Frameworks 5.71, then animations would become too fast to see! Furthermore, any discrete release distro in the future that shipped Plasma 5.19 with the 5.70 Frameworks version it depends on rather than a newer one would then have all of its users suffer from the bug forever (or at least until its packagers backported the plasma-framework commit).

So shipping the units change in Frameworks 5.71 did not seem to be a realistic option. In the end I shipped the units change in Frameworks 5.70 knowing that rolling release distro users (myself included) would suffer from slow animations for one month. Sorry. 😦 It will all be fixed in Plasma 5.19.

Software is complicated!

After an anxious month, I am writing a Krita Weekly again and probably this would be my last one too, though I hope not. Let’s start by talking about bugs. Unlike the trend going about the last couple of months, the numbers have taken a serious dip.

by Akhil K Gangadharan and Valorie Zimmerman

The KDE Community welcomes our students for Google Summer Of Code 2020!

We are so grateful to the GSoC program for offering this opportunity to the KDE Community and our students. By the end of the summer, we hope that each of these students will be a confident KDE Developer, happy with their summer of work, and looking forward to supporting their code and newfound friends far into the future.

Krita is KDE’s professional free and open source painting program. The Krita team will mentor four students this year: L. E. Segovia will work on adding dynamic fill layers, Saurabh Kumar will implement a storyboard feature, Sharaf Zaman will bring SVG Mesh Gradients to Krita and Ashwin Dhakaita will integrate the MyPaint brush engine.

GCompris is a high quality educational software suite which includes a large number of activities for children aged 2 to 10. This year GCompris will have two students with Deepak Kumar adding multiple datasets to several activities and Shubham Mishra will complete the multiple dataset task.

digiKam is KDE’s professional photo management software. This year digiKam will be mentoring two students: Nghia Duong will bring DNN based face recognition improvements to the app and R Kartik will make improvements to the face management workflow.

Cantor, which lets you use your favorite mathematical applications from within a nice KDE-integrated worksheet interface, will mentor Nikita Sirgienko. Nikita will extend the usability and feature set of Cantor and Shubham will be working on integrated documentation in Cantor.

Kirogi, a ground control application for drones, will have Kitae Kim improve MAVLink integration. Aniket Kumar will work with KDE Connect, which enables communication between all your devices, to improve MMS support to the SMS client. Paritosh Sharma will implement the Qt3D backend for Kstars, KDE’s astronomy software.

Anuj Bansal will work on replacing OpenLDAP based authentication with OAuth2 in KDE Websites. Jean Lima Andrade will add support to text annotation in marK, a machine learning dataset annotation tool. Prasun Kumar will work with KMyMoney, a personal finance manager, to integrate SQLite format support for bank data. Davide Briani will work to bring WikiToLearn 2.0 (collaborative textbooks) to life. For Qt, Agisilaos Kounelis will Port QtQuickControls Calendar component to QtQuickControls2 module.

Also, Sashmitha Raghav will work to bring basic subtitling support to Kdenlive, KDE’s video editor; ROCS, a Graph Theory IDE, will have Dilson Guimarães improving graph visualization capabilities; Shashwat Jolly will to bring EteSync sync backend to Akonadi, a database to store, index and retrieve personal information.

Detailed reports from our students will follow later this summer as the program progresses. We wish all of our students and mentors a safe, productive and a successful summer.

Saturday

9 May, 2020

Since last year KDE’s KNotification framework has support for Android. And while that generally works, there were still a number of things to polish in order to improve the experience on Android, e.g. when using KDE Itinerary there.

Text Formatting

KNotification supports rich-text notification messages, while so far this resulted in a single line with HTML markup on Android.

  • Multi-line messages are enabled by D29323 which is part of KF 5.70. This also removes HTML markup in case we cannot display it.

  • Rich-text support in the notification message is added by D29357, assuming you have at least Android API level 24. This is still in review and should make it into KF 5.71.

KF5Notifications on Android showing a multi-line rich-text notification message.
Multi-line rich text notification message.

Updating Notifications

Still active notifications can be updated when the event they are about changed or more information becomes available. That’s way less bothersome for the user than issuing a new notification each time. KNotifications’ Android backend was however missing support for this until now, which is rectified by D29339, in time for KF 5.70.

Prioritization

In KF 5.58 KNotifications added support for specifying the urgency of a notification. This is a useful property in order to sort larger amount of notifications in a way that the most important ones receive the most attention. D29342 forwards this information to Android, and will become available with KF 5.71.

KF5Notifications on Android showing a low urgency message.
A low urgency notification shown at the very end of the notification list.

Grouping

Another useful approach for managing larger volumes of notifications is grouping. Notifications referring to similar events can be collapsed together saving space, while still allowing the user to drill down by expanding the group when needed. KNotifications supports this by flags to control whether a notification should be considered for grouping.

Android also has the concept of grouped notification, however it’s not as simple as just forwarding some settings, on Android notification grouping is under full control of the application. D29335 implements this based on KNotifications event ids, while considering the grouping flags when present.

That’s by far the most complex one of these patches, but the screenshots below show it’s worth it. In this example we have three delay notifications from KDE Itinerary, without grouping they would occupy a considerable amount of space, while the collapsed variant is hardly bigger than a single notification.

Three notifications of the same time summarized in a collapsed group.
A collapsed group of three notifications.

Fully expanded you still have access to all details, with the ability to discard individual notifications or the entire group by swiping.

Three grouped notifications shown in full in an expanded group.
An expanded group of three notifications showing all details.

Notification grouping on Android will hopefully make it into KF 5.71.

Lock Screen Visibility

The final patch D29358 deals with controlling the level of detail of a notification shown on the phone lock screen. The challenge here isn’t the Android implementation, but the lack of frontend API in KNotifications for this. That’s being looked into for Plasma Mobile, but isn’t available yet. So far now this is implemented as a custom hint on the notification.

KF5Notifications on Android showing a message on the phone lock screen with full content.
A notification shown on the lock screen with full content.

Obviously this feature is of great interest for KDE Itinerary, its gate/platform change notifications are most useful if you can also read them while rushing to catch your connection without the need of a full phone unlock procedure. Having an option to show them on the lock screen would therefore be nice to have.

Outlook

There’s more in the Android notification system that we haven’t connected to KNotification yet. Notification categories is one example, in-line reply is another one. For the latter we are also waiting for the corresponding XDG standardization to finalize the corresponding frontend API. There’s also settings for LED notification lights and vibration to look into.

Going further, there is the topic of abstracting launching of notification configuration dialogs. On Android that’s provided by the platform, on Plasma we can do both right now, in-app and out-of-process configuration. So this still needs some conceptual/API design work first.

This week a lot of work was put into improving the reliability of the “Get new [thing]” feature integrated into many KDE apps and System Settings pages. Also, several Wayland improvements landed, including subsurface clipping. Finally, a major Dolphin feature request was implemented, allowing the display of on-disk folder sizes! There are also scads of other things, so read the full list and be happy:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

We recently updated our documentation for how to build and run Plasma Mobile locally on your desktop machine: https://community.kde.org/Get_Involved/development#Plasma_Mobile. Plasma Mobile is really amazing and advancing at warp 9 speed, so please do check it out and see what all the fuss is about! More information can be found at https://www.plasma-mobile.org

More generally, have a look at https://community.kde.org/Get_Involved to discover ways to help 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.

KDE e.V. is a registered non-profit organization that represents the KDE Project in legal and financial matters. It is an association under German law, which means it has a board of directors. The board meets online weekly to discuss ongoing work – contractors, progress in working groups, external relations – and traditionally a few times a year in-person to deal with bigger jobs.

Akademy is one of those meetings, where we also meet with the community, our sponsors and advisory board and all our friends. We usually have two more, wherever there are board members (e.g. Berlin or Barcelona, right now).

With Akademy going online (CfP is open!) this year due to COVID-19, we still need to meet but doing so in-person would be irresponsible. So the board meeting is also online, using BigBlueButton which so far meets our needs for whiteboard, audio, and some video quite well.

The Board Meeting

Audio on FreeBSD is a bit of an issue for me – it gets choppy after about 10 minutes in Falkon, fixed by a reload. Things are fine on the Slimbook running openSUSE.

One of the things we talked about today is the annual general assembly, and how to do one properly online. Many German associations have that same problem, so we’ll be looking at expertise built up elsewhere for hints. For tomorrow we have a bunch of KDE e.V. internals on the schedule, including how we’re progressing with the current goals of the KDE community and what the e.V. can do to help.

Actually, if I look back almost exactly ten years there’s a lot of continuity in topics and care that the e.V. takes for the KDE community.

So here’s a toast to the e.V., for another ten years of stability (and perhaps silly screenshots from meetings).