Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content Planet KDE
Planet KDE
Updated: 1 hour 5 min ago

Phase 1 Evaluation Status Report

Monday 29th of June 2020 11:05:00 AM
It has been over a month since the start of GSoC. Phase #1 evaluations will start today. This post is to summarise all the work done by me during phase #1

Implementing the MyPaint Brush engine This involved writing the core brush engine classes like KisMyPaintBrush, KisMyPaintSurface, MyPaintOpPlugin, KisMyPaintOp and KisMyPaintOpFactory. At a very high level, all I had to do was override the draw_dab and get_color methods of MyPaintBrushSurface with my own version to draw over a Krita Paintdevice (Krita Surface class). While working on this, I faced a problem related to lagging that I have discussed in the previous posts. With the help of my mentors, I was able to solve this and bring the lag under acceptable limits. Then, I went on to fix some bugs, which occurred in using some specific presets. The brush engine seems to work fine mostly =]
Particules


Calligraphy                                                                       Loading MyPaint Brushes This was the second most important thing in my TODO. The mypaint brush engine would be of no use if it can load the installed mypaint brushes from the system. Also, testing the brush engine was a pain if you base off all your testing work on the default brush. This thing was much needed from the start of the project itself.
Loaded MyPaint brushes
Hopefully, I will pass this evaluation. Don't know. 
Till then, Good Bye :)

  

OpenUK Awards Close Tomorrow

Monday 29th of June 2020 09:52:56 AM
OpenUK Awards are nearly closed. Do you know of projects that deserve recognition?   Openuk.uk/awards Entries close midnight ending UTC tomorrow   Individual, young person or open source software, open Hardware or open data project or company   The awards are open to individuals resident in the UK in the last year and projects and organisations with notable open source contributions from individuals resident in the UK in the last year.

Qt Visual Studio Tools 2.5.2 Released

Monday 29th of June 2020 06:30:00 AM

We are happy to announce the release of the Qt Visual Studio Tools version 2.5.2. Installation packages are now available at the Visual Studio Marketplace.

SPDX and the KDE FLA

Sunday 28th of June 2020 10:00:00 PM

KDE repositories are switching over to SPDX identifiers following the REUSE.software specifications. This machine-readable form of licensing information pushes for more consistency in licensing and licensing information.

Long, long ago I wrote some kind of license-checker for KDE sources, as part of the English Breakfast Network. The world has moved on since then, and supply-chains increasingly want to know licensing details: specifically, what exact license is in use (avoiding variations in wording that have cropped up) and what license-performative actions are needed exactly (like in the BSD license family, “reproduce the Copyright notice above”).

Andreas Cord-Landwehr has been chasing license information in KDE source code recently, and has re-done tooling and overall made things better. So there’s now changes – via merge requests on our GitLab instance KDE invent – showing up.

There is one minor thing of note which I’ve discussed with him, and which bears upon the Fiduciary License Agreement (FLA) that KDE e.V. has.

The FLA is a voluntary license agreement that individual contributors can enter into, which assigns such rights (remember, Free Software leverages Copyright!) as are assignable, to the fiduciary, and the fiduciary grants a broad license back. This leverages Copyright laws again, to ensure that the fiduciary can act as copyright holder, while leaving the original contributor with (almost) all the original possibilities for using and sharing the contribution.

I’ll be giving a short talk about the FLA at this year’s online KDE Akademy, so I’ll skip a bunch of general background information.

Since I signed the FLA quite some time ago, with the intent that KDE e.V. is the fiduciary – and therefore the holder of my Copyrights in a bunch of KDE code – Andreas has been converting my statements of copyright like this:

SPDX-FileCopyrightText: 2010 KDE e.V. <kde-ev-board@kde.org> SPDX-FileContributor: 2010 Adriaan de Groot <groot@kde.org>

I don’t hold this copyright: the KDE e.V. does. But I’m still morally the author and contributor in this file, so my name is in the file.This is a combination of SPDX tags you’ll probably see more of in the (gradual) conversion of KDE sources to using SPDX tags.

Many other projects also used SPDX statements and follow the REUSE specification: Calamares (a non-KDE project where I’m the maintainer) is slowly switching over, and I have some other projects elsewhere that are following suit. In greenfields (new) code it’s easy to stick to REUSE from the start, but retro-fitting it to an existing codebase can lead to a lot of tedious busywork, so none of my other projects have gone whole-hog over – none of them are “REUSE compliant”, so to speak.

I admire, and salute, Andreas for his dedication to improving the quality of KDE’s codebase in this (tedious and busyworky) way.

Edit 2020-06-29: salute the right name

Cantor Integrated Documentation : Week 3 and 4 Progress

Sunday 28th of June 2020 06:33:00 PM
Hello KDE people. First phase evaluations is due from today onward until 3rd of July. It has been coupe of weeks since I had posted about my project. I was quite busy writing code implementing the documentation panel for the various backends supported by Cantor. In the last post I have explained about how I generated the help files namely qhc (Qt Help Collection) and qch (Qt Compressed Help) from the documentation's source file. In today's post I will explain how I utilized Maxima's help files to actually display help inside the Cantor application itself. So here are the things done:- Things Done 1. Implementation of Documentation Panel Cantor has dedicated panels for Variable manager and some general Help. So I have created a new panel dedicated to display the documentation of the backend which is currently active. To implement it, I have borrowed some basic code from the cantor/src/panelplugins and added widgets similar to any documentation help. I have added tabs for displaying Contents, Index and Search for the documentation. These widgets are populated by loading the help files using a QHelpEngine instance. Currently, Search functionality is yet to be implemented.
2. Display of documentation inside the Documentation Panel I have kept the design as simple as possible. I have divided the display area into 2 halves, one half is the QTabWidget which displays the above listed widgets and the other half is the QWebEngineView, which I am using as a display area for the contents of the documentation. To make the display responsive to the events on the QTabWidget, I have connected the signals of the index and content widget to a slot which displays the contents in the View. 3. Context Sensitive Search Capabilities I have successfully implemented the Context Sensitive Search capability. The user can now while in the worksheet, can select any keyword and then press F2 to show the relevant documentation about that topic. The QWebEngineView updates in real time.
User selected 'sin' and then pressed F2 to forward to the related documentation On pressing F2 key while 'sin' keyword was selected, the index was filtered and the corresponding topic documentation was shown in the view area. 
For those interested in trying it out themselves and/or playing with the code, can clone my repository and build it from source. Here is the link to my repository on which I am working.
That's all folks for this time, until then, Good bye!!

