Plasma 5.19 Beta

KDE Plasma 5.19 Beta

Thursday, 14 May 2020.

It's time to test the beta release for Plasma 5.19!

In this release, we have prioritized making Plasma more consistent, correcting and unifying designs of widgets and desktop elements; worked on giving you more control over your desktop by adding configuration options to the System Settings; and improved usability, making Plasma and its components easier to use and an overall more pleasurable experience.

Read on to discover all the new features and improvements of Plasma 5.19…

Plasma Desktop and Widgets



Rewritten System Monitor Widgets

Rewritten System Monitor Widgets



Consistent System Tray Applets

Consistent System Tray Applets



Completely New User Avatars

Completely New User Avatars



More consistent appearance for switching the current audio device

More consistent appearance for switching the current audio device

  • We have improved the panel spacer so that it can automatically center widgets
  • The System Monitor widgets have been rewritten from scratch
  • Plasma now has a consistent design and header area in system tray applets as well as notifications
  • We have refreshed the look of the media playback applet in the System Tray and of Task Manager tooltips
  • There are completely new photographic avatars to choose from
  • You can now see the name of the creator of a desktop wallpaper when you go to pick one
  • Sticky notes get usability improvements
  • You now have more control over the visibility of volume OSDs during certain situations
  • GTK 3 applications immediately apply a newly selected color scheme and GTK 2 applications no longer have broken colors
  • We have increased the default fixed-width font size from 9 to 10
  • More consistent appearance with less ugly UI for switching the current audio device


System Settings



Full System Settings App Is Now Launching



Redesigned Settings Pages

Redesigned Settings Pages

  • Default Applications, Online Accounts, Global Shortcuts, KWin Rules and Background Services settings pages have all been overhauled
  • When launching System Settings modules from within KRunner or the application launcher, the complete System Settings application launches on the page you asked for
  • The Display settings page now shows the aspect ratio for each available screen resolution
  • You now have more granular control over Plasma's animation speed
  • We have added configurable file indexing for individual directories and you can now disable indexing for hidden files
  • There is now an option that lets you configure the mouse and touchpad scroll speed under Wayland
  • We have made lots of small improvements to the font configuration


Info Center



Redesigned Info Center

Redesigned Info Center

  • The Info Center application has been redesigned with a look and feel that is consistent with the System Settings
  • It is now possible to see information about your graphics hardware


KWin Window Manager



Icon Recoloring in the Titlebar

Icon Recoloring in the Titlebar

  • The new subsurface clipping for Wayland greatly reduces the flickering in many applications
  • Icons in titlebars are now recolored to fit the color scheme instead of sometimes being hard to see
  • And in Wayland screen rotation now works for tablets and convertable laptops


Discover



Flatpak Repository Removal in Discover

Flatpak Repository Removal in Discover

  • Flatpak repositories in use are easier to remove now
  • Discover displays the application version for reviews
  • Discover improved its visual and usability consistency


KSysGuard

  • Our system monitor KSysGuard has gained support for systems with more than 12 CPU cores


Full Plasma 5.19 Beta changelog

Thursday

14 May, 2020

GSoC, KDE, EteSync logos

I am elated to be selected for GSoC with KDE! Through the program, I aim to dive deeper into open-source and utilize the mentorship to become a better contributor and member of the community. I am really excited to work on my project, EteSync sync backend for Akonadi.

About the project

Akonadi is the backend framework providing APIs for storage and retrieval of the user’s personal info such as contacts, email and calendar. These APIs are used by applications like Kontact, Kmail, KAddressBook and other apps in the KDE PIM suite. Akonadi also allows one to sync this data via a number of services like Google, Microsoft Exchange, DAV servers and many others.

My project is to add to this list a secure, end-to-end encrypted, FLOSS sync solution for contacts, calendars and tasks, called EteSync. EteSync clients are available for Android, iOS, the desktop (Cal/CardDAV bridge) and the web, and a Thunderbird plugin is in the works. The server too is open-source and can be self-hosted. As mentioned, EteSync utilizes end-to-end encryption, hence giving users the benefit of truly owning their data and respecting their privacy.

Plans for the work ahead

