It has been a busy two month since the last report again, KDE’s source code hosting is now using Gitlab, we got the 20.04 release out, notifications were significantly improved, and we are now leveraging OpenStreetMap in more places, with even more exciting things still to come. The global travel restrictions have been hampering field testing, but they have most certainly not slowed down the development of KDE Itinerary!
Delay and disruption notifications in KDE Itinerary were almost entirely redone.
This required work throughout the stack, see the recent post on KNotification on Android work for details.
Another new development is that we now have access to intermediate stops of a journey, thanks to KPublicTransport extracting this when available from a backend now. Besides showing this to check suggested transfer trips or alternative journey options, this also gives us more information to compute journey statistics.
A lot happened on the internals as well, all aiming at providing better data for the travel data extraction and the transfer assistant.
The probably most powerful outcome of this is the coordinate-based lookup of timezones and countries. With just 300kB of static data this is able to provide correct results for more than 99% of the coordinates, also replacing two more specialized tables for airports and train stations. See this post for details.
Combining OSM and Wikidata data also allowed us to get public transport line logos in many cities, making it easier to match what the app shows you to local signage when trying to find the right station/platform. How this was done is described here and you can see it in use in the above screenshot.
How we navigate to and from airports has also been improved by using OSM data. This should fix issues where KDE Itinerary suggested public transport stops or driving destinations on the other side of the airport, rather than the terminal or entrance you actually need to go to. See this post for more details.
All of this relies on detailed Open Data, I have written previously about how you can help to improve this in areas of interest to you, by editing the corresponding entries in Wikidata and OpenStreetMap.
There’s plenty more noteworthy changes too of course:
Quite some work in the past two weeks also went into something larger that isn’t ready to be integrated yet: train station and airport (indoor) maps. Besides being useful in their own right, having the infrastructure for this will enable many more exciting assistance features, such as helping you to get to a connecting train while considering mobility restrictions (e.g. avoiding stairs due to heavy luggage).
Much more about this yet to come, for now here’s just a few teaser screenshots of the current prototype.
As mentioned already, a very easy way to contribute to this is by improving the relevant information in Wikidata and OpenStreetMap.
If you want to help in other ways too, see our Phabricator workboard
for what’s on the todo list, for coordinating work and for collecting ideas. For questions and suggestions, please feel free
to join us on the KDE PIM mailing list or in the #kontact channel on Matrix or Freenode.
This week we landed a lot of nice improvements for KDE’s apps, which I’ve highlighted below! Of course we didn’t forget about Plasma, so have a look-see:
Dolphin now lets you mount ISO images using a new menu item in the context menu (Kwon-Young Choi, Dolphin 20.08.0):
Konsole now lets you monitor a tab for the active process to complete (Will Westrop, Konsole 20.08.0):
Improved search speed/performance in Okular’s sidebar (Ahmad Samir, Okular 1.10.2)
Fixed a very common Yakuake crash (Maximilian Schiller, 20.04.2)
Fixed a common crash in Konsole when right-clicking and using Qt 5.15 (Ahmad Samir, Konsole 20.04.2)
Gwenview’s touch gestures now work properly when using display scaling (Steffen Hartlieb, Gwenview 20.08.0)
Notes widgets placed in a panel now display the pop-up note if clicked on when all windows are hidden or minimized (Marco Martin, Plasma 5.19.0)
Clicking on the settings button for a notification now opens the Notification settings page with that particular app focused and visible (Benjamin Port, Plasma 5.19.0)
KRunner once again shows Firefox bookmarks (Alexander Lohnau, Plasma 5.19.0)
KRunner now does a better job of handling file paths beginning with a tilde (Méven Car, Plasma 5.20)
When using Dolphin to view the desktop using the special desktop:/ URL, the amount of free space is now correctly displayed in the status bar (Ahmad Samir, Plasma 5.20.0)
Dates displayed in the file overwrite confirmation dialog now respect the date formatting of your current locale (Méven Car, Frameworks 5.71)
Deleting files from a Samba share no longer displays a notification with an inaccurate number of deleted files (Kai Uwe Broulik, Frameworks 5.71)
Okular’s sidebar user interface has been overhauled, with the result that it now takes up less horizontal space, is easier to show and hide quickly, has a more consistent appearance overall, and fixes many bugs (me: Nate Graham, Okular 1.11.0):
The default gesture for moving windows has been changed to Meta+click, to avoid conflicting with apps like Krita, Inkscape, and Blender which use Alt+click for their own usages. Tell all your friends and spread this information far and wide so people aren’t surprised! If you hate the new one and don’t use Krita, Blender, Inkscape, or another app which uses Alt+Click for something, you can of course change it back to Alt+click (Noah Davis, Plasma 5.20)
When dragging files from Dolphin (or elsewhere) onto the desktop, the files now end up at the location where you dragged them, rather than at the end of the last row (Radek Husek, Plasma 5.20)
The battery charge level icons displayed by the Battery And Brightness applet now reflect the current charge status more accurately (Daniel Roschka, Frameworks 5.71):
The standalone KRunner widget now closes the pop-up if you hit the Escape key while the text field is empty (Alexander Lohnau, Plasma 5.20)
When using an ultrawide screen wider than 21:9, the default horizontal panel now no longer spans the entire screen width, but rather remains at the size it would be on a 21:9 screen, horizontally centered. Also in this mode, notification pop-ups that are configured to appear close to the Notifications System Tray applet will pop up close to it rather than way far away in a corner of the screen (Kai Uwe Broulik, Plasma 5.20.0):
The new OSDs now show a percentage label for brightness and volume (me: Nate Graham, Plasma 5.20):
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.
We are pleased to announce the launch of Nitrux 1.2.9. This new version brings together the latest software updates, bug fixes, performance improvements, and ready-to-use hardware support.
Nitrux 1.2.9 is available for immediate download.
Index, along with other Maui apps updated to version 1.1.1.
Maui applications 1.1.1 in Nitrux 1.2.9. An active window (Index). In the background, one of the new wallpapers; HighBuilding.
Maui applications 1.0.0 in Nitrux 1.2.8 with the previous artwork assets. An active window (Index).
Qps is a monitor that displays the status of the processes currently in existence.
The post Changelog: Nitrux 1.2.9 appeared first on Nitrux — #YourNextOS.
Hey everyone,
As the coding period of GSoC is going to begin in the next 2 days. In this blog, I am going to write all about what I did during the community bonding period.
During this period I have interacted with my mentors and finalized the multiple datasets of a few activities. Recently, the GCompris project has been moved to GitLab so I set up my account over there and also asked my mentors how can I push my branches to the server and everything else. I have also gone through the code of the memory activities and planned about the resources I will be using. I have also set up my environment as to how to test the GCompris on the android platform. I plan to start my work with the enumeration memory game activity so I have created a branch for it and pushed it to the server.
As to sum up I am all ready to begin my coding period now. Hope I would be having a great time ahead.
I will be updating my progress regularly through blogs.
Thanks!!
Deepak
kdesrc-build is an amazing tool that makes building KDE projects a breeze.
Now, I like having several build profiles for the projects I’m working on. The main build done by kdesrc-build is done with gcc, but I keep also a parallel build with clang, and some builds that incorporate static analysis tools and such.
At first, a long time ago, I was doing all this with shell scripts. But that approach was not really scalable.
Then I wrote a small tool that builds on kdesrc-build, but allows you to define different build profiles.
This tool has now been updated and moved to KDE’s brand new GitLab instance at https://invent.kde.org/ivan/kdesrc-build-profiles.
It allows you to create a few profiles, and specify which projects you want built with each of them. So, for example, you can keep parallel builds of plasma-workspace with gcc and the latest clang, while having a static analysis tool being run on plasma-framework and plasma-vault.
The example configuration file comes with the program. The format is the same as the one used by kdesrc-buildrc, just with a few custom fields.
In recent times, quite a few C++ IDEs or editors use clang behind the scenes to give you code completion, quick fixes, etc. It is often needed to create the so called compilation database which contains the compiler flags used to compile your project in order for the clang integration with your editor/IDE to work properly.
I found it quite tedious to always have to set this database for all the projects that I work on.
Because of this, kdesrc-build-profiles has got a new feature – it can now symlink the compilation database generated by cmake to the root of your project’s sources where the editor/IDE will find it easily. You just need to add symlink-compilation-database yes to the kdesrc-build-profilesrc file, and run the tool.
The program is written in Haskell. In order to install it, just install the stack package manager and do this:
vkrause
stack update
stack install kdesrc-build-profilesIf you are old-school and use cabal instead of stack, the installation is similar:
cabal update
cabal install kdesrc-build-profilesIf you want to compile it yourself, the steps are also easy:
git clone https://invent.kde.org/ivan/kdesrc-build-profiles.git
cd kdesrc-build-profiles
stack build
stack installTo use it, copy the kdesrc-build-profilesrc-example (remove the -example suffix while doing so) file into the KF5 sources directory (where you keep kdesrc-buildrc file), edit it to fit your setup, and run it.
The commands are quite simple. For example, if you want to build all projects you configured under clang profile, do:
kdesrc-build-profiles clangIf you want to build only plasma-desktop and plasma-workspace with clang, do this:
kdesrc-build-profiles clang plasma-desktop plasma-workspaceFor more commands, use the --help.
During foss-north 2020 we had a group of talks related to using free and open source in various settings. I call them enablement talks. Someone with a more salesy mind might have said success stories.
This year we had tree such talks. One from about SVT’s (the Swedish public TV broadcaster) video streaming platform by Gustav Grusell and Olof Lindman, one from arbetsförmedlingen (the Swedish public employment service) by Johan Linåker and Jonas Södergren, and about Screenly OSE by Viktor Petersson, a digital signage solution.
We’ve also decided to experiment with a series of shorter videos, and we started by explaining licenses.
Three months ago I went to Colombia for a mix of visit-family and visit-colleagues. At the time, COVID-19 wasn’t called that in the media, and travel was still pretty normal.
Two-and-a-half months ago I jumped in the Amazon river, saw some of the rarest animals on earth, and ate ants. Being far away from COVID-19 was the best protection I could think of.
Two-and-a-quarter months ago I got the last KLM plane out of Bogotá and arrived in an empty Schiphol, took an empty train through an empty Utrecht CS and biked home through empty streets to sit down for at least two weeks of quarantaine (that’s only 35%, though).
Since then, the Netherlands has gone through a phase of dumbassery, then lockdown, then “smart” lockdown, and now restrictions are slowly easing up. I get the sniffles from walking around outside, which qualifies me as symptomatic, so I’ve basically been cooped up inside since then. The “smart” lockdown meant that I could send a kid to the supermarket – and I’m lucky to live within walking distance of a supermarket, with kids whom I can hand a bank card and say “buy oatmeal”.
So these are notes from a position of tremendous privilege. I understand that some indigenous tribes are in danger of annihilation from the disease now that it has spread into the heart of the Amazon. My friends in India are locked inside and can’t go out for fear of police. I can’t help them directly, just be supportive from a long-way off.
In many ways, very little has changed in the way I work on Free Software projects. I get paid to do so – partly on Calamares, partly on other things – and there simply was no switch-to-remote work for me. Sitting at my desk, two monitors, FreeBSD underneath and Linux VMs in my face, with IRC for realtime communication: that’s been part-and-parcel of work for years now and nothing has changed there.
Except that now there’s people in the house.
One thing I notice is that when kid[1] is at the machine next to
mine, it’s distracting. But how distracting, depends on what is
on-screen. Java code only a little, until I feel the urge to
ask what’s the issue – then I’m the cardboard cutout dog.
Geometry Dash also only a little, since the rhythmic clicking of
the mechanical keyboard mostly makes the same sound as
my own keyboard when I’m doing something derpy like re-indenting
chunks of CMakeLists.txt.
Minecraft, on the other hand, drives me nuts.
I just can’t work sitting next to that.
The Slimbook sees a lot more work now, when I flee to the living room. But that’s where online lessons are happening, so I need to sneak around (sometimes out around the side of the house to cross to the other end of the room) because I don’t want to be broadcast accidentally to 20 students listening to middle-school explanations of quadratic equations. The equations are written on the blackboard painted onto one wall of the room.
kid[0] had final exams cancelled out from under them, so
they graduated from school with very little sound or fury.
We wrote out a CV together and they now have a job (in “smart” lockdown times!)
until the end of the summer and the start of university.
Since I live within walking distance of the supermarket and work from home, my daily pattern was go-to-store for lunch (bread, veg, milk) and then go again later in the afternoon to come up with something for dinner (veg, pasta, cheese). Dinner choices are strongly dictated by what’s on sale today (oh, tomatoes? then we’ll have tomato soup).
Now I have to think about a dinner plan, sometimes for several days.
This has been a very learning time for kid[1], who gets sent to
the store most often. Generally they get detailed instructions,
along with an explanation of what’s planned for dinner. I have
learned that “tomato” is too ambiguous – it could mean
whole tomatoes, cherry tomatoes, passata di pomodori, or concentrated tomato paste.
Kid returned with all of them, just to be sure.
Then we had tomato-based dinners for three days.
In some ways this is like onboarding new contributors in a software project: there is all this implicit knowledge and stored experience and assumptions and habits that might need to be passed on. Bread is available at the supermarket but is sold out if you wait until five in the afternoon. Get the frozen spinach last unless it’s on the meal plan for today. I don’t care about what brand of tomato paste; I do care about the brand of pasta (Barilla no. 41 for mac-n-cheese).
Speaking of mac-n-cheese: we tried Kraft Dinner for nostalgic purposes a few times: eww. But here’s a bell-pepper soup that we call “gulyás” because it’s inspired by the real Hungarian thing:
So it was 4th May 11:30pm IST, I was eagerly waiting for an email from google about Google Summer of Code results. I checked #gsoc on freenode and it seemed like selected students already received an email.
I kept refreshing my emails and…
I had been accepted into Google Summer of Code!
I am really excited to be a part of GSoC with KDE and work on my project this summer and would like to thank my mentors Carl Schwan, Niccolò Venerandi and Alexander Saoutkin for helping me along the way.
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.
Officially, GSoC’20 coding period starts from June 1. The current time is meant for getting to know the community better and finalize details about the project. So I’ve been doing just that :)
Be it playing Werewolf at KDE Werewolf or discussing the next season of Dark, It has been a fun time interacting with the community.
I also worked a bit on KDE’s new Identity service mykde and managed to fix a few bugs. With one week left in the coding period, I also started working on porting kde.org. The progress has been a bit slow as the website is using very old HTML and has a lot of pages but I hope I can speed up with time.
I will keep on sharing my progress in future blog posts and hope to have a productive summer ahead! If you would to join in, Say Hi at #kde-www on irc or telegram.
Good morning everyone!
I’m checking in today to let you know what I did in my GSoC project these past weeks. This Community Bonding period was really wonderful; although I’ve been more or less involved with the project since 2016, I’ve acquainted myself with the efforts of each of the members, and so far it’s been a wonderful experience.
During these past weeks, I’ve been preparing for the coding period by talking with Boudewijn and Wolthera about the particulars of Krita’s file format and build system. The objectives for the past two meetings were:
This post summarizes my efforts on each of these bits. I apologise for the late post; but this week I got to attend (virtually) my first Eurographics and LGM sessions, and with the homework load, it’s been some wild days.
Without further ado, let’s see how deep this rabbit hole goes.
I’m glad to report that SeExpr can be successfully built as a dependency! Currently, the build process points to my own fork of SeExpr. This is for two reasons: first, for GSoC evaluation purposes, my mentors need to be notified of every commit I make (in this case, both in Krita and in the SeExpr library itself). But the other, and most important, is that SeExpr, as designed by Disney, is natively incompatible with our compilation toolchain in Windows. When Disney developers wrote the library, they made a critical assumption, that a Windows compilation would always be made with Visual C++. Also, since their parser is written with Bison and FLEX, they required Windows users to copy bundled, pre-generated files before being able to compile the library.
My fixes were four-fold:
find_packageWith this process, I was able to get successful builds on both Windows and
macOS. (There’s a bug that Iván fixed quickly in the osxbuild.sh
script, but as it was easily worked around, I’ve yet to cherry-pick it into my
branch.)
The process for Linux wasn’t so smooth, unfortunately. The build process I demoed in a previous post uses Manjaro’s system libraries, and since it’s rolling release distribution, it guarantees that almost no one will be able to run a demo. Since tiar usually asks users to test using AppImages, I decided to take that route, and attempted to build them… blindly.
I spent a whole weekend fixing the ensuing mess.
To begin with, Manjaro comes with an AppImage integration called AppLauncher that hooks into any AppImage that tries to run and helps you integrate it with your system. The bad news is that, as a system application, it uses the local version of Qt, 5.14. Why is this important?
Turns out, the build scripts use a packer, linuxdeployqt.
I’d naïvely thought this was bundled with Qt (like macdeployqt and
windeployqt), but it’s an AppImage on its own right.
And since the build scripts patch LD_LIBRARY_PATH, in order for it to find
our (heavily patched) Qt 5.12 distribution, I got very
unhelpful crashes from AppLauncher. I uninstalled it once I recognized the Qt
version mismatch, but it kept crying “file or directory not found”.
tl;dr: uninstall AppLauncher and reboot your system before using
linuxdeployqt.
My Ryzen 7 box packs quite a punch so, thankfully, the above didn’t waste too
much time. The real problem arose, when I noticed that
linuxdeployqt automatically detects and refuses to run if your system is
too new.
This is to prevent incompatibilities between the AppImage and the
version of the glibc library it needs.
I needed a way to isolate my Krita build and use a least common denominator distribution. Thanks to my best friend’s sysadmin tales, I knew I had a solution in the shape of a LXC container.
tl;dr: I installed LXD (the Snap version),
sudo snap install lxdadded my account to the lxd group to skip the sudo bits,
sudo usermod -a -G lxd amaliaAfter the customary reboot, I initialized LXD with all the defaults,
lxd initcreated a new container (Ubuntu 18.04 is still too new for AppImages, but it helped to satisfy my learning needs),
lxc launch ubuntu:18.04 krita -c security.privileged truebound the ~/krita folder as a writable device (which is why I need
security.privileged),
lxc config device add krita src disk source=$HOME/krita path=/kritaand relaunched the container:
lxc stop krita
lxc start kritaWith the container set up, I could start building the dependencies… But wait, what packages do we actually need?
Yes, this step felt like another whack-a-mole of mistakes. The dependencies’ build script is notoriously unhelpful:
# Prerequisites: cmake git build-essential libxcb-keysyms1-dev plus all deps for Qt5After a whole day of getting complaints from each step, and installing the required packages, I managed to determine exactly which dependencies are needed for Krita. For the build process in general,
sudo apt-get install build-essential cmake libgl1-dev libglu1-mesa-devand additionally, for the KDE libraries,
sudo apt-get install libxcb-keysyms1-dev libxcb-res0-dev libxrender-dev libxkbcommon-devBut there are hidden dependencies that aren’t listed anywhere,
perhaps because we bundle them in 3rdparty yet we do not use them
in Linux.
The GMic plugin needs:
sudo apt-get install libtiff5-devThe exiv2 library needs:
sudo apt-get install zlib1g-devAnd, finally, Qt itself:
sudo apt-get install libssl-dev gettext libfontconfig1-devWith the dependencies installed, I added the two remaining utilities,
linuxdeployqt and patchelf:
wget -c -nv "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage" -O /usr/local/bin/linuxdeployqt
chmod a+x /usr/local/bin/linuxdeployqt
cd /tmp/
wget -c -nv https://nixos.org/releases/patchelf/patchelf-0.9/patchelf-0.9.tar.bz2
tar -xf patchelf-0.9.tar.bz2
cd patchelf-0.9
./configure -prefix=/usr/local
make -j4 install
cd ~
rm -rf /tmp/patchelf-*By this time, I had realised there was an official KDE repo listing everything
I needed to set up such a container, sysadmin/ci-tooling. You can save time and headaches by pulling the kdeorg/appimage-ubuntu1604 Docker image, or by using Dmitry’s scripts.
Dmitry and Agata asked:
I’d like to clarify that the main development will be done under Windows, as that’s the most clean environment possible; it doesn’t ship Qt nor any other libraries that could interfere. For macOS, I have my MacBook Pro with Mojave. And for the AppImages, the LXC container resides in a separate SSD with the Manjaro install I run.
Finally, I prefer LXC to Docker because Docker (without e.g.
docker-compose), is oriented to ephemeral containers, that need a lot
of command line flags to set themselves up. I’m also too prone to docker image prune --all,
and I wouldn’t want to download a multi-GB image each time I build Krita
. And since the LXC container runs in the background, I can have
it always up and pull the demonstration AppImage very easily – with just a
copy-paste operation.
Two weeks ago, Wolthera sent me her MR for the KRA file format documentation.
The gist of this is that each KRA file is a Zip container. It has a manifest
in maindoc.xml listing, among other things, the component layers’ properties.
To the above, I’ll add a new layer type identified as SeExpr. My plan was to
store the code in the layer node itself. In heavily simplified terms, it would
look like this:
<layer nodetype="SeExpr">
<![CDATA[
$val=voronoi(5*[$u,$v,.5],4,.6,.2);
$color=ccurve($val,
0.000, [0.141, 0.059, 0.051], 4,
0.185, [0.302, 0.176, 0.122], 4,
0.301, [0.651, 0.447, 0.165], 4,
0.462, [0.976, 0.976, 0.976], 4);
$color
]]>
</layer>However, Boudewijn suggested I should instead follow the existing pattern and move the SeExpr rendering code to a separate file. This should make it easier to repair KRA files if they are corrupted. I have not done any further work on this, especially the UX bits; hopefully next week, I’ll be able to show you something
I have some more work to do as regards dependencies. I noticed Krita doesn’t
maintain a list of the supported libraries for each operating system;
for instance, the exiv2 library uses zlib, yet we don’t ship it in Linux.
I’d like to sit down and document the whole list, and the necessary fixes
for ensuring a consistent feature set.
Next, I’ll be dissecting the SeExpr library, and why I elected to bundle only a
limited set of features.
In the meanwhile, please chip in on David’s thread at Krita-Artists.org and let me know your expectations!
Until next time,
~amyspark