GSoC'20 with KDE

Sunday 28th of June 2020 06:30:00 PM
Part 1 -

With the first month of the coding period almost over, I have been working on completing the first part of my GSoC project.

I have been porting kde.org to hugo. The website is very old and has lots and lots of pages. It is even older than me! I have been working on porting these pages to markdown removing the old PHP syntax and adding improvements to the design, responsiveness and accessibility of the website.

I have completed porting the announcements upto the year 2013. I ported the year 2014 as well but I replaced the formatted links into normal ones but I didn’t realise It would break the translations for the pages. So I may have to port these announcements again :( . KDE provides a pot file to its translators and they provide translations in a po file in return. We use a custom extraction script to extract the strings to be translated from the markdown files. The translator is smart enough to ignore some changes to the strings but the changes to the links that I made would break it. It also doesn’t work well with HTML that isn’t inline. I will keep these things in mind in the future.

I am also working on automating (RegEx is Awesome!) much of the work involved in porting these files which may make up for the time lost.

About my Project

The project involves improving KDE Web Infrastructure. KDE has a lot of websites and some of them like the main website could use an update.

The first part of the project involves porting kde.org to use Hugo- A go based static site generator. kde.org is very old and thus contains a lot of pages. This project would involve porting most of the pages to markdown so as to make the website faster and easier to develop.

The second part of the project involves updating Season of KDE website. The goal is to use more modern tooling and add some new features. This project is a part of the transition of KDE websites from LDAP to OAuth based authentication. OAuth is a much more modern approach to authentication and would solve some headaches with the current authentication system.

Current Working Repository: kde.org repo

If you would to join in, Say Hi at #kde-www on irc or telegram.

KDE Connect SMS App (First Evaluation)

Sunday 28th of June 2020 04:14:45 PM

Hi Everyone! It’s been a while since my last post and during this period I continued adding MMS support in KDE Connect SMS app. After the addition of MMS support in android app, My next step was to enable the desktop SMS client to allow users to reply to multi-target messages. I had some discussion with my mentors related to the structure of the network packets to allow sending multimedia files from android to desktop. Since the Attachment field should be an optional field and replacing the current packet type entirely was not feasible keeping in mind the backward compatibility for the desktop app. Simon suggested a nice idea of converting the thumbnails into Base64 encoded string and then adding it into the network packet. This solved the issue of replacing the entire method of pushing the messages to the desktop.

After successfully completing and testing the code on android studio, I added the support to receive and display the optional attachment object on the desktop side. The desktop side was mostly straight forward except transferring the QImage from C++ to QML but at the end I figured it out.

This brings us to my last task of this period i.e. requesting the original attachment file when a user will click on the thumbnail. The click event generates a attachment request packet and send to remote device. Android on the other side on receiving the request packet fetches the requested attachment file from the MMS database and send it to the desktop. Then desktop downloads the file and stores it locally for the future references.

This would not have been possible without the guidance and support of my mentors Simon, Philip, Nicolas and Piyush.

Changelog: Nitrux 1.3.0

Sunday 28th of June 2020 09:41:24 AM

Today is the day! — Nitrux 1.3.0 is available to download

We are pleased to announce the launch of Nitrux 1.3.0. This new version brings together the latest software updates, bug fixes, performance improvements, and ready-to-use hardware support.

Nitrux 1.3.0 is available for immediate download.

What’s new
  • We’ve upgraded the kernel to version 5.6.0-1017.

  • We’ve updated KDE Plasma to version 5.19.2, KDE Frameworks to version 5.71.0, KDE Applications to version 20.04.02.
  • We’ve updated the GTK theme to match closer the Kvantum theme and the Plasma color scheme.
  • We’ve updated the SDDM theme and Plasma look and feel package too (splash, and lock screen) with the colors of the color scheme.
  • We’ve added more wallpapers to our default selection, including our new default wallpaper Opal.

  • Inkscape is updated to version 1.0, and Firefox to version 77.0.1.
  • We’ve updated the Nvidia driver and its libraries to version 440.100.
  • appimage-cli-tool is replaced with its newer version appimage-manager. This new version of appimage-manager is rewritten in Go.
  • We’ve added a new AppImage to the system, Wine.
  • We’ve added a Day/Night wallpaper plugin, which allows users to simulate the color transition of the background to match the daylight. Thanks to dark-eye for the wallpaper plugin.
  • We’ve changed the default font from Chivo to Fira Sans for a more modern look and readability.
Known issues
  • Resizing a window from the top-right corner doesn’t work, this is a problem with the Aurorae decoration; we will be using a native QStyle window decoration to replace it in future releases.
  • When using the tiling windows feature (Khronkite), the system tray plasmoids will be treated as regular windows.
Notes
  • OpenGL acceleration is used by default, if you use Nitrux in a VM open System Settings>Monitor>Compositor and select XRandr in addition to disabling desktop effects like Blur.

The post Changelog: Nitrux 1.3.0 appeared first on Nitrux — #YourNextOS.

GSoC 2020 and KDE

Sunday 28th of June 2020 12:00:00 AM

Tomorrow (29/06/2020) begins the first evaluation of the Google Summer of Code 2020. Last GSoC, when I was participating as a student, I wrote in my final report a set of future proposals that could be done in the ROCS graph IDE (Section What’s Next?). This year, some students got interested in these ideas but only one could enter the program (we didn’t have enough mentors for more than one project). Here are the list that I proposed:

  • Implementation of a better algorithm to position the nodes and edges on the plane. I can recommend the use of Force-directed graph drawing algorithms, because they are usually fast and are physics-based;
  • Create a better interface workflow for the program. I can recommend something like the Possible New Configuration image. This configuration consider that the user will spend most part of the time programming, so it creates a better writing space, while the view has a more square shape, which is (in my opinion), better for visualization;
  • Remodelation of how each graph is represented in the javascript code. The type system is good to provide a global configuration, but I think it falls apart when dealing with individual edges and dynamic creation of subgraphs and new edges/nodes (which is needed in some algorithms);
  • Rewrite the view to deal with some problems related to the space of the graphs that is really limited, mouse clicks not working correctly and bad navigation;
  • Change how the icons are used by the ROCS, as some icons don’t have cross-compatibility between some systems.

From this list, Dilson decided to tackle the first one listed. Here is his proposal. Most of the best algorithms involves some type of heuristic inspired in physical motions in the graph, being really fast and good in most graph classes (although there is specialized algorithms for some graph classes). You can see more of his work here. He is doing a great job by showing a good understanding of the algorithms and methods while giving a great amount of thought in the test process (as it is not trivial to test random algorithms).

For now, he implemented a layout algorithm that is an adaptation of the Fruchtermani-Reingold algorithm that works only on connected graphs in a special plugin that controls each physical forces inside the model. I will be giving some updates on his work sparsely in this blog. Please check his blog for more details if interested. :)