May 4 - June 1 is the Community Bonding period, where we are given time to interact with the community, get familiar with our project codebase and be ready to start work from June 1, when the coding phase starts. I have already been hanging out at the relevant IRC channels for quite some time, and I’ve had regular communication with my mentors (Tom “TAsn” Hacohen, Daniel Vrátil and Adriaan de Groot). I am taking this time to get used to reading all messages in some new IRC channels I’ve joined and interacting with fellow GSoC students (and also getting quickly done with college assignments :P).

I have laid out a detailed timeline for the work to be done, in my proposal.

About me

I’m Shashwat Jolly, a mathematics graduate from IIT Guwahati, India.

I’m well-versed with C++, and have made a few contributions to KDE PIM, which also introduced me to Qt. I’m pumped to get started with my project!

Apart from technical stuff, I’m very interested in all the latest and upcoming gadgets (mobiles, laptops etc). I’m into music, movies and twisty puzzles (Rubik’s cube and the like). If you’re also into any of this stuff, or even if not, I’m sjolly on IRC. Hoping to interact and learn from everyone in the KDE community!

With more and more events happening online I’ve been faced with dealing with headsets and microphones and things; the KDE e.V. board meeting this past weekend was one of them. Upcoming Akademy will be another.

One odd bit of kit I have is a Roland Edirol UA-4FX, an old – as in I fished it out of a dumpster – USB recording gadget. It’s cool in that you can hook up XLR cabled microphones and guitars and things to it, and it’s USB powered, and behaves as a recording and playback device. With that, I can switch away from a Logitech USB headset to a nicer set of cans and a mic with hardware on/off switching.

On Linux (openSUSE), the Edirol is recognized immediately and “just works”.

On FreeBSD, the “advanced” mode of the device isn’t recognized as an audio device at all, but the “normal” mode is. It shows up in various tools like this:

# usbconfig
ugen0.3: <EDIROL UA-4FX> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (360mA)
# cat /dev/sndstat
pcm4: <USB audio> (play/rec) default

So I have a little bit of mucking about to do, in order to figure out the difference between the two modes. For practical (i.e. my) purposes they should behave the same (thanks to various Ardour and ALSA sources for mentioning specifically the “advanced” mode).

One thing leads to another, and FMIT, the Free Musical Instrument Tuner, caught my eye because it was packaged for Flathub. It’s already packaged on FreeBSD, but not on openSUSE (I guess I’m supposed to snap or flap or app it there).

FMIT in Action

For just tuning an instrument this looks like a bit of overkill; I’m half-minded to take the internals and put a simpler UI on top so it takes less space. Maybe a plasmoid so I can tune my shrieking at C++ code (B sharp means someone ignored the compiler warning about missing return value).

Start with a lockdown; end up with two more projects on the “someday” pile.

Cutelyst the web framework based on Qt and SimpleMail the SMTP library got another update.

The current scenario has made me a lot less productive, after all 4 kids at home all the time it’s really hard to concentrate. Still many fixes and a few features have landed both.

Simple mail had issues building on Windows, and also got some docs fixes.

Cutelyst got some Session parameters available on config, an WebSocket improvement to avoid setting a null body to skip RenderView processing, and a new view called Cutelee.

This year I got a big project, one that is pushing scalability on Cutelyst further, but it also requires that things progresses faster, and this means Grantlee was starting to become an issue. A while ago it’s maintainer proposed to move it’s code to KDE, got my hopes high, but that got postponed to Qt6, I couldn’t wait for that and I also had an years old Pull Request waiting there, making in fact Cutelyst pages less safer as an escaping code wasn’t escaping one special character. A Cutelyst contributor also had patches pending there, I tried my best to avoid this, the author is a great programmer, did an awesome job but we needed something that can move a little faster.

Cutelee was born, and already have many commits, it also got some performance improvements, like not converting QDate(Time) to an string and converting back to use the :date “yy/dd” formater, another important change was that it can inject filters without the hassle of creating a Qt Plugin, putting it into the right and error prone directory hierarchy, %with% tag also supports the new Django syntax, and I hope we can keep improving it at a faster rate.

I didn’t do a new release of it yet, as some installation issues raised at Grantlee weren’t fixed yet on Cutelee.

