So, I decided to do Advent of Code this year too. I usually get stuck part of the way, but I still think that it is a fun exercise.
This year the plan is to use python and pytest the whole way through. Every day that i learn something that I want to remember, I add a til.txt file in that sub-directory. You can follow my progress and learnings in the git repository.
The lessons this far includes:
readline to read lines, the line-break is included, so len(text) will be one character more than expected. Strip your strings!if – elif – elif – elif, make sure to include an else, even though you know that all cases are covered. I run assert False in the else clause.As you can see, these are on the level of small snippets of wisdom right now. I’m sure it will be more interesting as the problems become more complex.
We are happy to announce the release of Qt Creator 4.14 RC !
What does that mean?
It means this https://invent.kde.org/graphics/okular/-/commit/3129b642f996589f1c7fcee513741e1993924241
That is, you add JPEG::JPEG to target_link_libraries, and that's it, no need to add the includes, the compile_definitions and whatnot.
This has multiple advantages to the old mode:
TSDgeosJPEG::JPG it will fail at cmake stage
To know if you can use that you'll need to use the cmake help, for example the imported target is described at https://cmake.org/cmake/help/latest/module/FindJPEG.html
Now we don't probably depend on cmake 3.19, do we? So we need to make sure the cmake we say we support has that, so use the combo on the top of that page to go and find which version introduced it, for JPEG we can see it was cmake 3.12
Four years ago I bought a OnePlus 2 for 319€, nowdays it still is good hardware, it's better or as good as most of the mid to low end phones in the market.
But it has a big-ish problem, it is stuck on Android 6, which not only is old and probably full of security holes, it is starting to not be supported by some apps.
Solution: LineageOS.
It provides Android 10 for my phone and works flawlessly (from what i can see, only been using it for 4 days), so the fact that "some randos" (with all my love, I'm a rando) can make it work, means that the manufacturer could have if they wanted, they just chose not to.
It's really sad because if i wasn't a geek that knew how to put LineageOS on the device i would have probably ended up buying a new phone, making the world be fill with more junk.
Let's hope the more open devices like the PinePhone KDE Community Edition put an end to this :)
I’ve now had my Lenovo ThinkPad X1 Yoga laptop for about 6 months, so I thought I’d provide a quick update about how it’s going to use this laptop every day with openSUSE Tumbleweed running KDE Plasma. Let’s explore what’s changed since then:
Initially, I complained about some aspects of the keyboard layout, but I’ve gotten used to the Home/End/PageUp/PageDown positioning, and the swapped position of the Fn and Ctrl keys. These are fine now. Lack of media keys is okay too since I’ve used the Shortcuts KCM to set my own. However I just can’t get used to the PrintScreen key being between the right Alt and Ctrl keys. I probably press it by accident 10 times a day and bring up Spectacle when I don’t mean to. One of these days I should get around to using xmodmap or something to turn it into a right Meta key, and they maybe make the F11 key which currently does nothing be the new PrintScreen key.
In my initial review, I had some complaints about the speakers and audio configuration. It turned out there there were issues both in the Kernel and PulseAudio that prevented the speakers from reaching their full potential, and all of those issues have been resolved now. The speakers sound awesome (for a laptop, of course). In addition, all the software issues in Plasma are fixed too. Everything audio-related is now perfect. I love listening to music on the machine. It sounds so good!
The camera’s lag has gone away due presumably to improvements in some layer of the software stack beneath KDE. The quality is still not fantastic, but that’s generally what you can say about any laptop webcam these days. It’s sufficient for Zoom and BigBlueButton meetings.
Over the last 6 months, power management got worse and worse. Battery life continually declined and then eventually the battery started spontaneously reporting its charge percent as 0% while unplugged. At other times it would refuse to charge. This was a disaster for, well, actually using it as a laptop!
I called for warranty service and a technician replaced the battery recently. The issues immediately disappeared. I haven’t experienced any more buggy behavior, and the battery life has increased to about 6 hours with real use, which is probably acceptable given the fancy 4K screen. Hopefully there are more wins to be had through additional kernel optimizations in the future. I guess my original battery was just a lemon.
I love the 4K screen! Everything is so sharp and crisp!
..a little bit too much so, perhaps.
4K turns out to be kind of overkill for a 14″ screen. Its resolution of 3840×2160 pixels effectively becomes 1920×1080 with 200% scaling, but the thing is, 1920×1080 makes everything rather too small on the screen. It would be ideally suited for a larger 15.6″ screen, but at 14″ and even 13.3″, you need to use fractional scaling or increase the font size to make things big enough to be legible. So that’s what I’m doing: I currently have the scale set to 200% and I use 11pt fonts, making everything approximately 10% larger with no blurriness since it doesn’t scale icons, lines, or pixmaps. It’s as if I had an effective resolution of 1745×981.
Lenovo offers this laptop with a 1440p screen option, but that’s not right either: its 2560×1440 resolution, when scaled to 200%, gives you only an effective resolution of 1280×720, which is much too low and everything on the screen becomes comically large! Well maybe not comically large, but too large for my tastes, at least. 
All windows need to be maximized, and even then, they will feel starved for space. This might be an acceptable resolution for a 12-13″ screen, but not 14″.
I think the ideal high DPI resolution for a 14″ lies between 1440p and 4K; something like QHD+, which is 3200×1800. You’d have effectively 1600×900 with 200% scaling, which would be perfect. 4K should be saved for the 15.6″ screen laptops which will have room to fit an enormous 90+ Wh battery required to provide adequate endurance with such a power-hungry panel.
There’s one more problem with the 4K screen: it’s driven by an integrated Intel UHD 620 GPU which simply cannot push the pixels fast enough. I regularly experience dropped frames and choppiness in full-screen GPU-accelerated animations. Even worse, full-screen CPU-bound rendering (like YouTube videos in Firefox) will kick the CPU into overdrive and massacre the battery life. Gaming? forget about it.
The situation would be improved with either Intel’s 11th gen architecture or AMD’s Ryzen CPUs, both of which feature radically better integrated graphics capabilities. But I’m stuck with the old Intel UHD 620 which is pathetically underpowered for the hardware that’s being thrown at it. Oh well. Lesson learned.
On a happier note, the touchscreen now works out of the box due to distro patches for the problem I mentioned in the initial review. However I still haven’t managed to get the 10-bit color support working.
Every single scaling issue I found is now (or already was) working on Wayland!
On X11, all the major issues I ran into are fixed, but there are still a lot of minor rough edges. Many are virtually unfixable, sadly. Ultimately Wayland is the future, so it’s good that it’s been selected as an official KDE goal and is improving at warp speed right now!
I’m happy with this laptop now. It does what I need and it’s a pleasure to use. Here’s what’s great about it:
What would make it perfect:
OpenUK is looking for two charismatic and diligent individuals to be judges in the 2021 OpenUK Awards. After a successful first edition in 2020, OpenUK are looking to find two judges from the Community to judge the Awards with Katie Gamanji, our head Judge for 2021.
To be considered as an OpenUK judge:
The Judges’ work requires a dive deep into the nominations and diligent investigation of all of the applications to come to a well informed and balanced decision.
Nomination form is open now if you’d like to help or you can think of someone who would be suitable.
Web applications can be pretty useful at times when a native application is not available. In today’s tutorial, we will make an AppImage file of a web application using a tool called nativefier-appimage. nativefier-appimage makes it very easy to create AppImages of your favorite web applications and share them. It leverages the web application creation process by using nativefier. It packages the resulting web application in an AppImage for portability using appimagetool (which is included by default in Nitrux).
Note: We might change the name at some point if more features are added to the code (if needed).
To make our AppImage for this tutorial, we will need to install npm.
sudo apt install npm --no-install-recommends
Now we need to download nativefier-appimage. After downloading the program, give it execution permissions.
wget https://raw.githubusercontent.com/Nitrux/nativefier-appimage/main/nativefier-appimage chmod +x nativefier-appimage sudo mv nativefier-appimage /usr/bin
That’s all we need.
Now let’s create a web application. For this tutorial, we’ll create an AppImage of a WebGL game called HexGL. All we need to do is run nativefier-appimage, appending the name of the application and the URL.
nativefier-appimage HexGL http://hexgl.bkcore.com/play
Our AppImage will be created, and now we can move it to ~/Applications so that it’s integrated into the desktop.
To test it, we launch it from the menu.
And it works!.
We even have support to use the global menu or the HUD.
appimagetool HexGL.AppDir
That’s it; this concludes today’s tutorial.
The post Making a web application AppImage in Nitrux appeared first on Nitrux — #YourNextOS.
PinePhone KDE Community edition pre-orders start from today, and we are continuously working on polishing the software that will be shipped with it.
Plasma Mobile is a user interface for phones and tablets, just like Plasma Desktop is for notebooks and desktop PCs.
There are various distributions that package Plasma Mobile,
Although there is some overlap between the Plasma Mobile and the KDE Neon team, Plasma Mobile is not tied to KDE Neon.
The Manjaro team has experience with the PinePhone hardware from building their images for the PinePhone shipping with Phosh. To provide the best Plasma Mobile experience, we decided to build on top of their work.
The KDE Community PinePhone will come with Plasma Mobile running on a customized installation of Manjaro ARM, giving you access to mobile applications from other environments already packaged in Manjaro, and the proven hardware support known from other Manjaro images.
If you would like to see a preview of what will be shipped with PinePhone KDE Community edition. You can download unstable nightly image from their website
We also aim to work with the KDE Neon and postmarketOS teams in the future to improve the support for Plasma Mobile in their distributions. This will ensure that you will be able to use Plasma Mobile in your favorite distribution.
We are pleased to announce the launch of Nitrux 1.3.5. This new version brings together the latest software updates, bug fixes, performance improvements, and ready-to-use hardware support.
Nitrux 1.3.5 is available for immediate download.
sudo apt install -yy nvidia-driver-450 nvidia-settings nvidia-prime ubuntu-drivers-common sudo apt install -yy --reinstall nx-desktop-settings-legacy
To report bugs, please use our bug tracker at GitHub.
To see a list of previous changelogs, click here for the changelogs archived at our site, or click here for the changelogs archived at Sourceforge.
The post Changelog: Nitrux 1.3.5 appeared first on Nitrux — #YourNextOS.
With Qt 6 well on its way, it’s about time we go over some of the internal changes and optimizations made to Qt 3D for the upcoming release.
In a separate article, my colleague Mike Krus has already highlighted the API changes we’ve made in Qt 3D for Qt 6. This post will dive into the internal changes.
Back in 5.14, we got rid of the Aspect Thread. Yet we still had a Render Thread. On paper, having a dedicated thread would allow you to send drawing commands to the GPU while preparing commands for the next frame. This could potentially help with maintaining a high frame rate, if command submission took a long time. In practice, this worked only in the case that Qt 3D was used as standalone (without QtQuick).
The Qt Quick renderer has blocking synching points. Synching Qt Quick and Qt 3D content forces us to wait for all drawing commands to have been performed before proceeding to the next frame. Not only does this make having a RenderThread pointless, but it also results in separate code paths to handle Qt 3D driven by QtQuick.
Moreover, having an extra thread also adds a cost with general synchronization, scheduling, and memory allocations. In addition, the more threads you have, the more things get complex and hard to troubleshoot. For these reasons, we decided that whatever little speed gain we obtained from having a Render Thread didn’t justify keeping it.
In essence, this means that Qt 3D for Qt 6 only uses the main thread and a thread pool to spawn jobs in every frame. The rendering either takes place in the main thread or in the QtQuick SceneGraph thread, if using QtQuick.
The backend of Qt 3D made heavy use of the Qt containers, like QVector and QHash. Much to our surprise, it appeared that QVector was adding a little bit of overhead everywhere we used it (mostly because of copy on write checks). Lots of something small can add up to something big. We were actually paying a high cost simply by using QVector.
Therefore, we’ve switched to using std::vectors in most of the Qt 3D backend. This work started with 5.15 and was pursued for Qt 6, as well. The API is not as nice as that of Qt’s vector but we have seen noticeable improvements in critical code paths on complex scenes. In contrast with the backend, the public API still relies on QVector (well QList in Qt6).
The Qt 5 architecture is tightly tied to OpenGL. Hence, our efforts with Qt 3D were primarily focused on providing an efficient OpenGL renderer. Towards the end of the Qt 5 series, The Qt Company started working on abstracting access to various graphics APIs with RHI (Rendering Hardware Abstraction).
In Qt 6, the tight coupling with OpenGL in the code will be removed in favor of calls made through the RHI abstraction layer. This signifies that Qt and, more specifically, Qt Quick will be able to work with different rendering backends (DirectX, Vulkan, OpenGL, Metal), depending on the target, the platform, and what’s available.
Over the past couple of Qt releases, under the hood Qt 3D has slowly been reworked. The aim being to decouple the rendering from the processing code. In that sense, a plugin mechanism was introduced to load the renderer as a plugin. This has been finalized for Qt 6 and the existing OpenGL renderer is now a dedicated plugin. In parallel, we’ve started working on a new RHI-based render plugin.
The plan for Qt 3D for Qt 6 is to have the RHI-based renderer become the default. However, you will still be able to use the OpenGL render plugin if you wish to. A lot of work has been put into the OpenGL renderer and it is currently more mature and feature complete that what can be done with the RHI plugin. In reality, for most use cases, the RHI renderer will probably be enough.
API-wise this has little impact on code. The only changes required to have Qt 3D work with the RHI backend is to define a RHI compatible QTechnique on custom QMaterial classes. The default materials provided in the Qt 3D Extra modules have been updated.
Of course, this plugin mechanism will also allow you to have dedicated renderers for Metal or Vulkan, if the RHI plugin is deemed insufficient.
By default, Qt 3D will try to load the RHI plugin and let RHI decide which backend to use. However, that behavior can be overridden by using the following environment variables and values:
Note: When using Scene3D, the OpenGL plugin should only be selected if you’re forcing RHI to use its OpenGL backend.
The development of RHI is driven with the use cases of Qt Quick and Qt Quick 3D in mind. This implies that not all the features required for more advanced use cases are available.
When it comes to Qt 3D, this means that what the FrameGraph API allows you to describe might not be translatable to existing RHI commands.
One of the interesting features of modern graphics APIs, such as Vulkan, is the ability to use several threads to build the list of rendering commands. This maps perfectly to Qt 3D’s multithreaded architecture. Unfortunately, RHI does not currently support multithreading. Due to this limitation, while Qt 3D still leverages multiple threads to prepare commands, it needs to serially generate the RHI commands from a single thread. As a result, things are not likely to be any faster than what was achieved with the OpenGL renderer when it comes to command generation and submission. Arguably, there might still be a gain if the driver works better with whichever RHI backend gets used.
The OpenGL backend maps only to the ES 2 / GL 2 feature set.
Another hurdle with the current implementation is it limits each render target to a single clear call. For instance, you cannot clear the depth buffer after having drawn something. Given that, the workaround is generating more render targets and attachments than would otherwise be required and manually blitting between these.
As can be seen, a fair amount of work has been ongoing these past few months. From new performance optimizations in the backend to new decoupled rendering plugins, Qt 3D is ready for the next major Qt release. While most of these changes will be transparent for Qt 3D users, they still represent nice improvements.
KDAB provides a number of services around Qt 3D, including mentoring your team and embedding Qt 3D code into your application, among others. You can find out more about these services here.
If you like this blog and want to read similar articles, consider subscribing via our RSS feed.
Subscribe to KDAB TV for similar informative short video content.
KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.
The post Qt 3D Renderer changes and improvements in Qt 6 appeared first on KDAB.
