If you are here from Part 1, welcome back. If you are wondering why we started at Part 2, go to Part 1.
So, you tried everything from the first part (that was relative to you), and your screen is still a backlighting test? No problem. (Well.. I mean, clearly there is but you know what I mean) We’ve gathered another five reasons this could be happening and how to go about fixing them.
Issue 6: Directional light is pointing in the wrong direction.
There are a few choices when it comes to choosing a light source for your scene. You can even add more than one. So we have Point lights, Directional lights, Spot lights and Area lights. You can then also have emissive textures that will act as a light source. Some of these get tricky… say, if you have a Spot or Directional light, you have to make sure they are pointing at something. For testing, you can always have a point light in the scene but even with these, you have to make sure they won’t be ‘inside’ an object, aren’t black and have a decent brightness.
Issue 7: It’s so dark in here. Did you not turn any lights on?
If using a lighting model, ensure the lights are actually enabled. A good test here is to set a temporary
glClearColor (eg pink) – this will usually show un-lit geometry as black. Another solution is to set an ambient colour term and/or changing the background colour to something lighter.
Issue 8: Are you supplying enough power to your Raspberry Pi 4?
The Raspberry Pi 4 has dual HDMI outputs. Using the Qt EGLFS backend, these are available as different displays – so can run two different Qt applications, one full-screen on each. But if your system is near the limits of its power supply (and the onboard power monitor is quite picky, on the Pi) – the second display might fail to initialise. When debugging this problem, we initially tested different OpenGL backends and QPA plugins, but none of these made any difference. Very occasionally both displays would work, but mostly the second one would fail to initialise with an EGL error. A beefier power supply fixed the problem immediately. (Sometimes, it’s really not a software problem)
Issue 9: The GL context won’t create.
This can happen for instance if you upgrade your drivers (especially common with Linux and NVidia cards) and don’t reboot, there’s a high chance that your system won’t be able to create a GL context anymore. To make sure that this is the issue, start a simple 3D program such as
glxgears. If it does not work, only one solution : reach for that restart button.
For more info, see: Checkliste Allgemein (German)
Issue 10: Return of the mac. – You’re using the wrong profile
OpenGL has been around for a while and has many version. Maybe you are using something that requires a more recent version of OpenGL? One thing that is more subtle, especially when updating old code to more modern practices, is the concept of profile. As of 3.2, contexts can be created with a Core profile or a Compatibility profile. The latter preserves compatibility with older fixed function pipeline code and settings. However, it is optional for drivers to implement that profile. Apple, in its wisdom, has decided not to do so. So if you ask for a Compatibility profile, it will create a 2.1 context, and you will not be able to use 3.0 or later features.
So, make sure Core profile is enabled, on the default
Other cross-platform issues are quite common. For example, NVIDIA drivers tend to be forgiving and accept using
texture2D() in shaders even though it should not be allowed in a Core profile. So test on as many platforms and driver setups you can lay your hands on.
Once you’ve double checked the camera settings, shaders and your model settings, 6, 7, 8, 9, and 10, you should be good to go! If not, why not comment your issue below and we’ll try to get it in the next part.
The title of this post is a somewhat common gripe among users. Its obvious answer is that resources are limited and people were working on other things.
Duh! Not very helpful.
We need to dig deeper and find the implicit question, which is “Why wasn’t [thing that I care about] prioritized over other things?” This is a more accurate and useful question, so we can arrive at a more accurate and useful answer: because other things were deemed either more important or more feasible to fix by the people doing the work.
Why would other things be deemed more important? For bugs, it’s because they affect everyone and are trivially reproducible. The ones that get overlooked tend to be more exotic issues that are not easily reproducible, or only affect niche use cases or hardware. Put bluntly, it’s appropriate that such issues are de-prioritized; it should be obvious that issues which affect everyone and are trivially reproducible are more important to fix.
Let’s step back a moment: in my experience, this is exactly the same as in closed-source software companies. Every piece of closed-source software has multi-generational bugs, baffling mis-features, and things that make you wonder, “jeez, why didn’t they fix this years ago?” Anybody who uses Windows, macOS, Android, or iOS can rattle off half a dozen examples instantly. So it’s not like FOSS is especially bad here.
Still, it’s still not a very satisfying answer if you have an exotic use case or hardware that exposes you to an annoying issue.
However, it leads to one of the beautiful advantages of open-source: you can actually dig into the code and fix the issue yourself, then submit the fix! If you lack those kinds of technical skills, you can learn them, or maybe cajole a technically savvy friend into doing it. Or you can sponsor a developer to fix it, paying them directly. You can write a polite blog post about the issue to draw attention it. You have options.
These are all options you don’t have in the closed-source world, where your only option is to live with the issue until it happens to come to the attention of an executive, manager, or other decision maker who experiences it, or when user feedback indicates that it’s not as exotic as originally believed. However this is totally random; you have no control over the process. Also, once this happens, engineers are pulled off other tasks and asked to fix the issue. So while it does eventually get fixed, no new engineers are ever hired specifically to fix little issues, so as a result the pace of development for everything else slows down a tiny bit.
The open-source world has a real advantage here, in my opinion. There are many more ways for users to get involved in fixing the problems that affect them.
So what a great time it is to fix some of the little annoying issues you’ve been living with forever! If you’re strapped for ideas, you can find some lists of bugs here. We make it really easy to compile KDE code from source, so you can get hacking. Check out https://community.kde.org/Get_Involved/development
So what are you waiting for? GET TO DA CODE!
I’ve been doing all my development work on a late 2016 HP Spectre x360 for the past few years. Though a fantastic machine overall, it’s starting to fall apart: the screen backlight has partially burned out, the battery barely holds a charge anymore, and the trackpad sends a double or triple click when I press down on it. This thing has been worked hard and dragged all over the country and the world, so it feels like the time is coming for a replacement.
So I did what a typical OCD nerd does for a major purchase: I made a spreadsheet with all reasonable options and gave myself terrible analysis paralysis!
For my research, I found two resources in particular to be invaluable: notebookcheck.com for its exhaustive long-form technical reviews, and Lisa Gade’s MobileTechReview YouTube channel for focusing on each machine’s overall user experience.
After nearly a month, I made my decision: the late 2019 Dell XPS 13 with a 6-core CPU which I figured would really speed up my code compile times, and the rest of the laptop seemed super high quality. Unfortunately, after it arrived I found that I did not like the feel of the keyboard: the key activation force was quite mushy, and the travel was low. But even worse, the display suffered from unbelievably terrible ghosting–which I had been warned about in reviews, but foolishly ignored–and it emitted an awful coil whine when in use. I sent it back. What a nuisance!
So I moved on to the second laptop in my list: the early 2020 HP Envy 13. I ignored reviews complaining about the trackpad surface not having a glass coating, which again was stupid: I didn’t like the feel at all of the rough plastic texture. But the rest of the laptop was solid, and the trackpad surface wasn’t a fatal flaw as these tend to smooth out over time in my experience. I decided to keep it. Not having yet wiped the disk to install openSUSE Tumbleweed (my current OS of choice), I performed the initial set of Windows updates just in case there were any firmware updates. It completed and I rebooted… and then the laptop became a brick! It was stuck in a half-on-half-off state, with the power LED illuminated, but no activity. The laptop could neither be turned on, nor fully powered down. I returned that one too.
So now I’m kind of feeling stuck. Out of two well-researched laptops, I’ve gotten two lemons, and I’m feeling like it’s time to reach out to the wider KDE community for assistance.
I need your help to find a good laptop!
This will be my one and only computer, used for both work/KDE development and also my personal stuff, so like Mary Poppins, I need for it to be practically perfect in every way (that’s not too much to ask, is it!?):
First, it needs perfect or near-perfect Linux compatibility; there’s no point in buying great hardware if it doesn’t work with your software.
Next, the built-in input and output devices that I’m going to actually use the computer with must be perfect:
Next, it needs to be powerful. I want 16 GB of RAM with excellent multi-core CPU performance to improve my code compilation times. This means good thermal management too, so that that performance can be maintained and the machine doesn’t damage its battery or other internal components with excessive heat, which I suspect happened with my current machine.
Also, I need for it to not have an NVIDIA GPU. I have no graphical needs beyond what an integrated GPU can accomplish, and don’t want to deal with Plasma-on-NVIDIA drama. Sorry, NVIDIA.
The machine needs to have a solid and durable metal case, as I will be traveling domestically and internationally with it multiple times a year (once the world beats COVID-19, that is). For similar reasons, it should be reasonably lightweight and get very good practical battery life. Extreme thinness is not required, but excessive thickness would be nice to avoid, as I like to travel to Europe for work events and conferences with only a backpack and no checked or hand luggage. An excessively thick laptop takes up space needed for socks and underwear (unless I’m going to Germany, in which case I wash them in my hotel room and dry them on the towel warmer! TMI… sorry-not-sorry!).
Finally, I want the laptop to not look stupid. No bling-bling effects, no gaudy blue and gold two-tone color effects, no flashing multicolored lights, no fake (or real) wood, no trying to look like an expensive watch or a traffic accident, no sharp chiseled edges–none of that attention-getting crap! Just a basic boring matte silver or gray metal case. Ideally it will not be a fingerprint magnet.
Within reason, price is not a practical consideration as this is a business expense for me and I am comfortable spending big bucks on something that provides my livelihood which I expect to keep for several years.
So given these conditions, what do people recommend? Help me, KDE community, you’re my only hope!
This weekend the KDE Sysadmins completed the migration of KDE git modules to our Gitlab-based source code management stack as discussed for months now, and recently posted to kde-cvs-announce as a final reminder.
While we did some work in kdesrc-build to set the stage for support for the migration, there were a few changes still necessary to adapt to the new KDE project directory scheme.
kdesrc-build has made those changes this weekend and should be able to handle the Gitlab-based KDE git modules.
However you will likely need to manually update kdesrc-build and then kdesrc-build will be able to handle the rest.
The easiest way to do this is to navigate to the kdesrc-build source directory (where
you initially cloned it from git) and ensure that the kdesrc-build
If you use the default recommended paths from the Get Involved with Development page then you can make this happen by following these commands:
cd ~/kde/src/kdesrc-build git remote set-url --push origin email@example.com:sdk/kdesrc-build.git git remote set-url origin https://invent.kde.org/sdk/kdesrc-build.git git pull
git remote set-url --push command uses a : where the
set-url command uses a / to separate “invent.kde.org” from the
“sdk/…” part. If you decide to type this in instead of copy-pasting then be
careful of that.
From there, kdesrc-build will be configured to read from the new Gitlab-based
git modules. When it next runs, it will update any existing
kde: git config
prefixes to point to
invent.kde.org as appropriate, and also update the
git-remote settings for KDE modules automatically since some modules are now
found in different locations (e.g. kdesrc-build itself moved from
‘extragear/utils/kdesrc-build.git’ to ‘sdk/kdesrc-build.git’)
If for whatever reason kdesrc-build ends up staying wedged, the easiest way to resolve is probably just to delete the kdesrc-build install (NOTE do not delete any existing kdesrc-buildrc configuration files you may have) and clone it again using the instructions at the Get Involved with Development page.
I hope this helps you all to update your KDE git modules as seamlessly as possible. This should free you of the need to manually run git kclone or git kpull porting aids. As always if you run into bugs please let us know on IRC, on the mailing list or at bugs.kde.org!
We just released the first bugfix version for the 20.04 Kdenlive version. Despite our continued work, many issues were still affecting the 20.04.0 version. A lot of work has been done to fix crashes and other annoying issues, so the 20.04.1 version should be much more reliable and stable. We have a long list of fixed issues.
Windows: Motion Tracking effect integrated.
AppImage: Fix crash on older systems (remove OpenCV sse4 dependency)
Most notably, we have now fixed:
The KDE Plasma 5.19 beta has been released! We’re very proud of the work that’s gone into 5.19, but it is no doubt buggy and in need of QA. Please help us find all the bugs we missed! Go test it in your favorite distro; options include KDE Neon Testing or Unstable editions, openSUSE Krypton or KDE:Unstable repos, Arch’s kde-unstable repos, and probably many more I’m not familiar with (please tell me!).
But wait, there’s more…
Go test that Plasma 5.19 beta! Read the first paragraph of this post to see how.
More generally, 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!
During the last weeks, as for most of us, the communication happens over applications on the PC. For this matter, I use my headphones which cover the ears, have a decent sound quality and a microphone builtin to the cable. It is a pure analog device with a 4 pin jack connector which has the big advantage to also work on my cell phone.
While being in a somewhat boring and lengthy status meeting where I did not have to say anything but still needed to listen for some trigger words and discussions to jump in if needed, I was looking at some KMyMoney code reviews on the side and ran the build process in the background.
To get the most out of my machine, I have the following lines in my
.bashrc which make sure to use the all the available processors plus an extra one to also cover wait cycles for external hardware etc.
CPUCOUNT=nproc let CPUCOUNT=$CPUCOUNT+1 alias make='make -j$CPUCOUNT'
Doing so on my 6 core hyperthreaded Dell Laptop runs 13 threads of the compiler which eventually causes the fan to start spinning.
In the meeting people started complaining about a loud noise. It took me a while to figure out that they complained about me resp. my fan making the noise as the headphones shielded this noise pretty well. I simply muted my mic to get a quick solution. At the same time, I wondered why the microphone placed in the cable of the headphones is so good to pick up the fan’s noise.
A bit of research turned out that it was the builtin microphone of the laptop which was used all the time and not the one located in the cable. Checking what is going on, I found out that the audio output switches from speaker mode to headphone mode when you plugin the headphone jack but that it does not switch the mic at the same time. You can do that manually, but it switches back to builtin equipment as soon as you pull the headphone plug. That’s not elegant and I thought that there must be a solution to automate the process.
Searching for the term “howto automatically switch mic from builtin to headphone on linux” I got sound – How do I make Ubuntu select my headset mic as default … as the first hit. Well, I am using openSUSE Leap 15.1 but gave it a shot anyway. And guess what: it was exactly the solution I needed mainly because the person who answered the original question had a very similar, if not even the same hardware.
Now, I can join the meetings and run the compiler without getting complaints.
Kid3 is a handy but powerful music tagging program which lets you edit the ID3 tags and similar formats on MP3 and other music files.
This month is has moved to be hosted by KDE and has made its first release as a KDE app. The release note says:
“Besides bug fixes, this release provides usability improvements, additional keyboard shortcuts and user action scripts. Special thanks go to various people at KDE, who translated the user interface and the handbook to new languages.”
Kid3 is available in for Linux, Windows, Mac and Android. You can download from the website or through your distro and the stores Chocolatey, Homebrew and F-droid.
Calligra is feature complete and standards compliant office suite. It has been without a release for a couple of years but now is back with style.
Version 3.2 has Gemini, the office suite especially designed for 2 in 1 devices, that is, for laptops with touchscreens that can double up as tablets ported to our beautiful Kirigami framework. The drawing program Karbon now supports document containing multiple pages. While Stage, the Calligra presentation editor, now supports automatic slide transition,
Calligra is available through your Linux distro.
Tellico is a collection manager for keeping track of everything you collect likes books, bibliographies, videos, music, video games, coins, stamps, trading cards, comic books, and wines.
To make this easy is has a load of data engines to make it easy to show what you own. The new version 3.3 out earlier this month add a data source for Colnect a comprehensive collectibles catalog. It also updates a bunch of data sources such as Amazon and MobyGames.
New projects in KDE this month include pvfviewer, a PC Stitch Pattern Viewer so you can make beautiful tapestries. And Alligator, an RSS reading using our beautiful Kirigami framework.
Each month we like to profile one of the new package container format. AppImage isn’t new, it’s been around for over a decade but it’s worth reminding ourselves about as a number of KDE apps use it.
AppImage is a packaging format that provides a way for upstream developers to provide “native” binaries for GNU/Linux users just the same way they could do for other operating systems. It allow packaging applications for any common Linux based operating system, e.g., Ubuntu, Debian, openSUSE, RHEL, CentOS, Fedora etc. AppImages come with all dependencies that cannot be assumed to be part of each target system in a recent enough version and will run on most Linux distributions without further modifications.
To run an AppImage you need the Linux kernel (> 2.6) and
libfuse. Those dependency are present in the majority of the GNU/Linux distributions so you have no need to install anything special.
Sadly the AppImage support on the major desktop environments (KDE and Gnome) is not complete so you may require an additional tool to create a menu entry of your app. In such cases depending on the UX you preffer you can choose between: - AppImageLauncher for a first-run integration pop-up or - appimaged for a auntomated intagration of every AppImage deployed in your home dir.
To update your AppImages you use AppImageUpdate. This is embed in AppImageLauncher so if you already installed it, you have no need to install anithing aditional. Just right click over the AppImage file and choose update. Notice that not all packagers embed the update information into the binaries so there may be cases in which you will have to manually download the new version.
There are several KDE apps that are already being distributed as AppImage, the more relevant ones are: - kdenlive - krita - kdevelop
The recommended way of getting AppImages is from the original application authors, but this is not quite practical if you still don’t know which app do you need. There is when AppImageHub comes in. It’s a software store dedicated only to AppImages. There you can find a catalog with more than 600 apps for your daily tasks.
This web site is part of the OpenDesktop.org platform which provides a complete ecosystem for users and developers of free and open source applications.
Making an AppImage is all about bundling all your app dependencies into a single dir (AppDir). Then it’s bundled into a sqaushfs image and appended to a ‘runtime’ that allows it’s execution.
To acomplish this task you can use the following tools:
Some of our projects release on their own timescale and some get released en-masse. The 20.04.1 bundle of projects was released today and should be available through app stores and distros soon. See the 20.04.1 releases page for details.
Some of the fixes included in this release are:
Today, we are pleased to announce the release of MauiKit and Maui Apps 1.1.0!.
Are you a developer and want to start developing cross-platform and convergent apps, targeting, among other things, the upcoming Linux mobile devices? Then join us on Telegram: https://t.me/mauiproject. If you are interested in testing this project and helping out with translations or documentation, you are also more than welcome.
We are present on Twitter and Mastodon:
The 1.1.0 version brings updates, new features, bug fixes, and an improved cross-platform and convergent experience from the framework to the apps. For this first full release, the packages are distributed directly from the MauiKit official webpage.
Some apps might be missing features or present some bugs if it is the case that you want to report a bug or a feature request you can open a ticket at https://gitlab.com/nitrux/mauikit/maui-bug-tracker. Follow the instructions on how to file an issue.
Although this is not the first release for MauiKit, it is the first official stable release.
The Maui Apps will get a version bump whenever Mauikit gets a version bump to keep them as close as possible to the framework and help both projects grow together. The Maui Project is aiming for the ‘convergent’ environment.
This first release is a massive step towards such a goal. In the future, we want to see Maui Apps and MauiKit on various other devices.
As of now the Maui Project provides nine applications to cover the basic set of standard utilities: A file manager (Index), music player (VVave), an image viewer (Pix), text editor(Nota), Notes taker (Buho), terminal emulator(Station), contacts manager (Contacts), document viewer (Library) and a video player (Cinema). Some of the apps are in different states, most of them are stable, some of them are more feature-rich, and some others are in early stages.
For this release cycle, we provide packages for Index, VVave, Pix, Nota, Buho, Station, and Contacts.
For users, we provide packages for Linux x64 and ARM (aarch64, a.k.a arm64) devices like Plasma Mobile, APKs for Android, and Windows installers for x64.
And for distribution maintainers, we provide links to the applications and the framework source code.
During this cycle, we added support for macOS and iOS, although, for this 1.1.0 release, we don’t provide official packages for them, you can join us at our channels to keep an eye on testing packages.
Most of the apps gained keyboard shortcuts to make them usable on desktops.
Pix is the image viewer and gallery manager.
For this release, it has gained some excellent features, such as initial support for doodles and the option to switch from a grid view to a detailed view allowing to group by categories besides sorting.
Pix does not make use of a database system for storing the image collection; instead, it makes use on the file system to list the images from the Pictures and Download folders, that way Pix can more quickly detect them and refresh.
It gained a settings dialog and more configurable options.
Pix received fixes to the viewer, and the thumbnails rollbar now can be scrolled by using the wheel handler.
VVave is a music player.
The delegates were cleaned up and are now faster, it gained an improved focus view, and overall it makes further use of MauiKit templated ‘delegates’ and components.
It has initial support for streaming music from NextCloud servers.
Index is the file manager.
Supports independent embedded terminals per browser view on macOS and Linux; this means that you can use a terminal per split view and per tabs, allowing you to be more efficient when hacking.
It supports previews for text files, images, PDFs, music, and videos.
It has three different view modes: details, grid, and columns view.
Allows you to quickly tag and browse your files, the ‘tags’ are usable across all the Maui apps, so music tracks or images tagged on VVave or Pix, respectively, can be accessed from Index.
Also, the Columns view now has a proper scrollbar at the bottom for better scrolling between the multiple path columns.
The simple text editor now includes more configurable options, such as new focus mode, switching on and off the syntax highlighting, and editor background color options.
Features split views and embedded terminal per tab.
A focus mode to focus on the task of editing the text entirely.
A better list/details view beside the cards view.
Gained more stability coming to form MauiKit Editor improvements.
The editor for new notes is no longer a small popup dialog but instead takes full app size using a stack view.
Notes can be synchronized using a NextCloud server with the Notes app installed.
Station now correctly closes open tabs, and the split views work as expected.
It also now uses the MauiKit ToolActions.
Contacts app is the contacts manager and dialer for phones
The framework has gained new controls, and the previous ones have been cleaned up and improved. Same for the back end utilities like the file management classes and templated models. For more information, you should check the previous blog posts about the progress leading to the 1.1.0 release:
The style was reviewed for better supporting desktop devices on Windows and macOS and AppImages, besides the previous support for Android phones or touch-based devices.
Hope you all are safe and doing great. It’s been about 2 weeks since the GSoC results were announced and I got selected for the GCompris project. I have written a previous blog in which I have mentioned all about my projects and my contribution to the community.
In this blog, I am going to write what I have done so far.
As currently, the GSoC community bonding period is going on. I have interacted with my mentors about the design of the datasets which I am going to implement for the memory activities. As I am going to implement multiple datasets to about 11 activities so I have created a separate task on the phabricator for each of them. I have also finalized the description of the multiple datasets of few activities as Enumeration memory game Activity, Addition memory game activity, Subtraction memory game activity, and the Multiplication memory game activity. The main goal of all the memory game activities is to practice addition, subtraction, multiplication, etc. To make the Enumeration memory game more rich I also planned to add configurations to choose between different quantity representations as choose between dots, numbers, dices, etc.
I will be updating my progress regularly through blogs.