Have fun

https://github.com/cutelyst/cutelyst/releases/tag/v2.11.0

https://github.com/cutelyst/simple-mail/releases/tag/v2.1.0

https://github.com/cutelyst/cutelee

Wednesday

13 May, 2020

Part 2 -

It’s been 10 days since the GSoC result was announced and it’s still beyond belief that I am selected for GSoC.

This Month is for community bonding and fortunately I already have quite good bonding with mentors. I am also utilising this time in learning some more git and QML and now I am planning to start reading code for all the activities on which I have to work this summer. So, I might disturb mentors a bit more from now :).

GCompris has been working on adding multiple datasets to activities for a long time and in this GSoC, I am taking forward my SoK work and adding multiple datasets to some more activities.

The activities I am going to deal with -

  • Sudoku
  • Share pieces of candies
  • Locate the region
  • Categorization
  • Gnumch equality
  • Gnumch inequality
  • Build the same model
  • find the details

That’s it for now, Keep checking this blog. I’ll keep sharing my progress here. In the meantime, checkout GCompris here link or directly install from Google Play Store.

Stay safe and have fun.

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

Hi again, everyone! This is the final post for this series, in which I’ll show you how to set Krita up in Visual Studio Code. For this post, we’ll cover the Windows operating system. I’ll show you how to take advantage of the same build scripts maintainers use for building the Windows releases.


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

So, without further ado, let’s begin!

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

Preparing your development environment

Credits: David Revoy, CC-BY-4.0

We’ll set up a main folder called krita in one of our drives, for instance C:\.

mkdir C:\krita

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 the Windows version of Git from git-scm.com. Then, let’s go to our krita folder,

cd C:\krita

and run:

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

If you already have a copy, skip the above and let’s check it’s properly updated:

cd src
git pull

Getting the Compiler and Python

Credits: David Revoy, CC-BY-4.0

Compiling in Windows is special, because Krita doesn’t use Microsoft’s compiler. We use instead a port of GCC called mingw-w64. We’ll grab version 7.3 (by mingw-builds) from the KDE FTP site. Uncompress this file to a subdirectory named toolchain inside our krita folder.

Next, we’ll set up Python. As of the writing of this post, we use version 3.8.1 exactly. Go to its download page, download the installer that matches the architecture you’ll compile for (which is almost always 64-bit), and install it.

Finally, the most difficult of our prerequisites is… Windows SDK. You can get it through the Visual Studio Installer, or by going to the Windows Dev Center. After installation, make sure the following environment variables are set:

  • WindowsSdkDir: typically set to C:\Program Files (x86)\Windows Kits\10;
  • WindowsSdkVerBinPath: typically set to C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0, where 10.0.18362.0 is the version of the SDK that you installed.

Configuring the Build

Credits: David Revoy, CC-BY-4.0

This was the most difficult part in our Linux journey. However, in Windows, we can skip a lot of the hard work by setting up Build tasks! You must install first the CMake build system.

Do not use the CMake Tools extension here; it will really complicate things.

Now, open our krita folder under Visual Studio Code,

code ~/krita

open the Command Palette (Ctrl+Shift+P), select Tasks: Configure Tasks, then Create tasks.json file from template.

A JSON file will open. Replace its contents with the following:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Krita",
            "type": "shell",
            "args": [
                "--no-interactive",
                "--skip-deps",
                "--jobs",
                "12",
            ],
            "options": {
                "cwd": "${workspaceFolder}",
                "shell": {
                    "executable": "${env:SYSTEMROOT}\\system32\\cmd.exe",
                    "args": [
                        "/C"
                    ]
                },
                "env": {
                    "PATH": "${workspaceFolder}\\toolchain\\bin;${env:PATH}"
                },
            },
            "command": "${workspaceFolder}\\src\\build-tools\\windows\\build.cmd",
            "detail": "Compile Krita with the official script",
            "group": "build"
        },
        {
            "label": "Dependencies",
            "type": "shell",
            "args": [
                "--no-interactive",
                "--skip-krita",
                "--jobs",
                "12",
            ],
            "options": {
                "cwd": "${workspaceFolder}",
                "shell": {
                    "executable": "${env:SYSTEMROOT}\\system32\\cmd.exe",
                    "args": [
                        "/C"
                    ]
                },
                "env": {
                    "PATH": "${workspaceFolder}\\toolchain\\bin;${env:PATH}"
                },
            },
            "command": "${workspaceFolder}\\src\\build-tools\\windows\\build.cmd",
            "detail": "Compile dependencies with the official script",
            "group": "build"
        }
    ]
}