KSysGuard

Saturday 27th of June 2020 10:00:00 PM

Packaging a big stack like the software from the KDE community – Frameworks, Plasma, and all the applications and libraries and tools from the KDE Release Service – takes a fair bit of time and energy. The KDE-FreeBSD team works on both packaging and porting – making sure that KDE applications behave well on FreeBSD just like on other operating systems.

The majority of the work of compatibility happens in Qt, which is also maintained by the KDE-FreeBSD team. Then the KDE frameworks – 80 or so libraries that are small, lightweight, tiered-so-you-know-about-dependencies and LGPL-licensed – pile a bunch of compatibility on top of that for desktop purposes.

But sometimes, an application needs to dig into the system itself. A text editor edits text regardless of the underlying system, but a memory-usage monitor needs to know how to ask the OS about memory-usage.

So this week I spent a fair bit of time in the KSysGuard codebase, because there’s a FreeBSD bug report that says that the memory-usage monitor shows nothing, and another report that says the graph and the status bar don’t match.

This isn’t the first time: apparently in 2009 I did some work on KSysGuard for OpenSolaris. Different times.

Something that has vaguely bugging me since 2017 is the display of micro-kibibytes in KSysGuard. A micro-kibibyte is one one-hundred-and-twenty-secondth of a single bit – let’s call it a centibit – and that is not useful as a measure of memory usage.

It turns out that in 2016, when porting from KLocale (a kdelibs4-era class) to QLocale, some edge cases were missed. Porting is rarely simple. So today I reintroduced the relevant bits, and in the spirit of modern C++ replaced some magic numbers by static constexpr const int values. As a result, KSysGuard tooltips no longer annoy me (assuming the MRs are accepted over on KDE invent).

And then I looked at the upstream bug list, and fixed a buffer overflow if you have implausibly long disk-device names (I suspect this is only relevant with the old Solaris naming scheme).

Once the bug list is open, it’s natural to click around a bit, and I tracked down another bug to a typo in an entirely different repository, which causes translated rich-text markup to break.

The next bug is about column alignment, and I ended up with 10 commits to illustrate the thinking behind what was a relatively simple refactoring, but a single change would be a lot harder to justify.

.. and then it was 2am. What was I trying to fix? I forget.

Rendering OSM Maps with MapCSS

Saturday 27th of June 2020 07:45:00 AM

After having written about where we get the data for KDE Itinerary’s train station and airport maps from, this post is about how we actually render this data.

Rendering OSM Data

When looking at the geometry, OSM data consists basically just of lines and polygons, so technically there’s only few primitives to render. To make this look like a useful map though, a lot depends on the map styling. That is, the decision with which colors, line strokes, fill patterns, z order, and iconographic or textual labels those geometric primitives should be rendered. Here we are talking about hundreds of rules to make a good map.

Since writing all those rules in code is hard to work with and to maintain, using a declarative way to define the rules is attractive. Several such systems exist in the OSM space already, such as MapCSS or CartoCSS, so we followed that and are using MapCSS for our indoor map renderer.

MapCSS

As the name suggests, there’s quite a few similarities to CSS, which makes it fairly straightforward to work with. Selectors and conditions are tied to querying OSM element types, OSM tags and the current zoom level instead of HTML elements and attributes, and similarly the properties you can declare refer to the styling capabilities of the map renderer instead.

Let’s look at a simple example for rendering railway tracks:

