Thanks to the KDE community, I’ve finally chosen and ordered a new laptop: a Lenovo ThinkPad X1 Yoga. People heavily recommended the X1 Carbon, which is essentially the same computer except less touch-focused. That led me to the Yoga which seems to fit the bill perfectly: in addition to the necessary touchscreen, according to reviews it has otherwise excellent screen characteristics, a perfect keyboard, great speakers, and a great trackpad. I also like the look and probable durability of the aluminum case. Though it’s not a Ryzen 4000-series laptop, CPU performance is still three times better than my current laptop, so I’m not complaining. Mine arrives in three weeks. Thanks again everyone!
Sometimes you just want to get something done. Something for yourself.
You do not intend it to be reused, or even pretty.
You build a tool.
My tool was a photoframe with some basic overlays. I wanted the family calendar, some weather information (current temperature + forecast), time, and the next bus heading for the train station.
To make this acceptable in a home environment, I built it as a photoframe. You can find the sources in the hassframe-ui repository on my github.
A hidden feature is that if you tap the screen, a home automation control panel slides up. That way you can control all the lights, as well as heat in the garage and an AC in the bedroom. Very convenient.
All this is built using QML. Three somewhat useful models are available:
I also have a bunch of REST calls to my local home assistant server. Most of these reside in the HassButton class, but I also get the current temperature from there. These are hardcoded for my local network, so needs refactoring to be used outside of my LAN.
All of these interfaces require API keys of one kind or another – be it a proper key, or a secret URL. These are pulled from environment variables in main.cpp and then exposed to QML. That way, you can reuse the components without having to share your secrets.
All in all the code is quite hacky. Especially main.qml. I refactor out parts from there now and then, but the photoframe works, so its not anything that I prioritize.
Currently it runs on a Raspberry Pi on top of Raspbian. I want to build an optimized Yocto image making it less hacky and more pre-packaged. Perhaps there will be a rainy day this summer and I’ll get around to it. Burkhard has prepared the instructions needed over at embedded use.
Sup y’all.
This is a series of blog posts explaining different ways to contribute to KDE in an easy-to-digest manner. The purpose of this series originated from how I feel about asking users to contribute back to KDE. I firmly believe that showing users how contributing is easier than they think is more effective than simply calling them out and directing them to the correct resources; especially if, like me, said user suffers from anxiety or does not believe they are up to the task, in spite of their desire to help back.
Last time I talked about websites, I taught how to port current KDE websites to Markdown, and this led to a considerable influx of contributors, since it required very little technical knowledge. This blog post however is directed to people who are minimally acquainted with git, html/css, and Markdown. We will be learning a bit of how Jekyll and scss work too.
This post has now been copied over to https://community.kde.org/KDE.org/Jekyll! Which means the content available on the wiki can serve as a full tutorial explaining how to prepare KDE application websites from scratch using Jekyll. This should in theory enable you to at the very least set up a Jekyll environment, apply content to it, and insert some css in it for a bit of customization!
Please be wary that not every project necessarily wants a website of their own, and so you need to contact the website maintainers either directly or by contacting the KDE Web team over Telegram, Matrix or IRC!
As usual, if you want to skip the explanations and start immediately, you can click here.
The first thing we’ll need to do is install the programs required to create the website. Just install: ruby-dev bundler git using your distribution package manager, and we’re set to go!
Let’s download the KDE repository containing the original KDE Jekyll theme. This way, we can both explore the repo and obtain the examples folder. Run the following command:
git clone https://invent.kde.org/websites/jekyll-kde-theme.git
Inside, there are mainly three folders we should take a look at: /css, /_sass, and /examples.
Inside /_sass, there are several /.scss files which should be the foundation of the KDE theme. If you already have some experience with these files, you should know that they can be imported to any website that uses the theme by adding an @import inside a /main.scss.
Inside /css, the file /main.scss is located. Here you can see that the various .scss files you previously saw in the /_sass folder are being imported into the project. Any extra CSS shoud be contained either within main.scss or any .scss file you create within this folder.
If you check the /examples folder, you can see two folders: /application and /application-components. The first is a general example for building any application website; the latter is useful for bundled applications, as is the case of kontact.kde.org. For the purpose of this post, your main concern should be copying the /application folder to another place, more fitting for work.
In my case, for instance, I was planning to create the website for Subtitle Composer, so I put the folder inside my home folder. I then renamed it to /subtitlecomposer-kde-org, so as to follow the pattern found over KDE’s Gitlab instance, Invent.
With this, we now have an example website to improve. Let’s take a look at what you will change to make it a proper website for a KDE application:
First of all, there are the folders /assets/img and /css. /assets/img is pretty straightforward, it’s where you’ll put any media you want to display on the website that’s not displayed by the theme. The already present app_icon.png is what will be displayed on the upper left of the website, screenshot.png will be used to display the application screenshot inside the main example carousel.
As already mentioned, the /css folder is where you should store any .scss files you’d like to create, in addition to main.scss. Inside it, you should already see home.scss and download.scss. The absolute minimum required should be home.scss, though.
Your example website should also have a .gitignore. This is important since Jekyll generates extra folders and files when compiled, and we don’t want them to be unnecessarily uploaded to our future repository when we push it to Invent.
The two main configuration files you should pay attention to are Gemfile and _config.yml. Gemfile is what determines the use of Jekyll and the KDE Jekyll theme, it should have something like:
ngraham
source "https://rubygems.org"
ruby RUBY_VERSION
gem "jekyll", "3.8"
gem "jekyll-kde-theme", path: '../../'You should always change the path of the jekyll-kde-theme to git, it’s the main way the theme is distributed for all KDE application websites to receive fixes as soon as possible. You also need it if you want to use a dark theme on the website. You need to switch that line to include the following:
gem "jekyll-kde-theme", :git => 'https://invent.kde.org/websites/jekyll-kde-theme.git'
As for the _config.yaml, it’s where most metadata for the website will be stored, and it’s also what determines the website’s structure:
You should change the appropriate information there by checking the previous website for the application you’re designing it for, or by contacting the devs directly if they don’t already have a website.
I’ll elaborate a bit more on the role of this file on the structure of the website later.
After reading the config files, the first file we should take a look at should be index.html.
The section within --- is a bit of metadata determining what should be included on the website, it is called Front Matter. It should be present regardless of whether you’ll be working on an HTML or Markdown file.
Then, you can see a section containing a carousel with only one image. You may have noticed that kHeader was also present within the KDE Jekyll /_sass/home.scss file.
That’s what’s convenient in this kind of setup: you can use resources already available by the theme by just calling them. If you’re already acquainted with those resources, it becomes quite easy to create multiple reproducible builds with them. We will be using a few of those later on.
This is how the index.html looks like by default; Konsole is used as a template website in this case.
Carousels are generally a bad idea unless they are properly implemented, thus the carousel doesn’t come with more than one image by default. However, it is the website maintainer’s choice as to whether it should be used or not.
The line we see there containing {% include blog.html %} serves to insert blog.html in the contents of index.html. blog.html, in turn, pulls the Markdown files inside your /_posts folder. Thus, the result:
Now, let’s take a look at the get-involved.md file now, which should be easier to understand.
Writing in Markdown is particularly easy, and Jekyll interprets each part of Markdown as HTML code, so if you want to add a specific style to something written in Markdown, you’d use its HTML equivalent, so in ## Text for a header, ## would be considered an <h2> tag.
The konqi: /assets/img/konqi-dev.png does not pull from the /assets/img folder from your local project, but rather from the Jekyll KDE theme itself. The theme also provides for its layout on the page, so adding this simple line in your Front Matter will show this adorable Konqi icon properly. If any extra Konqi icon is required, they can be added manually to your local installation and called through a konqi: line.
One particular thing that is shown twice in this image is the use of variables. With {{ site.somedataIwanttoshow }} you can call any information present in your _config.yaml. Image XXXX shows two examples: {{ site.title}} and {{ site.email }}, which display on Image YYYY as Konsole and konsole-devel@kde.org, respectively.
Alright, alright. Let’s build the website already.
So what you previously did if you read the previous section was installing ruby-dev, bundler and git, right? It should be noted that you need Ruby 2.6 as of now. If you only have Ruby 2.7, you’ll face an error in which a gem named eventmachine won’t install. I’ll provide you with the respective commands for Ubuntu/Debian, openSUSE and Arch/Manjaro:
Ubuntu:sudo apt install ruby-dev bundler gitopenSUSE:sudo zypper install ruby-devel ruby2.6-devel bundler gitArch:sudo pacman -S ruby ruby2.6 ruby-bundler git
After that, you likely already cloned the KDE Jekyll repository by using the command git clone https://invent.kde.org/websites/jekyll-kde-theme.git and copied the /examples/application folder elsewhere, renaming the folder to something like /myproject-kde-org, right?
Next you’ll want to change your directory (cd) to the project’s top directory. If it is located in your home folder, you should cd myproject-kde-org.
Already inside, run gem install jekyll --user-install. This will run Ruby’s default dependency manager, gem, which will install the jekyll gem with user privileges, that is, inside your home directory. This is convenient because then you don’t fill your system with gems, and you can install different gems according to the project (not like you’ll need to if you’re just planning on creating one website).
After the command finishes downloading the gems, run bundle config set path 'vendor/bundle' and afterwards bundle install. The first command determines where to store the gems defined in your Gemfile, namely jekyll and jekyll-kde-theme. The command bundle install subsequently installs them. The later takes a bit to finish.
That’s basically it. With that set up, we can generate our website with bundle exec jekyll serve. You’ll see output like this:
As you can see, the website should be available by opening a browser and typing 127.0.0.1:4000. If you’re working on a server without a GUI interface, get your ip with ip a and use it with the command:
bundle exec jekyll serve --host my.ip.shouldbe.here --port anyportIwant
Then access it through another machine on your LAN—this includes your phone, which is convenient when you’re testing your website on mobile.
One nicety about Jekyll is the functionality of auto-regeneration. With this properly running, every change you do to a file on your website will show up automatically on it without requiring a “server restart”, so to speak. With this, you can keep the website running on your side monitor (if you have any) while you change files on your main monitor.
If you get an error about Duplicate Directories, just ignore it. This occurs because of a symlink in /examples/application-components which is quite convenient, and this error does not hinder you from generating your website. If you reeeeeeally don’t want your beautiful terminal output to be plagued by an error message, though, you can just remove the /vendor/bundle/ruby2.6/blablabla/_changelogs and /vendor/bundle/ruby2.6/blablabla/_posts folders which are shown in the error output.
Now I’ll show you some ways I customized and worked on the Subtitle Composer website, the website that allowed me to learn how to handle Jekyll.
The first thing I noticed was the following line used to add a screenshot to the carousel:
<div class="slide-background" style="background-image:url(/assets/img/screenshot.png)"></div>
This means I need to add background-image:url(/path/to/image/either/local/or/from/theme.png) whenever I want to have an element link to an image. I prefer to do so in scss since pure Markdown doesn’t allow to apply styling directly, unlike HTML, so everything stays in the same place.
I could naturally switch the screenshot.png file in my /assets/img folder in order to switch the screenshot, which is what I did; but what about the wallpaper? I have nothing against Kokkini; however, I think keeping a more up-to-date wallpaper makes more sense for a new website. Well, in all honesty, I also wanted to do this because I particularly like the newest wallpapers. 
Apparently the wallpaper was showing up despite not existing in my local /assets/img folder, therefore it was being provided by the theme by default.
Right clicking on the wallpaper and selecting Inspect element immediately shows the css element div.carousel-item-content. However, after some testing, the actual element that needs to be changed is #kHeader. Therefore, on my main.scss file, I added #kHeader {background-image:url(/assets/img/wallpaper.png). This managed to override the wallpaper provided by the KDE Jekyll theme, switching Kokkini for Next.
The next thing I wanted to do was to add a subtitle effect on the name of Subtitle Composer; it seemed like an awesome thing to do, but I had no idea how to do that (I’m not very experienced with web design at all! I actually took way too much time to learn all of this), and so I searched for it in the internet.
The guess that got me in the right direction was thinking that I’d need a thin border around text to convey an effect of subtitle, thus I searched for “css text 1px border”, which led me to this StackOverflow question: CSS Font Border?, with the following code: h1 {color:yellow; text-shadow: -1px 0 black, 0 1px black, 1px 0 black, 0 -1px black;}.
So I included a class named subtitleheader to my original <h1>Subtitle Composer</h1>, allowing me to add .subtitleheader {font-size:30px;color:yellow; text-shadow:-3px 0 #4d4d4d, 0 3px #4d4d4d, 3px 0 #4d4d4d, 0 -3px #4d4d4d;font-weight:bold;min-width:130%} to main.scss after a ton of experimenting until I achieved the desired result. I added similar code to the paragraph describing Subtitle Composer, namely .subtitleparagraph {font-size:20px;color:#eff0f1; text-shadow:-2px 0 #4d4d4d, 0 2px #4d4d4d, 2px 0 #4d4d4d, 0 -2px #4d4d4d;font-weight:bold;min-width:130%}, and so I arrived at this:
So now I need to change the top navigation bar to fit what I needed.
For that, I need to learn how to change some stuff on _config.yaml. Let’s take a look at the code:
This is quite straightforward. A navigation bar can be on the top or bottom section, and each - title: represents an element in the navigation bar, and each element can work as a list if you add a subnav. Despite the url: pointing to an html file, markdown files can be used too without specifying the .md file format.
I changed it to look like so:
Which is way simpler than the default and fits the content I could find about Subtitle Composer that was available both on the Invent project and its old Github.
I also copy-pasted the bottom navigation bar from the KDE Connect website so it gets quite complete on the bottom of the website too.
After that I could work on inserting the content inside the respective .md files.
Let’s take a look at features.md and get-involved.md now.
Anyone acquainted with HTML and Markdown is likely to know that --- is the equivalent to <hr>, it’s an horizontal ruler, that is, it creates a straight horizontal line, which in this case acts sort of like a separator. I used this together with an HTML line break <br> so the header gets more noticeable.
Also note that using --- after the Front Matter will be interpreted by Jekyll as normal Markdown.
The reason I wanted to show this was to exemplify my previous comment about Markdown being interpreted as HTML: if I add a style to the element hr in main.scss, it will work for both the HTML and Markdown notations. So, by adding hr {border-color:#7f8c8d} when using a dark theme, the result should be something like this:
Well, talking about dark themes, what the heck do I need to do to add a dark theme? I already knew prefers-color-scheme was used for that, but I had no idea how it worked. The Mozilla page explains it very well though, you just need to add any style to:
@media (prefers-color-scheme: dark) { any.style {should-be:here;} }
Since the hr element needed to be light only when using a dark theme, and should be standard black everywhere else, I used it inside prefers-color-scheme: dark. So the result was this:
@media (prefers-color-scheme: dark) { hr {border-color:#7f8c8d} }
If you want to test prefers-color-scheme on your browser without changing your local theme, on Firefox you can go to about:config and create a config named ui.systemUsesDarkTheme with a number value of 0 or 1, and on Chrome you can open the Developer console, click on the top right hamburger menu, go to More tools, Rendering, and change Emulate CSS media feature prefers-color-scheme.
I made a few more customizations to the website, as you can check out here. However, the examples I showed are not only enough for anyone to start hacking, but they are also proof of how I managed to learn stuff on my own, search for what I wanted to change on the website, and how I managed to learn all of that in a few months despite working full-time and not having that much free time in general. You can be sure you’re able to do that too!
Additionally, Jekyll seems to be quite performant. It doesn’t use JavaScript and most KDE websites done with it render over 90% performance on Google’s PageSpeed Insights, y’know!
If you’re interested in building a website from scratch using Jekyll for a KDE application, please contact the KDE Web team over Telegram, Matrix or IRC first, yeah? This post was also copied over to https://community.kde.org/KDE.org/Jekyll if you’d rather to check the wiki for these instructions.
It’s a great pleasure to announce that KIO FUSE has a second Beta release available for testing! We encourage all who are interested to test and report their findings (good or bad) here. Note that, the more people who test (and let us know that they’ve tested), the quicker we’ll be confident to have a 5.0.0 release. You can find the repository here.
To compile KIO FUSE, simply run kdesrc-build kio-fuse or follow the README. If your distributor is really nice they may already have KIO FUSE packaged but if they don’t, encourage them to do so!
In this beta, the hallmark features implemented are the ability to read and write without downloading the whole file (smb/sftp/file protocols only) and expiring local nodes so that changes on the remote side become visible. In addition, a new Dbus API was added to map a FUSE path back to a remote URL, used for syncing the terminal panel in Dolphin the main view (needs Dolphin >= 20.07.80).
Thanks,
feverfew
It’s been a while since the last status update on Plasma Mobile, so let’s take a look at what happened since then.
To assist new people in contributing, we organized a virtual mini Plasma Mobile sprint in April. During the three days, we discussed many things, including our current tasks, the websites and documentation, our apps and many other topics. Most of our important tasks have been asigned to people, many of them have been implemented already.
On Saturday, there was a training day, with four training sessions on the technology behind Plasma Mobile:
While the Sprint was not active, we were busy working on Plasma Mobile itself.
Nico mostly worked on fixing bugs. First, files now open correctly in Okular Also, the busy indicator made invisible when it’s not running In ruqola, he fixed a few bugs regarding the layout on small screens.
KTrip now has all providers disabled by default, to make it easier to have a good selection of enabled providers. The list of available connections and the connection details have been redesigned.
It now also allows to open a station’s position on a map.
Tobi has been busy working on the wireless connectivity. Some refactoring and bugfixes allow Wi-Fi connections to be editable now and to create custom connections, enabling users to connect to hidden Wi-Fi networks. Also, there is now a settings module for creating Wi-Fi hotspots
Apart from the work on the wireless settings, he put a lot of work into Alligator, the RSS feed reader for Plasma Mobile. Even though it’s been in development since the previous Plasma Mobile Sprint in February, it’s never really been anounced here. By now, most basic functionality is working, and it’s not even slow anymore!
In the last few days especially, a lot of work was put into things like porting it to Android, getting an (amazing!) icon and getting a proper KDE repository for it. With some more polish, it will be ready for a first release soon.
Dimitris has put a lot of work into calindori. A day view has been created, offering the users the opportunity to review the incidences (events or tasks) of each day. In specific, the incidences are presented in an hour list, according to their start and in case of events end time. The users may navigate between the days as well as return to the current day, using the action toolbar buttons.
A Week view is now available; users can manage tasks and events via a per-week dashboard. On that dashboard, a list view displays the days of each week. The tasks and events of each day can be seen. Upon clicking to a task/event, a new page is opened. On that page, the task/event can be edited or deleted. Users can navigate between weeks using the action toolbar icons.
Bart has made the wifi and wwan buttons in the top drawer toggles instead of opening the settings pages.
Marco implemented a webapp-container in Angelfish, which can be used to ship websites as webapps in Plasma Mobile images.
Jonah later added functionality to Angelfish to allow adding webapps to the homescreen. As webapps don’t have any browser user interface apart from the html content, he added a retry button to the error handler, to allow reloading in case of errors. Jonah also adapted Angelfish’s use of overlay sheets to the new design from Kirigami. The same was done with the time settings module of the settings app.
Recently he managed to workaround a bug causing scrolling in all apps using QtWebEngine, notably Angelfish, to jump around. This was caused by frames being shown in the wrong order. Fixing this was only possible thanks to the debugging of this issue Rinigus Saar did for SailfishOS. Over the last month, he started to rewrite the SMS app SpaceBar, because it became very hard to debug, and the KDE Telepathy API it was using wasn’t well suited for SMS. The new app is directly based on TelepathyQt, just like the dialer. New features include mapping of contacts to phone numbers of incoming conversations, starting chats without having to add a contact for the number, visual and functional improvements. Anthony Fieroni fixed incoming conversations in the new app.
While the app is already working better than SpaceBar, we are still working on fixing the last bugs and integrating it with the dialer internally. Jonah also updated the design of the application headers, which are used across all Kirigami apps according to the suggestions of the KDE Visual Design Group.
Rinigus redesigned the highlight of the current tab in Angelfish, and implemented an overlay which shows the history of the current tab.
Nico worked on improving the dialer UI, which now makes use of the new SwipeNavigator component from Kirigami.
This post shows what a difference new contributors can make. Do you want to be part of our team as well? Just in case we prepared a few ideas for tasks new contributors can work on. Most coding tasks require some QML knowledge. KDAB’s QML introduction video series is a great resource for that!
For a change, let’s talk about a topic other than notifications. More than five years ago (can’t believe how time has passed) I took over maintainership of PowerDevil, Plasma’s power management service. While I did a lot of cleanup and feature work in the beginning, there haven’t been many major changes for some time.
One of the first features I added back then was smooth brightness changes. PowerDevil supports three ways of changing screen brightness: through XRandR configuration, through DDC (display data channel, for desktop monitors, experimental and not built by default), and by writing to sysfs (/sys/class/backlight or /sys/class/leds). Since the latter requires privileges and uses a helper binary through KDE’s KAuth framework, I only implemented the animation for the XRandR code path, which was executed in the same process.
Obviously, XRandR doesn’t work on Wayland, and it seems that modern graphics drivers don’t support changing brightness through it anymore either. I recently sat down and wrote a patch to have the helper binary execute a similar animation. KAuth works quite magically by exposing methods defined in an .actions file through DBus and then calling them as slots through Qt’s meta object. Unfortunately, the way it is designed doesn’t allow for delayed replies, which I wanted to use so the job only finished once the animation was completed in order to keep PowerDevil’s state consistent. I then found that KAuth randomly keeps its helper running for 10 seconds, more than enough for a 250ms animation.
I’m not too happy with the implementation and the brightness handling class itself has turned into quite a mess over the years, and having three (four, if you count keyboard brightness) completely separate brightness controls entangled within doesn’t help. To clean it up I want to get rid of XRandR brightness support. Since I don’t know if that’s actually still being used – I surely haven’t used it ever since I ditched the Intel driver – please do me a favor and check what brightness control your machine uses by running PowerDevil from command line (make sure to quit the running process first, and executable location will vary depending on your distribution):
QT_LOGGING_RULES='powerdevil=true' /usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil
When using XRandR it will say “powerdevil: Using XRandR”, otherwise it’ll be “Xrandr not supported, trying ddc, helper”. (It’ll always say it tries the DDC helper even when it isn’t built with that.) If it actually uses XRandR please tell me and what GPU and driver you are using. That would help a lot in judging the impact of removing this! If it is indeed using XRandR, please see if you can still manually write into /sys/class/backlight/[whatever devices there may be]/brightness to alter screen brightness. It prefers XRandR but that doesn’t mean that sysfs couldn’t be working, too. Please also tell me the value of max_brightness in there. Feel free to chime in on the plasma-devel mailing list thread I started on the subject to share your thoughts. Now you can see why having some telemetry via KUserFeedback would be tremendously useful for improving code quality and, er, “user experience”.
Lastly, of course there can’t be a post on this blog without mentioning notifications: in the upcoming Plasma 5.19 the “low battery” notification is marked as critical which will make it show on top of full screen windows. Previously, while watching a video, playing a game, or giving a presentation, you likely didn’t see an advance warning. Only once battery reached critical levels would you get told to pick up a charger, running, tumbling down some stairs, frantically searching for it, before the 60 second timeout for sleep or standby expired. (Seriously, the reason why throughout the years I prolonged the timeout from the original 30 seconds and eventually added a “cancel” button was to stop fellow Plasma hackers injure themselves on sprints when running to their bags to fetch a charger.)
KDAB’s Kevin Funk presented Using Modern CMake with Qt at Qt Virtual Tech Con last month.
He reported that the Qt Company did a great job moderating the sessions at this event, and there was a lively Q&A at the end – Kevin had to pick from about 60 questions, so this is a hot topic.
Now the event is over you can access the talks, including Kevin’s and the answers he had time for, and also Kevin’s slides, below this abstract.
Prerequisite: No prior CMake experience required
CMake is a cross-platform build system, with powerful APIs for finding dependencies of various or specific versions, and with many abstractions for platforms, compilers, other build systems, and dependencies.
The next major Qt version, Qt6, will be using CMake internally as its build system, so the CMake integration with Qt will likely get tighter and more versatile in the long-term.
In this talk, we’ll be introducing Qt specific CMake functionalities, in order to find and use Qt5 inside your personal CMake-based project, using modern CMake capabilities. We are going to discuss how to find Qt installs using CMake’s find_package function and how to find specific Qt versions when multiple versions are installed.
Further than that, useful CMake variables such as CMAKE_INCLUDE_CURRENT_DIR, CMAKE_AUTOMOC, CMAKE_AUTORCC, and CMAKE_AUTOUIC will be explained in detail and how the use of the CMake integrations can speed up the build drastically.
Last but not least some of the additional supplied Qt related CMake functions, such as for big resources or translation support will be discussed.
Target audience: Build Engineers or Software Engineers who would like to know more about using Qt under CMake.
Download Kevin’s slides: QTVTC20 – Using Modern CMake – Kevin Funk
Kevin has actively developed with Qt/C++ since 2006 and has a special interest in tooling and profiling. He’s an active contributor to KDAB’s GammaRay analyzer (a high-level Qt application debugger) and has a strong emphasis on state machine tooling. He is a co-maintainer of the KDevelop IDE, a powerful C/C++ development environment backed by Clang, and is pushing for cross-platform success inside KDE. Kevin holds a Masters Degree in Computer Science.
Download Kevin’s whitepaper on CMake and Qt…
The post Using Modern CMake with Qt appeared first on KDAB.
Last week, as part of my GSoC Project with DigiKam, I implemented a new feature to effectively Ignore faces. The feature had been requested multiple times, and was in-fact necessitated due to the power of DigiKam’s Facial Recognition Algorithm.
DigiKam will often detect and then try to recognize faces in photos that the user perhaps doesn’t recognize himself! With the implementation of this new feature, the user could just mark such faces as Ignored. Faces marked as Ignored will not be detected by the Face Detection process in the future, nor will they be considered during the recognition process.
Only Unknown Faces are allowed to be marked as Ignored, this stems from the logic that if you confirmed a face, i.e. gave it a name, then it is someone you know, and hence marking them as Ignored doesn’t really make sense.
To mark an Unknown Face as Ignored, press the 
sign that appears when you hover over a face.
If this is your first time marking a face as Ignored, this will lead to the creation of a new tag (named Ignored) in the People Sidebar. The reason that the Ignored tag isn’t created automatically at startup (like Unconfirmed and Unknown) is that most users would not require the Ignored functionality, hence it is only created when necessary.
And it’s that simple! In case you accidentally marked a face as Ignored, you can press the 
to un-mark the Ignored face, and effectively undo the procedure.
Even though the feature seems quite simple at first glance, it involved a lot of changes to the underlying code-base. I’ll perhaps go over details of the implementation in a later post.
DigiKam is the ultimate cross-platform application for digital photo management. Download it for free! : https://www.digikam.org/download/
I have started working on my project earlier due to the uncertain times that we find ourselves in. Hence this is Week -1 report, a week earlier than the official start of coding period. This week corresponds to Week 1 of the planned timeline.
This week was easier than expected. Adding the storyboard docker to Krita’s plugin system was very easy, thanks to the numerous dockers already implemented. Implementing outer GUI was tougher than that, but it was easy on absolute terms. The GUI consists of four QToolButtons namely Export, Comment, Lock(Icon), Arrange(Icon) and a QTableView(which will be promoted to a custom view). Three of these buttons Export, Comment and Arrange have a menu associated with them. Lock is a toggle button.
Export Button’s menu is simple and consists of QActions corresponding to pdf and svg export formats. These buttons would open a Dialog. The dialog is not yet implemented.
Comment button’s menu consists of a QListView and two QToolButtons. The QListView will be drawn based on the comments in main model’s data. This menu is not fully implemented yet. The (…) button is delete button.
Arrange button’s menu consists of 2 button groups Mode and View. The button groups consist of QRadioButtons corresponding to the values offered in Mode and View. This menu is setup so that it stays open after choosing an option, as the user might want to change more than one option. e.g. they might want to change view to column and mode to thumbnail at the same time.
Next week I would try to write unit tests for delegate class, add details to documentation, implement the Storyboard Item class and start implementing the MVC classes.
The KWinFT project with its two major open source offerings KWinFT and Wrapland was announced one month ago. This made quite some headlines back then but I decided to keep it down afterwards and push the project silently forward on a technical side.
Now I am pleased to announce the release of a beta version for the next stable release 5.19 in two weeks. The highlights of this release are a complete redesign of Wrapland's server library and two more projects joining KWinFT.
One of the goals of KWinFT is to facilitate large upsetting changes to the internal structure and technological base of its open source offerings. As mentioned one month ago in the project announcement these changes include pushing back the usage of Qt in lower-level libraries and instead making use of modern C++ to its full potential.
We achieved the first milestone on this route in an impressively short timeframe: the redesign of Wrapland's server library for improved encapsulation of external libwayland types and providing template-enhanced meta-classes for easy extension with new functionality in the future.
This redesign work was organized on a separate branch and merged this weekend into master. In the end that included over 200 commits and 40'000 changed lines. Here I have to thank in particular Adrien Faveraux who joined KWinFT shortly after its announcement and contributed several class refactors. Our combined work enabled us to deliver this major redesign already now with the upcoming release.
Aside from the redesign I used this opportunity to add clang-based tools for static code analysis: clang-format and clang-tidy. Adding to our autotests that run with and without sanitizers Wrapland's CI pipelines now provide efficient means for handling contributions by GitLab merge requests and checking back on the result after merge. You can see a full pipeline with linters, static code analysis, project build and autotests passing in the article picture above or check it out here directly in the project.
With this release Disman and KDisplay join the KWinFT project. Disman is a fork of libkscreen and KDisplay one of KScreen. KScreen is the main UI in a KDE Plasma workspace for display configuration and I was its main contributor and maintainer in the last years.
Disman can be installed in parallel with libkscreen. For KDisplay on the other side it is recommended to remove KScreen when KDisplay is installed. This way not both daemons try to meddle with the display configuration at the same time. KDisplay can make use of plugins for KWinFT, KWin and wlroots so you could also use KDisplay as a general replacement.
Forking libkscreen and KScreen to Disman and KDisplay was an unwanted move from my side because I would have liked to keep maintaining them inside KDE. But my efforts to integrate KWinFT with them were not welcomed by some members of the Plasma team. Form your own opinion by reading the discussion in the patch review.
I am not happy about this development but I decided to make the best out of a bad situation and after forking and rebranding directly created CI pipelines for both projects which now also run linters, project builds and autotests on all merge requests and branch pushes. And I defined some more courageous goals for the two projects now that I have more control.
One would think after years of being the only person putting real work into KScreen I would have had this kind of freedom also inside KDE but that is not how KDE operates.
Does it need to be this way? What are arguments for and against it? That is a discussion for another article in the future.
There is an overall technical vision I am following with KWinFT: building a modern C++ framework for Wayland compositor creation. A framework that is built up from independent yet well interacting small libraries.
Take a look at this task for an overview. The first one of these libraries that we have now put work in was Wrapland. I plan for the directly next one to be the backend library that provides interfacing capabilities with the kernel or a host window system the compositor runs on, what in most cases means talking to the Direct Rendering Manager.
The work in Wrapland is not finished though. After the basic representation of Wayland objects has been improved we can push further by layering the server library like this task describes. The end goal here is to get rid of the Qt dependency and make it an optional facade only.
You can try out KWinFT on Manjaro. At the moment you can install KWinFT and its dependencies on Manjaro's unstable images but it is planned to make this possible also in the stable images with the upcoming 5.19 stable release.
I explicitly recommend the Manjaro distribution nowadays to any user from being new to Linux to experts. I have Manjaro running on several devices and I am very pleased with Manjaro's technology, its development pace and its community.
If you are an advanced user you can also use Arch Linux directly and install a KWinFT AUR package that builds KWinFT and its dependencies directly from Git. I hope a package of KWinFT's stable release will also be soon available from Arch' official repositories.
If you want to contribute to one of the KWinFT projects take a look at the open tasks and come join us in our Gitter channel. I am very happy that already several people joined the project who provide QA feedback and patches. There are also opportunities to work on DevOps, documentation and translations.
I am hoping KWinFT will be a welcoming place for everyone interested in high-quality open source graphics technology. A place with low entry barriers and many opportunities to learn and grow as an engineer.