We have added two tasks called “Dependencies” and “Krita”, that use the script, build.cmd.

  • We have added our MinGW installation to the PATH by setting it in the task’s options.env value.
  • We have set the working directory (cwd) to ${workspaceFolder}, because build.cmd expects to be run from the krita` folder.
  • The script has the following arguments:
    • --no-interactive uses default paths and goes straight to the build process.
    • --skip-krita and --skip-deps skips building Krita and dependencies, respectively.
    • --jobs 12 tells CMake to build dependencies using 12 threads. You can adjust it to your tastes, or remove it to let the script autodetect the number of available threads.
Credits: David Revoy, CC-BY-4.0

That’s it! Open the Command Palette again, select Tasks: Run Build Task (or press Ctrl+Shift+B), and run:

  1. First, the Dependencies task.
  2. Then, the Krita task. 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}\\i\\bin\\krita.exe",
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [
                {
                    "name": "PATH",
                    "value": "${workspaceFolder}\\i_deps\\bin\\;${workspaceFolder}\\toolchain\\bin;${env:PATH}"
                }
            ],
            "MIMode": "gdb",
            "miDebuggerPath": "${workspaceFolder}\\toolchain\\bin\\gdb.exe",
            "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 PATH environment variable.
  • miDebuggerPath: we have to use the gdb executable that comes bundled with our copy of MinGW.

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
  • Building dependencies through the scripts need a working Internet connection. Please check you have one before trying!
  • 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.
  • To set environment variables, open the Start menu, then select Run, and enter rundll32 sysdm.cpl,EditEnvironmentVariables .
  • Make sure that the version of Python we’re using comes first in your PATH, for instance, by setting it up in the Build task. Do not set the PYTHONHOME or PYTHONPATH environment variables.
  • Make sure all the variables are properly set! If not, the dependencies build process WILL fail with the most strange errors.

That is all for this process! Remember, if you experience any issues, please do ping me, amyspark @ #krita on Freenode.

Cheers,

~amyspark

Use freely available sources of data, add the right tools and a bit of simple analysis and you will be able to figure out whether your Free Software project is being adopted at a healthy rate or not. Bonus track: Find out when to post to social media.

Hi! Today, I am bringing some good news. The Google Summer of Code 2020 results were announced and I was accepted as a student!

I am excited and grateful for this opportunity that KDE community has given to me and I will focus to do an excellent work during this project. 🙂

I  will be working on marK, a machine learning dataset annotation tool, which I have already contributed during Season of KDE 2020. If you don’t know about it, please check my status report.

And here is a brief description about what I am going to do during this program and an explanation about some of my plans to accomplish all the objectives:

Improving marK codebase

I will improve the codebase of mark to make it extensible, making easier to add new types of annotation, e.g. text and audio annotation. To accomplish that, I will separate the image annotation logic from the current codebase, and improve wherever possible. The new core of marK will take care of different tasks related to annotation of multiple types of data.

Implementing text annotation support

Sketchy idea of how text annotation may be in marK

First, I will explain a bit about text annotation, which is the task of labeling text-based data. It involves the process of highlighting and tagging the desired terms in a document or text and its result can be used to train machine learning models for different purposes, e.g. entity linking and text classification.

For now, marK only supports image annotation. After finishing the aforementioned objective, I will add support to text annotation, using some Qt and KF5 structures for text manipulation, such as KTextEditor. These APIs are going to be helpful as I will integrate them with new components that will handle tasks related to text annotation such as labelling.

To provide a visualization of how the annotated output will be, here is how I am planning to serialize its JSON, which will be similar to the format that is current being used for image annotation:

Conclusion

It is worth mentioning that I will take advantage of the first phase of GSoC to study more about how text annotation works and improve my knowledge about Qt, software engineering (more specifically how to write good, maintainable code)  and, of course, bond with the community.

My GSoC experiences and progress will be published in this blog, also my proposal can be found here.

That is it, see you in the next post 😉

Tuesday

12 May, 2020

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

Hi again! This is the second installment of this series. Today’s post will cover how to set Krita up in Visual Studio Code, under macOS. I’ll show you how to take advantage of the same build scripts Iván and Boudewijn use for building the Mac releases.


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

So, without further ado, let’s begin!

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

Credits: David Revoy, CC-BY-4.0

We’ll set up a main folder called krita-mac in our home directory.

mkdir ~/krita-mac

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. Git should already come with macOS, otherwise you can install a (newer) version by using Homebrew and issuing:

brew install git

Then, let’s go to our krita-mac folder

cd ~/krita-mac

and run:

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

Getting the Compiler

Credits: David Revoy, CC-BY-4.0

To compile Krita, you will need a copy of Apple’s Xcode. You can install it through the Mac App Store, or by going to the Apple Developer site and clicking on “View in Mac App Store”.

To check if it’s properly installed (it’s a big download), you can use the xcode-select tool:

xcode-select --print-path

It should output: /Applications/Xcode.app/Contents/Developer

Configuring the Build

Credits: David Revoy, CC-BY-4.0

This was the most difficult part in our Linux journey. However, like we did on Windows, we can skip a lot of the hard work by setting up Build tasks! You must install first the CMake build system.

Do not use the CMake Tools extension here; it will really complicate things.

Now, open our krita folder under Visual Studio Code,

code ~/krita

open the Command Palette (Ctrl+Shift+P), select Tasks: Configure Tasks, then Create tasks.json file from template.

A JSON file will open. Replace its contents with the following:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Krita",
            "type": "shell",
            "args": [
                "buildinstall"
            ],
            "options": {
                "cwd": "${workspaceFolder}",
                "env": {
                    "BUILDROOT": "${workspaceFolder}",
                    "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
                }
            },
            "command": "${workspaceFolder}/krita/packaging/macos/osxbuild.sh",
            "detail": "Compile Krita with the official script",
            "group": "build",
        },
        {
            "label": "Dependencies",
            "type": "shell",
            "args": [
                "builddeps"
            ],
            "options": {
                "cwd": "${workspaceFolder}",
                "env": {
                    "BUILDROOT": "${workspaceFolder}",
                    "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
                }
            },
            "command": "${workspaceFolder}/krita/packaging/macos/osxbuild.sh",
            "detail": "Compile dependencies with the official script",
            "group": "build",
        }
    ]
}

We have added two tasks called “Dependencies” and “Krita”, that use Iván’s script, osxbuild.sh.

  • We have cleaned the PATH by setting it to Apple’s defaults. This helps prevent conflicts with dependencies you may have installed through Homebrew.
  • We have set the working directory (cwd) and the BUILDROOT to ${workspaceFolder}, because osxbuild.sh expects to be run from the krita` folder.
  • The script has only two subcommands:
    • builddeps builds dependencies,
    • buildinstall builds and installs Krita.
Credits: David Revoy, CC-BY-4.0

That’s it! Open the Command Palette again, select Tasks: Run Build Task (or press Ctrl+Shift+B), and run:

  1. First, the Dependencies task.
  2. Then, the Krita task. 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": "(lldb) Start",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/i/bin/krita.app/Contents/MacOS/krita",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "lldb"
        }
    ]
}

The most important bit is:

  • program: it points to the krita executable, installed inside our install subdirectory.

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-mac/krita
git pull

If you have a branch, check it out first:

cd ~/krita-mac/krita
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
  • Building dependencies through the scripts need a working Internet connection. Please check you have one before trying!
  • Currently, osxbuild.sh doesn’t print anything to console. You can, however, look at the build progress by tail -f ~/krita-mac/osxbuild.log.
  • 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.
  • Do not try to build Krita with dependencies installed through Homebrew, because they will conflict with the build script.

In the final post of this series, tomorrow, we will cover Windows. Remember, if you experience any issues, please do ping me! amyspark @ #krita on Freenode.

Cheers,

~amyspark