way[railway=rail] { color: #eff0f1; dashes: 2,2; width: 1.5m; casing-width: 3px; casing-color: #31363b; linecap: none; }

One thing you might notice there is the support for the size unit “m”, meters. Unlike sizes specified in pixel, the size on screen changes depending on the current zoom level. Another powerful mechanism is being able to refer to values from OSM tags here. Let’s expand the above example by the following additional rule:

way[railway=rail][gauge] { width: gauge; }

This will cause railway tracks being rendered in a width matching their track gauge. The following screenshot of the mixed-gauge Swiss station of Visp shows the result.

Visp train station, narrow gauge tracks at the bottom, normal gauge tracks at the top.

Just like CSS, MapCSS also supports importing of rules from other files. This allows a modular design, sharing common rules between a dark and a light style for example, or even to define special-purpose variations of a common base style. This could for example be used to specifically highlight things depending on a users need or the current use-case/workflow.

Another nice side-effect of not having this in (compiled) code is the ability to load and reload MapCSS stylesheets arbitrarily at runtime, which speeds up development considerably: just make a change, reload the stylesheet and check if things look like you want them to look.

One can also twist this into a fancy debug output for the data processing, by creating a diagnostic stylesheet which e.g. just shows geometric primitives as-is.

Diagnostic MapCSS stylesheet showing navigation paths and elevator ids on a train station platform.

Such flexibility often has its price though. And indeed, the initial naive implementation didn’t scale up well enough to a realistically sized rule set. However, after a few rounds of optimizations MapCSS evaluation for an entire large building floor now easily happens within a single frame cycle, on a mobile phone. Even loading the data of an entire city into this as a stress test just takes a few seconds. And should we ever hit the limit again, there’s a few more ideas on how to further improve this.

There’s still a number of things from the MapCSS spec we haven’t implemented yet, due to so far not having needed them (e.g. fill textures, extrusion properties, chained selectors or eval expressions). Similarly, there are a few things that seem not easily doable by standard MapCSS features, such as indicating line directions (e.g. on one way streets or escalators), so a few custom extensions might become necessary. This is all fine though, having a system now that we can tailor exactly to our needs.

Outlook

While there is of course still plenty of work to do all over this, I think we are getting close to an initial integration into KDE Itinerary. While initially not offering more than showing a basic map, it would enable work on deeper integration features, and make all improvements on the map side immediately useful.

If you are interested in contributing, no matter if feedback, ideas or code, check out the workboard on Gitlab.

For playing with this locally, the best starting point is probably the QML example. After building KPublicTransport, add the bin/ sub-folder of the build directory to the QML2_IMPORT_PATH environment variable (or install to a properly setup prefix), and then load tests/indoormap.qml with qmlscene.

More (mis-)adventures in Qt Quick land

Saturday 27th of June 2020 06:08:10 AM

There’s no escaping that Qt Quick, sometimes also referred to by its language QML, has become the major focus of the framework. At least until the company decides to drastically change course in Qt 7. There will always be a place for QWidgets-based UI and C++ (everything compiles to C++ anyway, more or less), Qt Quick is really being pushed as the future of building user interfaces, especially for touch, mobile, and embedded.

A few years back, I tried playing around with using Qt Quick for rapid app prototyping by creating some reusable components and I wanted to build upon that by prototyping some non-conventional and even fictional user interfaces from prototype devices and concept videos. I didn’t get far with my limited knowledge of Qt Quick and was only able to implement an extremely crude version of MeeGo’s column-based home screen (a dream from long ago, don’t ask).

Inspired by my success (dripping with sarcasm), I ventured to try out other unconventional UI ideas that I had that I presumed would probably be easier to pull off in QtQuick compared to a traditional widget-based application. Especially since QML is always advertised for in-vehicle HUDs and instrumentation control panels.

Lastly, there was this sort of program I’ve long been thinking of, more as a fun and whimsical nod to some anime of my childhood. Yes, it’ll probably bring back not so fond memories of Clippy, but eh. Like I said, mostly for fun (for now).

I wish I could report that I have become a QML Qonvert (SCNR). I’m still on the fence about the whole Qt Quick matter, regardless of whether it’s the future or not. It’s probably possible to implement all of the fancy animation and touch-based gestures in C++ (since that’s what Qt Quick uses underneath anyway), but it will be like bending over backward just to have a “pure” C++ implementation. And since KDE Plasma, both desktop and mobile, are pretty centered around Qt Quick, the argument is pretty moot for a KDE developer working on those parts.

It’s not that I found the experience terrible. In fact, I’ve probably grown a bit fond of declarative programming, at least for some parts that make sense. I also appreciate how easy it is to play around with non-traditional widgets and controls or even make your own using QML, something I think would have taken me more than a day to pull off in C++ given the same level of proficiency (read: noob).

That freedom and flexibility, however, do come at a price, when the things you’ve taken for granted on the QWidgets side of the fence now become critical knowledge. Positioning, layouting, parenting, and the like have been particular stumbling blocks. They’re easy for the most common use cases but then become exponentially more complicated once you step outside of those. And don’t even get me started on how Qt Quick still lacks a proper tree view after so long.

My main takeaway? Qt Quick is almost like a separate and independent framework of its own, just one that’s built on top of Qt’s core classes. It almost shares very little in common with the widget-based paradigm that it’s probably best to treat it as an entirely different beast rather than just “another way” to develop Qt applications. In other words, it’s definitely something I’ll have to invest in learning deeper, as deep as I tried learning Qt ages ago. And considering the kinds of applications I want to write or am interested in, it is, as one purple dude said, inevitable.

__ATA.cmd.push(function() { __ATA.initDynamicSlot({ id: 'atatags-26942-5ef9880f82bf8', location: 120, formFactor: '001', label: { text: 'Advertisements', }, creative: { reportAd: { text: 'Report this ad', }, privacySettings: { text: 'Privacy settings', } } }); });

This week in KDE: We really hate bugs and we want to squash them all

Saturday 27th of June 2020 03:56:50 AM

The bugfixing and polish continue this week, but we also managed to squeeze in some welcome UI improvements, particular for our Kate text editor!

New Features

File move and copy operations and other similar I/O related jobs now support nanosecond timestamp precision (Méven Car, Frameworks 5.72)

File copy operations throughout KDE software can now make use of the copy-on-write functionality of the Btrfs filesystem (Méven Car, Frameworks 5.72)

Bugfixes & performance Improvements

.Desktop files whose icons are defined to be SVG files with the full path included now render correctly in Dolphin (Alexander Lohnau, Dolphin 20.04.3)

Hitting Ctrl+Shift+W in Yakuake now closes the session as expected rather than displaying an unpleasant “Ambiguous Shortcut Detected” dialog (Nicolas Fella, Yakuake 20.04.3)

Fixed a case where Discover could hang on launch and then crash (Aleix Pol Gonzales, Plasma 5.12.10 and beyond)

Fixed a bug that could cause Plasma Panels to be incorrectly drawn on top of full-screen game windows (Vlad Zahorodnii, Plasma 5.18.6 and beyond)

When an application exits very soon after inhibiting screen locking, the inhibition is now correctly cleared (Kai Uwe Broulik, Plasma 5.18.6 and beyond)

Fixed a bug that could cause the system to log out instead of restarting or shutting down (David Edmundson, Plasma 5.19.2)

Fixed a crash on Wayland when dragging-and-dropping a URL from Telegram to Firefox (David Edmundson, Plasma 5.19.2)

Switching between KWin rendering backends now lets you return to the original one without having to navigate elsewhere and then return (Benjamin Port, Plasma 5.19.2)

Fix Plasma 5.19 regression: The logout action in the Lock/Logout widget now works again (David Edmundson, Plasma 5.19.3)

Fix Plasma 5.19 regression: window rules using the WM_CLASS property now work again (Ismael Asensio, Plasma 5.19.3)

Fix Plasma 5.19 regression: window rules created from the rule dialog accessible by right-clicking on a window’s titleabar are now saved and applied properly (Ismael Asensio, Plasma 5.19.3)

Fix Plasma 5.19 regression: deleting multiple applications’ shortcuts in the new Global Shortcuts page no longer either fails or causes System Settings to crash (David Redondo, Plasma 5.19.3)

That incredibly annoying bug whereby scrolling with a scroll wheel mouse in a GTK app stops working when a Plasma notification appears has just been fixed!!! (Vlad Zahorodnii, Plasma 5.19.3)

The System Settings Default Applications page now lists Nautilus as a filemanager when it’s installed (Méven Car, Plasma 5.19.3)

Setting detailed locale format settings now works properly (Alexander Lohnau, Plasma 5.19.3)

The Media Player widget now has a saner default size when not in the System Tray (Riccardo Robecchi, Plasma 5.19.3)

Fixed a bug that could cause re-colorable icons to be re-colored incorrectly when changing an application-specific color scheme (David Redondo, Frameworks 5.72)

Plasma no longer crashes when configuring a WPA2-Enterprise encrypted Wi-Fi network with an EAP-TLS with public key only CA certificate file (Albert Astals Cid, QCA 2.3.1)

User Interface Improvements

Yakuake’s window can now be de-maximized with the same keyboard shortcut used to maximize it if you hit it a second time (Anton Karmanov, Yakuake 20.04.3)

Kate’s tab bar is now visually consistent with all the tab bars in other KDE apps (Tomaz Canabrava, Kate 20.08.0):

In case you noticed that the wallpaper is blurry, don’t worry, I’m fixing it

Kate’s tab bar now opens new tabs on the right, like most other tabs bars do (Christoph Cullmann, Kate 20.08.0)

Plasma’s Emoji picker window(which you can open with the Meta+period keyboard shortcut) now closes when you hit the escape key (Alexander Lohnau, Plasma 5.20)

That same Emoji picker window now lets you copy emojis using the standard Ctrl+C shortcut (me: Nate Graham, Plasma 5.20)

When the user has applied updates that require a reboot, the System Tray icon becomes a “Restart” icon and prompts you to restart when you click on it (me: Nate Graham, Plasma 5.20)

The System Tray’s expanded view now displays a button you can click on to configure the System Tray itself (me: Nate Graham):

The file dialog now behaves the same as Dolphin in that when you navigate to the parent folder, the child folder is highlighted (Ahmad Samir, Frameworks 5.72)

When you user trash a file, empty the trash, then undo the deletion, the message shown is now more accurate (Ahmad Samir, Frameworks 5.72)

How You Can Help

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.

First Evaluation

Friday 26th of June 2020 06:30:00 PM
Part 5 -

Hi everyone

It has been two weeks since my last post. In this time period, I took forward my project, adding multiple datasets and completed “share pieces of candies” and “locate the regions” activities.

Our motive behind adding multiple datasets in activities is to make the difficulty range of activities wider. This way the same activity can be easily configured to be played by pupils of different ages or capabilities.

GCompris code has been divided into two parts/folders i.e “activities” and “core” parts.

Activities parts

The Activities folder includes the implementation of each activity, it contains 1 folder per activity and every folder further contains a QML file, javascript file, and resource folder. Here QML is for designing the user interface, javascript (.js) files contain the main logic of the activity and resource folders, as the name suggests it, contains all the resources for activities. Images are good examples for resource folder.

Core Parts

Many elements i.e, help button, bonus which pupils see after successfully completing the level, menu bar and even the base container of each activity are the same in many activities. So, obviously rewriting them every time for each activity is time-consuming and makes the code difficult to maintain. This is why we have a core folder that contains core files which can be easily imported and used by any activity.

Visualization is always easy :).

src/ activities/ sudoku/ Sudoku.qml Sudoku.js resources/ core/ ActivityBase.qml Bonus.qml

Multiple dataset is implemented in core components of Gcompris. So, whenever I say I have added multiple datasets in an activity, it means I have changed the code of the activity to adapt multiple datasets and added JSON files. We use 1 JSON file to represent 1 dataset and datasets are a resource for an activity so we put them inside the resource folder.

I can further show you the json file and how anyone can easily customize them by discussing my past week’s work on share pieces of candies.

Share Pieces of Candy

As the name suggests, in this activity pupils have to equally distribute candies between their friends.



These are the datasets



Part of JSON file, which anyone can use to customize levels

We always try to make these keys self-explanatory. One can change values and rerun the application to see the effects.

In Proposal, I planned to only have 2 datasets for this activity but later I found that we have some random levels too, in which we can’t guarantee the extra candies. So after discussing with mentors, we decided to add one flag for each level (you can see the “randomisedInputData” flag in above JSON pic) and the third dataset, which will contain randomized levels. The Share activity contains lots of levels, sublevels and instructions...

Simplifying unit tests using a custom markup language

Friday 26th of June 2020 12:33:31 PM

Today I want to present a testing technique I now use in Nanonote unit tests.

Nanonote main component is a QTextEdit with several "extensions" to provide custom behaviors such as indenting/unindenting selected lines with tab/shift+tab or moving selected lines up and down with alt+shift+arrow keys (next version feature, #spoileralert!).

Testing these extensions is not particularly difficult but it requires tedious setup to set the text, position the cursor, define the selection. Then you perform the action and have to write more tedious code to check the new text, cursor position and selection match your expectations. Not only is it tedious to write, it is also error-prone and hard to read.

Here is an example:

SECTION("indent whole lines") { // GIVEN a TextEdit with 3 lines, the first two being selected edit->setPlainText("1\n" "2\n" "3\n"); auto cursor = edit->textCursor(); cursor.movePosition(QTextCursor::Down, QTextCursor::KeepAnchor, 2); edit->setTextCursor(cursor); // WHEN I press Tab QTest::keyClick(edit, Qt::Key_Tab); // THEN the selected lines are indented CHECK(edit->toPlainText() == QString(" 1\n" " 2\n" "3\n")); // AND the selected lines are still selected CHECK(cursor.selectionStart() == 4); CHECK(cursor.selectionEnd() == 12); }

(The SECTION and CHECK macros come from the Catch2 test framework I use to write Nanonote tests)

To simplify this I created two helper functions. The first one, setupTextEditContent(), is responsible for setting up a TextEdit in the state I need for my test. It takes a TextEdit instance and a string describing the wanted state in a tiny "markup" language. This language is the text content for the TextEdit with some special characters to define the selection:

  • It must contain a | character to indicate the cursor position.
  • It can contain a * character to indicate the selection start.
  • | may appear before * in the case of an upward selection.

Using this function, we can rewrite our the GIVEN part of our test code like this:

SECTION("indent whole lines") { // GIVEN a TextEdit with 3 lines, the first two being selected setupTextEditContent(edit, "*1\n" "2\n" "|3\n"); // WHEN I press Tab QTest::keyClick(edit, Qt::Key_Tab); // THEN the selected lines are indented CHECK(edit->toPlainText() == QString(" 1\n" " 2\n" "3\n")); // AND the selected lines are still selected CHECK(cursor.selectionStart() == 4); CHECK(cursor.selectionEnd() == 12); }

The second function, dumpTextEditContent(), does the opposite: it returns the representation of the TextEdit state using the markup language. It can be used to check the state of the TextEdit instance matches what is expected. Our test code can thus be further simplified into this:

SECTION("indent whole lines") { // GIVEN a TextEdit with 3 lines, the first two being selected setupTextEditContent(edit, "*1\n" "2\n" "|3\n"); // WHEN I press Tab QTest::keyClick(edit, Qt::Key_Tab); // THEN the selected lines are indented // AND the selected lines are still selected REQUIRE(dumpTextEditContent(edit) == QString(" *1\n" " 2\n" "|3\n")); }

As you can see the test code is much shorter and, at least for me, easier to read. Furthermore, in case of failures, the error message shows the difference between the actual and the expected state using the markup language instead of telling you that the cursor position is at 3 instead of the expected 2.

I find this technique makes it a lot less painful to write tests and will look into using it in other places when it makes sense. One drawback to keep in mind though is that the implementation of setupTextEditContent() and dumpTextEditContent() must not be buggy itself! It might make sense to write tests for those...

That's it for this article, I hope it was useful for you. I doubt I actually invented this technique, so I'd be interested to hear if you have ever used a similar testing technique in your own projects!

Plasma 6 porting work we need help doing now!

Thursday 25th of June 2020 08:00:29 AM

"6.0" is a word that brings a lot of excitement but also a lot of aprehension and for good reason. The reason our .0 releases sometimes struggle to match the quality isn't due to changes in the underlying libraries changing but how much we have to port away from the things that we've deprecated internally and have put off porting to.

Too many changes in one release becomes overwhelming and bugs creep in without time to get address them.

We want to be proactive in avoiding that.

At a recent Plasma sprint, we went through some of our bigger targets that we want to finish completely porting away from in time for the 6.0 release that we can actively start doing within the 5.x series where we can do things more gradually and inrecementally.

I've listed two big topics below.

DataEngines History

DataEngines were a piece of tech from the KDE4 era. Effectively the idea was to provide an abstract mechanism to expose arbitrary data or plugins to a scriptable format usable by various language bindings. A valid task at the time, but Qt5 provided a much more efficent mechanism to do this capitalising on the metaobject system and models

DataEngines mostly form a now unnecessary layer of indirection that makes QML code hard to parse and suboptimal to run. They also are Plasma specific, which doesn't help other QML consumers of the same data.

We kept with them for Plasma 5 as there's some valid, perfectly working code exposed through them, and have been slowly porting away.

Task

The task isn't to port all existing DataEngines. Some already have replacements under different names, some aren't widely used.

We want to find all existing applets that use DataEngines and make sure there are modern new QML bindings we can port the repsective applets to.

A list of tasks can be found:
https://phabricator.kde.org/T13315

System settings modules History

Systemsettings is powered by a multitude of KDE Configuration Modules (KCMs) each one is a standalone plugin. There are nearly 100 modules, and with dated code stretching back over 20 years.

KDE, plasma especially is on the turning point between two toolkits. Some things are written in QWidgets and other things use the newer QtQuick. We try and hide this from the user; everything should of course look seamless. Implementation details shouldn't affect the UI.

We've been slowly porting our system settings modules, and whilst some were rocky at first, the later results are looking really nice and really polished, able to make use of emerging new patterns in our Kirigami toolkit.

Mixing two toolkits in the same process leads to a lot of complications that leak into the UI as well as overhead. We want to make it an objective to see if we can port everything to lead to an overall simpler stack.

Task

The overall task is to find KCMs that haven't been ported yet and make the appropriate changes.

However, this isn't just a goal of blindly porting.

We want to take a step back, really polishing the UX, tidying the code to have a good logic vs UI split and revsit some modules that haven't been touched in a long time, putting effort into our underlying frameworks to make sure we have everything ready on the QtQuick side to do so.

A list of KCMs and their porting status can be found:
https://phabricator.kde.org/tag/plasma_kcm_redesign/

Getting involved

The best way to get involved is to comment on the relevant phabricator ticket. Or swing by #plasma on IRC and let people know what you want to work on and we'll help you get started.
Some of the systemsettings modules have mockups from the VDG and we want to keep them in the loop.

Week 3: GSoC Project Report

Tuesday 23rd of June 2020 10:13:18 AM

This week I implemented views, drag and drop of storyboard items in the central view and made some small changes. I also ran unit-tests, checked for memory leaks and debugged code, but unfortunately we couldn’t get it tested by users as we got some crashes.

There are three views to customize what part of the storyboard item you see. Namely they are Thumbnail only, Comments only and Both. This was easy to implement as we only had to make changes to delegate and view class to draw the right parts based on the chosen view.

All view Comments Only View Thumbnails only View

I also implemented drag and drop of storyboard items. For this I implemented the mimeData and dropMimeData functions and then called the moveRows function in the dropMimeData function to move the rows.

Drag and drop

Also we made the add and delete buttons permanent instead of show on hover as their might be some tablet devices that do not support hover.

I made some changes to unit-tests to account for the changes in the design. All the unit-tests passed. I also got some memory leaks that I investigated and fixed using valgrind. But we got some crashes that couldn’t be fixed this week so we couldn’t get the GUI tested by users.

This week I would focus on debugging the code and getting it tested by users.

2020 KDE roadmap: mid-year update

Monday 22nd of June 2020 10:17:24 PM

Here’s a mid-year update on the 2020 roadmap I proposed six months ago:

FUSE mounts to better support accessing remote locations in non-KDE apps: DONE

kio-fuse was released in beta form early this year and is already packaged in many distros. It’s working great! The final release will happen later this year.

Privilege escalation in KIO and Dolphin: AT RISK

It turned out that there was more work remaining here than I had anticipated. Unfortunately nobody seems to have the critical combination of domain knowledge, interest in working on it, and time to do so. Assistance on https://phabricator.kde.org/D7563 would be appreciated to help make it happen this year.

Improved Samba share discovery in Dolphin: DONE

This was implemented for Dolphin 20.04. By all accounts, it’s working quite well!

Auto-rotation for tablets, convertibles, and other hardware with rotation sensors: DONE

This was implemented for Plasma 5.18 and works on Wayland (getting it working on X11 is a lost cause, apparently). If it isn’t working for you on Wayland, it’s likely that you don’t have the iio-sensor-proxy package installed, or your hardware isn’t supported by the kernel yet.

Implement more of the proposed visual design changes to the Breeze style and KDE apps: ON TRACK

Work is proceeding at a good pace. The new System Tray design was shipped with Plasma 5.19. We’re targeting 5.20 for the new application appearance and patches are landing. Things are on track.

Better wallpapers in the extra wallpapers repo: AT RISK

This is blocked on implementing a wallpaper cache. I took a stab at it for Plasma 5.18 but it turned out to be more complicated than I had anticipated and I kind of got demoralized and dropped it. Need to resume the work.

Per-screen scale factors on X11: UNLIKELY

Focus has shifted toward Wayland in a big way, and for the past few months, veteran KDE developers have been smashing Wayland problems left and right. They’ve gotten clipboard support working with Klipper and going between Wayland and XWayland windows; made Spectacle work properly; fixed a number of drag-and-drop issues, and are very close to finishing task manager thumbnails, screencasting, and more! Given the progress and momentum, there’s a strong desire to make Wayland finally usable rather than hack things into X11 that it was never designed to support and are unlikely to ever work properly.

Inertial scrolling throughout Plasma and QML apps: UNLIKELY

No work has happened here. A lot of the issue are in Qt itself and are very challenging to resolve, especially on X11. There may be more hope for getting it done on Wayland.

Power/session controls on the lock screen: AT RISK

I started implementing this and got it kinda-sorta working but then lost motivation and forgot about it. Sorry about that. I need to get back into it.

Well there you have it! Of course this is just a tiny fraction of the stuff actually going on, it’s just what’s relevant to the proposed roadmap I outlined earlier.

As always, if you want to see these things happen faster, please feel free to help out! The code is public and the people are friendly.

PhotoTeleport 0.13

Monday 22nd of June 2020 08:11:09 PM

Just a quick note to let the world know that PhotoTeleport 0.13 has been released.

Week #3 Status Report

Monday 22nd of June 2020 12:18:00 PM
This was the third week since the commencement of official coding period on 1st June. In the last three weeks a lot of work is done and a lot of work still remains. The phase 1 evaluation submissions shall begin from monday next week, so now just 7 days are remaining.

This week was mostly spent on accommodating review changes by my mentors and writing some unit tests.
Work Done: Tests:  I started my week writing some unit tests for the draw_dab and get_color methods that I had implemented previous to previous week. Refactoring:  Boud suggested me to do some refactoring as the design decisions of my previous approach were not that good. I had linked libmypaint to other component responsible for preset management in the code which was not the right thing to do as a good design would be to have all the dependencies that belong to a plugin contained in the plugin itself. Ideally, a plugin should be removable from the entire system by deleting or commenting a single line. So, I had to implement a separate paintop factory class and hook the plugin within this class. Boud gave me an entire archive with code to the previous mypaint plugin that we had in Krita years ago. So, this was nothing more than understanding its approach and implement the same thing. Profiling:  In my previous post I had mentioned that the brush engine is lagging. My mentors suggested me to profile the brush strokes as it would reveal the bottlenecks. I did the same and as it turned out that 3 specific methods (KoColor::toQcolor, KoColor::fromQcolor and KoColor(colorspace)) were responsible for the drag. These methods are designed in a manner that they do colorspace conversions for us so that the user can stay away from the dirty work. The problem with using these methods was that they were doing complex processing for something as simple as divide by 255.0f causing the strokes to lag a lot. To mitigate this, I simply removed those methods and did the operation manually which solved the problem. So the lag is much less severe now. 
In short, the week was mostly good, and it went as expected :)

More in Tux Machines

Linux 5.9 Performance Is Off To A Great Start With FSGSBASE Boost

FSGSBASE particularly helps out context switching heavy workloads like I/O and allowing user-space software to write to the x86_64 GSBASE without kernel interaction. That in turn has been of interest to Java and others. While going through patch review, we've benchmarked FSGSBASE patches at different points and found the performance benefits to be evident and helping in areas hurt by the likes of Spectre/Meltdown. FSGSBASE is supported on Intel CPUs since Ivy Bridge as well as newer AMD CPUs, where the performance is also helped. On Linux 5.9 where FSGSBASE is finally mainlined, it's enabled by default on supported CPUs. FSGSBASE can be disabled at kernel boot time via the "nofsgsbase" kernel option. On Linux 5.9+, looking for "fsgsbase" in the /proc/cpuinfo is the indicator whether FSGSBASE kernel usage is happening though note prior to 5.9 on supported CPUs the "fsgsbase" string is always present. For this article are some early data points of Linux 5.9 tested out-of-the-box on a Git snapshot and then again when booting that kernel image with "nofsgsbase" and repeating the tests. Via the Phoronix Test Suite various benchmarks relevant to FSGSBASE testing were carried out. Quick tests on both Intel Core and AMD Ryzen are done for this article while additional tests will be coming of Linux 5.9 over the weeks ahead -- 5.9-rc1 isn't even out until next weekend as marking the end of 5.9 features landing. Read more Also: User Xattr Support Finally Landing For NFS In Linux 5.9 Please pull NFS server updates for v5.9

Python Programming

today's leftovers

  • "Hey, DT. Why Arco Linux Instead Of Arch?" (Plus Other Questions Answered)

    In this lengthy rant video, I address a few questions that I've been receiving from viewers. I discuss fake DistroTube accounts on social media, my thoughts on PeerTube, my experience with LBRY, my thoughts on Arco vs Arch vs Artix, and what YouTubers have influenced my life.

  • 2020-08-10 | Linux Headlines 186

    elementary OS teases big changes coming in version 6, RetroArch rolls out major search improvements with version 1.9, Microsoft releases Minecraft: Education Edition for Chromebooks, and the new Krita Scripting School website aims to help developers expand the painting application.

  • R600 Gallium3D Now Has Compute Shaders Working With NIR

    If you are still rocking a pre-GCN AMD Radeon graphics card on the R600g driver for the HD 2000 through HD 6000 series, you really ought to consider upgrading in 2020, but otherwise at least from the open-source community there continues to be improvements.

  • NVIDIA GeForce are teasing something for August 31, likely RTX 3000

    Ready for your next upgrade? NVIDIA think you might be and they're teasing what is most likely the GeForce RTX 3000 launch at the end of this month. We don't know what they're actually going to call them, although they will be based on the already revealed Ampere architecture announced back in May. It's probably safe to say RTX 3000 for now, going by the last two generations being 1000 and 2000 but NVIDIA may go for something more fancy this time.

  • How to Learn Python in 21 Days?

    Before moving further, let’s have a brief introduction to Python Language. Python, designed by Guido Van Rossum in 1991, is a general-purpose programming language. The language is widely used in Web Development, Data Science, Machine Learning, and various other trending domains in the tech world. Moreover, Python supports multiple programming paradigms and has a huge set of libraries and tools. Also, the language offers various other key features such as better code readability, vast community support, fewer lines of code, and many more. Here in this article, we’ll discuss a thorough curriculum or roadmap that you need to follow to learn Python in just 21 days!

  • This Week In Servo 135

    Last week we released Firefox Reality v1.2, which includes a smoother developer tools experience, along with support for Unity WebXR content and self-signed SSL certificates. See the full release notes for more information about the new release.

OSS Leftovers

  • Richard Stallman Discusses Privateness Dangers of Bitcoin, Suggests 'One thing A lot Higher'
  • The many meanings of 'Open': Open Data, Open Source, and Open Standards

    It is important to note that open source software is not always “free” software. The difference is in the licensing and the level of effort required to customize the code for your use case. According to GNU progenitor and software freedom advocate Richard Stallman, free does not mean non-proprietary but rather suggests that “users have the freedom to run, copy, distribute, study, change and improve the software” for any purpose. (“This is a matter of freedom, not price, so think of ‘free speech,’ not ‘free beer,’” Stallman says.). One also has the freedom to sell the software after modifying it. Implementing open source software inside a business enterprise frequently requires customization for your organization’s workflow. Whether this customization is done using internal resources or with the help of external consultants, it typically is not free, nor is the subsequent maintenance of the software. Successful open source software is designed and built using a collaborative community software development process that releases frequent updates to improve functionality and reliability. The key is in the “community” adoption and development.

  • How an open community rebrands

    As an open community evolves, so does the way it expresses its identity to others. And having open conversations about how you'd like your community to be recognized is an important component of community engagement. Simply put, your community's brand is what people (especially potential contributors) see first when they encounter you. So you want to make sure your brand reflects your community—its values, its principles, and its spirit. [...] Together, then, we were able to augment Jim's experience at Red Hat (though we always welcomed his perspectives along the way). Over the past half-decade, the Open Organization community has grown from a small group of passionate people debating nascent ideas about the "cultural side" of open source to a bustling bunch of thought leaders who have literally written the definition of what it means to be an open organization. To put it in open source terms: Our entire upstream project continues to evolve from that founding gesture.

  • LibreOffice 7.0 arrives, improves performance and compatibility

    AMD sponsored the developers' implementing the Skia graphics engine in LibreOffice. In Windows this open source 2D graphics library provides upgraded performance. Additionally the engine is accelerated by the Vulkan graphics and compute API.

  • TinyFloat, Troll Arithmetic, GIMP Palettes

    I've been working on a 64 bit extension to the 6502 processor architecture. This is for the purpose of implementing a secure computer which also has a hope of working after post industrial collapse.

    Along the way, I have found a use for a practical use for 8 bit floating point numbers. Floating point representations were historically used for scientific calculations. The two components of a floating point number - the exponent and mantissa - work in a manner similar to logarithms, slide rules and the scientific representation of numbers. For example, 1.32×104 = 13,200. Why not just write the latter? Scientific notation works over a *very* large scale and is therefore useful for cosmology, biology and nanofabrication. For computing, floating point may use binary in preference to decimal. Also, it is not typical to store both the exponent and mantissa within 8 bits.

  • Open Source Contributions on the Rise in FinTech, Healthcare and Government [Ed: "The Linux Foundation sponsored this post." So the Foundation is now busy distorting the media instead of actually supporting developers who develop Free software on shoestring budget.]

    Enterprise use of open source remains stable, and a new generation of companies are increasing their engagement with open source communities. Led by financial services, healthcare and government, more organizations across most industry verticals are regularly (frequently or sometimes) contributing to upstream projects, going from 42% to 46% over the last three years.

  • TODO Group Survey Shows Stable Enterprise Open Source Use

    The “Open Source Programs in the Enterprise” survey, from The Linux Foundation’s TODO Group and The New Stack says “enterprise use of open source remains stable.” An article by Lawrence Hecht reports that more organizations across industry verticals are regularly contributing to upstream projects, increasing from 42% to 46% over the past three years. “The multi-year effort provides a solid baseline for measuring change, growth and effectiveness of efforts to guide corporate open source policies and community participation,” Hecht said.