Skip to content

Welcome to Planet KDE

This is a feed aggregator that collects what the contributors to the KDE community are writing on their respective blogs, in different languages

Friday, 8 December 2023

The Qt 6.7 feature freeze is today, and we now start the process of further stabilizing the code. The actual release is still a few months off, but I thought I would look ahead at bit at what improvements are in store for font handling in Qt and Qt Quick. More specifically there are three things discussed: Variable font support, a brand new "large font" text renderer and font shaping feature support.

Let’s go for my web review for the week 2023-49.

Mobilizon V4: the maturity stage – Framablog

Tags: tech, framasoft, privacy, social-media, foss

Another important software release. Let’s wish luck to the new maintainers!

Introducing Wikifunctions: first Wikimedia project to launch in a decade creates new forms of knowledge – Wikimedia Foundation

Tags: tech, wikipedia, knowledge, programming

Interesting move, I’m wondering how far this will go. Reuse of those functions in other Wikimedia project will be critical to its success.

Toxic comments are associated with reduced activity of volunteer editors on Wikipedia | PNAS Nexus | Oxford Academic

Tags: tech, wikipedia, knowledge, community, sociology

Very interesting study, shows how toxic comments impact contributions. Gives a good idea of the probability for people to leave. In the case of Wikipedia this highlights reasons which contribute to the lack of diversity in the contributors. This is a complex community issue in general, this studies does a good thing by shedding some light on the dynamics in the case of Wikipedia.

An Open Letter to the Python Software Foundation

Tags: tech, python, community

The fact that they felt the need to write such a letter is troubling. What’s going on in the Python Software Foundation really? Something needs to be fixed it seems.

Firefox on the brink? |

Tags: tech, web, mozilla, google

Let’s hope it won’t get there… I wish people would abandon Chrome en masse. I unfortunately don’t see it happening and it’ll just weaken the Web.

Chrome’s next weapon in the War on Ad Blockers: Slower extension updates | Ars Technica

Tags: tech, google, browser, attention-economy

Still using Chrome? What are you waiting for to change for another browser which doesn’t play against your interests.

Automakers’ data privacy practices “are unacceptable,” says US senator | Ars Technica

Tags: tech, automotive, privacy

A senator is stepping up and rightfully pointing the finger at automakers. Let’s hope more will follow.

PlayStation keeps reminding us why digital ownership sucks - The Verge

Tags: tech, DRM, copyright

If you can’t download it without DRMs you just don’t own it, you’re renting it. This is completely different.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack

Tags: tech, security, bios

Fascinating vulnerability. When the BIOS is at fault with a crappy image parser… you can’t do much to prevent problems from happening.

AI and Mass Spying - Schneier on Security

Tags: tech, ai, gpt, surveillance, spy

Definitely one of the worrying aspects of reducing human labor needs for analyzing texts. Surveillance is on the brink of being increased thanks to it.

Google Researchers’ Attack Prompts ChatGPT to Reveal Its Training Data

Tags: tech, ai, machine-learning, gpt, copyright

A glimpse into how those generator models can present a real copyright problem… there should be more transparency on the training data sets.

Block the Bots that Feed “AI” Models by Scraping Your Website – Neil Clarke

Tags: tech, ai, machine-learning, gpt, copyright, criticism

This is clearly an uphill battle. And yes, this is because it’s broken by design, it should be opt-in and not opt-out.

Introducing Gemini: Google’s most capable AI model yet

Tags: tech, ai, machine-learning, gpt

The Large Language Model arm race is still going strong. Models are still mostly hidden behind APIs of course, and this is likely consuming lots of energy to run. Results seem interesting though, even though I suspect they’re over inflating the “safety” built in all this. Also be careful of the demo videos, they’ve been reported as heavily edited and misleading…

Multifaceted: the linguistic echo chambers of LLMs - by James Padolsey

Tags: tech, linguistics, ai, machine-learning, gpt

LLMs training had a bias from the start… and now we got a feedback loop since people are posting generated content online which is then used for training again. Expect idiosyncrasies to increase with time.

Seamless Communication - AI at Meta

Tags: tech, ai, machine-learning, gpt, translation, speech

Now this is a very interesting use of generator models. I find this more exciting than the glorified chatbots.

ChatGPT’s One-year Anniversary: Are Open-Source Large Language Models Catching up?

Tags: tech, ai, machine-learning, gpt, foss

Very interesting review, we can see some interesting strengths and weaknesses. Also gives a good idea of the different ways to evaluate such models.

reaction, in replacement of fail2ban

Tags: tech, security, server, self-hosting

Could indeed turn into a nice alternative to fail2ban.

Standard Webhooks

Tags: tech, web, services, webhooks

Interesting attempt at having webhooks implementation a bit more standardized. This is indeed needed, currently everyone does them in slightly different ways and sometimes the quality is debatable. If it gets adopted it’d give a good baseline.

You (probably) don’t need DateTime · Scorpil

Tags: tech, date, time, unix, complexity

Good reminder that the raw UNIX timestamps have interesting properties and often are enough not necessarily needing to rely on something more complex. Also gives nice criteria for picking between said timestamps and higher level types.

You don’t need JavaScript for that - HTMHell

Tags: tech, web, html, css, frontend

Nice examples showing JavaScript use can be reduced in the browser. HTML and CSS are gaining nice features.

Documentation unit tests

Tags: tech, tests, documentation

Interesting approach to reduce the amount of undocumented features because we simply forgot to update the documentation. Shows a few inspiring tricks to get there.

Struct initialization | Sandor Dargo’s Blog

Tags: tech, c++

Good walkthrough the finer points of members initialization in C++. Worth keeping in mind.

When static types make your code shorter

Tags: tech, programming, type-systems

Somehow unsurprising, this is often the case: less validation code, but also less automated tests. With types you can write unwanted states out of existence.

Profiling Rust programs the easy way | nicole@web

Tags: tech, rust, optimization, profiling

The Rust tooling makes it super easy to profile your programs. This is neat.

Topics in computer graphics

Tags: tech, graphics, 3d, learning

Very nice collection of tidbits of information for the main topics in computer graphics. A good way to get started or refresh the basics.

Nuclear Reactor Simulator

Tags: tech, web, game, 3d, simulation

Very cool simplified simulator. Gives a good idea of how this roughly works.

“Smartifying” my Hi-Fi system

Tags: tech, hacking, raspberry-pi, music, networking, usb

Alright, this is definitely a cool hack.

Deciphering Glyph :: Safer, Not Later

Tags: tech, quality, project-management, programming

An interesting interpretation of what was behind the “move fast and break things” motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.

TDD Isn’t Design - by Kent Beck

Tags: tech, tdd, design

Definitely this. Again TDD helps to work on the design, but it’s not a silver bullet which will give you the right design on a platter.

A few words about Blameless culture

Tags: tech, culture, blameless, quality, trust

Shows why it’s important to go for a blameless culture, also outside of postmortem. This is definitely not easy but worth it.

How to do annual planning and strategy for an engineering organization — Lena Reinhard

Tags: tech, organization, strategy, planning

Good blueprint for building up and following up (the most important part really) of a strategy in your organization.

Return to office is dead, Stanford economist says. Here’s why

Tags: tech, remote-working

Looks like remote work is here to stay for good now.

RFC processes are a poor fit for most organizations - Jacob Kaplan-Moss

Tags: business, organization, decision-making

Good point on why you don’t want to drive your organization simply on RFCs. Yet another fad of “this worked for them, let’s do it as well”… per usual this fails to take into account the specificity of the context where it worked.

First decide how to decide: “one weird trick” for easier decisions - Jacob Kaplan-Moss

Tags: tech, management, decision-making

Nice ideas for decision making in larger groups.

Bye for now!

Thursday, 7 December 2023

We bring you another 5.2 series bug fix release with Krita 5.2.2! Check out release notes for everything that was new in Krita 5.2.0.

Some of the highlights in this bug fix release is that we managed to track down a frequent crash on android, as well as fixing a bug where brush presets with masked brushes were not loaded correctly.

  • Make sure that the image is properly updated on frame switch on merge (Bug 476495)
  • Various fixes to the snap version, courtesy of Scarlett Moore
  • Fix a race condition when merging non-animatied layer over an animated one (Bug 476472)
  • Don’t enable combined opacity-flow option on masked brushes (Bug 476506)
  • Disable checkability of Opacity and Flow options for Masked Brushes (Bug 476505 , Bug 476076)
  • Fix redo of a flatten layer operation when it is animated (Bug 476511)
  • Hide perspective ellipse if assistants are globally hidden, courtesey of Maciej Jesionowski.
  • Fix Specific Color Selector changing to black (Bug 476614)
  • Add brush tip rotate actions and and a angle slider.
  • Extract the cache in KisMyPaintOpSettings to properly handle size updates (Bug 476141)
  • Remove wrong assert (Bug 476761)
  • Fix cancelling of the selection when doing two consequtive selections (Bug 474525)
  • Fixes for Qt: MDI titles and unbalanced non-us shortcuts (Bug 464175)
  • Draw assistants directly on the canvas (Bug 361709Bug 401940)
  • Various palette docker fixes courtesy of Mike Will
  • Better integration with windows darkmode, setting the window frame to dark when this is enabled (Bug 477266)
  • Use PreciseTimer type with KisPlaybackEngineQT (Bug 476059)
  • Various fixes to shortcuts, among others, to get altgr to work as a shortcut (Bug 459557Bug 474912Bug 469691Bug 473923)
  • Fix jumps just adjusting brush size with ‘[’ and ‘]’ shortcuts (Bug 456787)
  • Replace fcitx-qt5 with fcitx5-qt, which should help the look and feel of fcitx-based input methods.
  • Increase xmlgui version to be bigger that 5.1.6, which should solve old toolbars being reset (Bug 475698)
  • Fixes a very frequent crash caused by QAccesibility on Android (Bug 472705)



If you’re using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

Note that we are not making 32 bits Windows builds anymore.


The separate gmic-qt AppImage is no longer needed.

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)


Note: if you use macOS Sierra or High Sierra, please check this video to learn how to enable starting developer-signed binaries, instead of just Apple Store binaries.


We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.

Source code


For all downloads, visit and click on Details to get the hashes.


The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. The signatures are here (filenames ending in .sig).

Please support Krita by making a donation or joining the development fund!

Join the Krita Development Fund

The post Krita 5.2.2 Released! appeared first on Krita.

For the fourth installment of Off-Theme we have a global theme based on the granddaddy of all the classic Unix desktops, a desktop that ruled the roost of the workstations from a bygone era. It is time to pay tribute to the DE that once dominated the Unix world.

For quite some time, I have been bothered by this thought: Individual programming languages (C++, Rust, Go, etc.) are traditionally viewed as walled gardens. If your main() function is written in C++, you had better find yourself C++ libraries like Qt to build the rest of your codebase with. Do you want to use Flutter to build your app’s user interface? Get ready to build the logic in Flutter, too. Do you really want to use that Rust library to make your application safer? You get to either rewrite the whole app in Rust or build an ugly extern "C" wrapper around it that won’t fit well in your object-oriented C++ code.

This has been the standard view on using multiple programming languages for many years. However, I’ve decided that this view is fundamentally flawed, because every compiled language uses the same set of concepts when it is compiled:

    1. Code is split up into functions that can be reused.
    2. Functions are identified by a string generated from the function name in the source code. For example, g++ generates _Z3foov as the identifier for void foo(). This string is always reproducible; for example, both Clang and GCC on Linux follow the Itanium C++ ABI convention for mangling function names.
    3. Functions are called by storing all parameters to that function at a specific location in memory and then using a call instruction or equivalent to move control to the function. For example, to call void foo() from earlier, the compiler converts a C++ statement foo(); into the assembly call _Z3foov. The assembler then replaces call with the appropriate opcode and replaces _Z3foov with the location of the first instruction identified by _Z3foov.
    4. Functions return by storing their return value (if they have one) at a specific location and then using a ret instruction or equivalent.
    5. Classes and structs can be boiled down to a collection of primitive types (although some classes do have vtables).
    6. Class methods are just another function that happens to take a pointer to the class object as the first parameter. In other words, when you write this:
      class Foo
          void foo(int bar);
          int baz;

      your code actually compiles to something that is better represented this way:

      class Foo
          int baz;
      void foo(Foo *this, int bar);

    Since every compiled programming language uses the same concepts to compile, why can’t they just interact?


    Before we go any further, I’d like to give an example of what we want to achieve:

    // file: main.cpp
    #include "rustmodule.h"
    // or in an ideal C++ 20 world:
    // import rustmodule;
    int main()
        return 0;
    // file: rustmodule.h
    #pragma once
    // this is defined in Rust
    void foo();
    // file:
    pub fn foo() {
        println!("Hello from Rust");

    We want to be able to compile those files and get an executable file that prints Hello from Rust to stdout.

    Now let’s look at why this won’t just work out of the box.

    Name mangling, data layout, and standard libraries

    The most obvious reason that compiled programming languages can’t just interact with each other is the most obvious one: syntax. C++ compilers don’t understand Rust, and Rust compilers don’t understand C++. Thus neither language can tell what functions or classes the other is making available.

    Now, you might be saying “But if I use a C++ .h file to export functions and classes to other .cpp files, certainly I could make a .h file that tells C++ that there is a Rust function fn foo() out there!” If you did say (or at least think) that, congratulations! You are on the right track, but there are some other less obvious things we need to talk about.

    The first major blocker to interoperability is name mangling. You can certainly make a .h file with a forward declaration of void foo();, but the C++ compiler will then look for a symbol called _Z3foov, while the Rust compiler will have mangled fn foo() into _ZN10rustmodule3foo17hdf3dc6f68b54be51E. Compiling the C++ code starts out OK, but once the linking stage is reached, the linker will not be able to find _Z3foov since it doesn’t exist.

    Obviously, we need to change how the name mangling behaves on one side or the other. We’ll come back to this thought in a moment.

    The second major blocker is data layout. Put simply, different compilers may treat the same struct declaration differently by putting its fields at different locations in memory.

    The third and final blocker I want to look at here is standard libraries. If you have a C++ function that returns an std::string, Rust won’t be able to understand that. Instead, you need to implement some sort of converter that will convert C++ strings to Rust strings. Similarly, a Rust Vec object won’t be usable from C++ unless you convert it to something C++ understands.

    Let’s investigate how we can fix the first problem, name mangling.

    extern "C" and why it sucks

    The easy way is to use the extern "C" feature that nearly every programming language has:

    // file: main.cpp
    #include "rustmodule.h"
    // or in an ideal C++ 20 world:
    // import rustmodule;
    int main()
        return 0;
    // file: rustmodule.h
    #pragma once
    extern "C" void foo();
    // file:
    pub extern "C" fn foo() {
        println!("Hello from Rust");

    This actually will compile and run (assuming you link all the proper standard libraries)! So why does extern "C" suck? Well, by using extern "C" you give up features like these:

    • Function overloads
    • Class methods
    • Templates

    It’s possible to create wrappers around the extern "C" functions to crudely emulate these features, but I don’t want complex wrappers that provide crude emulation. I want wrappers that directly plumb those features and are human readable! Furthermore, I don’t want to have to change the existing source, which means that the ugly #[no_mangle] pub extern "C" must go!

    Enter D

    D is a programming language that has been around since 2001. Although it is not source compatible with C++, it is similar to C++. I personally like D for its intuitive syntax and great features, but for gluing Rust and C++ together, D stands out for two reasons: extern(C++) and pragma(mangle, "foo").

    With extern(C++), you can tell D to use C++ name mangling for any symbol. Therefore, the following code will compile:

    // file: foo.cpp
    #include <iostream>
    void bar();
    void foo()
        std::cout << "Hello from C++\n";
    // file: main.d
    import std.stdio;
    extern(C++) void foo();
    extern(C++) void bar()
        writeln("Hello from D");
    void main()

    However, it gets better: we can use pragma(mangle, "foo") to manually override name mangling to anything we want! Therefore, the following code compiles:

    // file: main.d
    import std.stdio;
    pragma(mangle, "_ZN10rustmodule3foo17h18576425cfc60609E") void foo();
    pragma(mangle, "bar_d_function") void bar()
        writeln("Hello from D");
    void main()
    // file:
    pub fn foo() {
        println!("Hello from Rust");
        unsafe {
    extern {
        #[link_name = "bar_d_function"] fn bar();

    With pragma(mangle, "foo") we can not only tell D how Rust mangled its function, but also create a function that Rust can see!

    You might be wondering why we had to tell Rust to override mangling of bar(). It’s because Rust apparently won’t apply any name mangling to bar() for the sole reason that it is in an extern block; in my testing, not even marking it as extern "Rust" made any difference. Go figure.

    You also might be wondering why we can’t use Rust’s name mangling overrides instead of D’s. Well, Rust only lets you override mangling on function forward declarations marked as extern, so you can’t make a function defined in Rust masquerade as a C++ function.

    Using D as the glue

    We can now use D to glue our basic example together:

    // file: main.cpp
    #include "rustmodule.h"
    // or in an ideal C++ 20 world:
    // import rustmodule;
    int main()
        return 0;
    // file: rustmodule.h
    #pragma once
    // this is in Rust
    void foo();
    // file:
    pub fn foo() {
        println!("Hello from Rust");
    // file: glue.d
    // This is the Rust function.
    pragma(mangle, "_ZN10rustmodule3foo17h18576425cfc60609E") void foo_from_rust();
    // This is exposed to C++ and serves as nothing more than an alias.
    extern(C++) void foo()

    In this example, when main() calls foo() from C++, it is actually calling a D function that can then call the Rust function. It’s a little ugly, but it’s possibly the best solution available that leaves both the C++ and Rust code in pristine condition.

    Automating the glue

    Nobody wants to have to write a massive D file to glue together the C++ and Rust components, though. In fact, nobody even wants to write the C++ header files by hand. For that reason, I created a proof-of-concept tool called polyglot that can scan C++ code and generate wrappers for use from Rust and D. My eventual goal is to also wrap other languages, but as this is a personal project, I am not developing polyglot very quickly and it certainly is nowhere near the point of being ready for production use in serious projects. With that being said, it’s really amazing to compile and run the examples and know that you are looking at multiple languages working together.

    Next up

    I originally planned to write on this topic in one blog post, but there are a lot of interesting things to cover, so I will stop here for now. In the next installment of this series we will take a look at how we can overcome the other two major blockers to language interoperability.

About KDAB

If you like this article and want to read similar material, 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 Mixing C++ and Rust for Fun and Profit: Part 1 appeared first on KDAB.

Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

  • dolphin-plugins: Mountisoaction: add preferred raw disk mimetypes (Commit, fixes bug #475659)
  • falkon: Fix StartPage search engine default configuration (Commit, fixes bug #419530)
  • kdepim-runtime: Correctly reload configuration (Commit, fixes bug #473897)

Distro and app store packagers should update their application packages.

Wednesday, 6 December 2023

Broken Rules, the Vienna-based game development studio known for their award-winning games Old Man’s Journey and Gibbon: Beyond the Trees, became a Krita sponsor earlier this year.

Known for their thoughful and candid approach to game making it comes as no surprise that their Co-Founder and Creative Director Clemens Scott has a strong stance on software projects:

“In a world full of subscription services, forced updates, feature bloat and vendor lock-ins, it’s refreshing to see that alternatives are cropping up. Projects such as Blender have proven that free, open-source software can reach industry-grade levels of quality and provide a viable alternative to the status quo. I’ve been using Krita on a regular basis for the past two years and I would love to see it become as ubiquituous as its corporate competitors.”

Painting of a small narrow house perched precariously on a cliff. Next to it a very nautical-looking banner is floating above the sea, with an anchor, rope, a landscape with a lighthouse and the words "Old Man's Journey".

Old Man’s Journey was the Apple Design Award Winner 2017 and iPad Game of the Year 2017.

Very bright painting of a gibbon moving from a lush green forest on the left to a fiery red area on the right. Text above the gibbon: "Gibbon: Beyond the Tree".

Gibbon: Beyond the tree won the Apple Design Award in 2022 in the category Social Impact.

An alien-looking landscape with alien-looking figures. One is playing a drum with two thin sticks, the other is leaning against a green hill.

Eloh won the Apple Design Award in 2019.

Clemens used Krita mainly for personal projects, such as various illustrations throughout his memex, but also for sketching out ideas on level designs for Gibbon: Beyond the Trees, which you can find on his personal page as well.

We appreciate their support and contribution to keeping Krita going strong!

About the Studio

Broken Rules Logo
Broken Rules was founded in 2009 and has a track record of creative left-field works. Their games focus on originality, simplicity, refined game mechanics and rich interactivity.

Broken Rules founding members regard video games as important cultural achievements and seek to make every game a new and meaningful experience that lingers in the players’ minds long after they powered down their computers.


The post Broken Rules Sponsors Krita! appeared first on Krita.

Tuesday, 5 December 2023

QCoro 0.10.0 Release Announcement

Thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

Support for awaiting Qt signals with QPrivateSignal

Qt has a feature where signals can be made “private” (in the sense that only class that defines the signal can emit it) by appending QPrivateSignal argument to the signal method:

class MyObject : public QObject {
    void error(int code, const QString &message, QPrivateSignal);

QPrivateSignal is a type that is defined inside the Q_OBJECT macro, so it’s private and as such only MyObject class can emit the signal, since only MyObject can instantiate QPrivateSignal:

void MyObject::handleError(int code, const QString &message)
    Q_EMIT error(code, message, QPrivateSignal{});

QCoro has a feature that makes it possible to co_await a signal emission and returns the signals arguments as a tuple:

MyObject myObject;
const auto [code,  message] = co_await qCoro(&myObject, &MyObject::handleError);

While it was possible to co_await a “private” signal previously, it would get return the QPrivateSignal value as an additional value in the result tuple and on some occasions would not compile at all.

In QCoro 0.10, we can detect the QPrivateSignal argument and drop it inside QCoro so that it does not cause trouble and does not clutter the result type.

Achieving this wasn’t simple, as it’s not really possible to detect the type (because it’s private), e.g. code like this would fail to compile, because we are not allowed to refer to Obj::QPrivateSignal, since that type is private to Obj.

template<typename T, typename Obj>
constexpr bool is_qprivatesignal = std::same_as_v<T, typename Obj::QPrivateSignal>;

After many different attempts we ended up abusing __PRETTY_FUNCTION__ (and __FUNCSIG__ on MSVC) and checking whether the function’s name contains QPrivateSignal string in the expected location. It’s a whacky hack, but hey - if it works, it’s not stupid :). And thanks to improvements in compile-time evaluation in C++20, the check is evaluated completely at compile-time, so there’s no runtime overhead of obtaining current source location and doing string comparisons.

Source Code Reorganization (again!)

Big part of QCoro are template classes, so there’s a lot of code in headers. In my opinion, some of the files (especially qcorotask.h) were getting hard to read and navigate and it made it harder to just see the API of the class (like you get with non-template classes), which is what users of a library are usually most interested in.

Therefore I decided to move definitions into separated files, so that they don’t clutter the main include files.

This change is completely source- and binary-compatible, so QCoro users don’t have to make any changes to their code. The only difference is that the main QCoro headers are much prettier to look at now.


  • QCoro::waitFor() now re-throws exceptions (#172, Daniel Vrátil)
  • Replaced deprecated QWebSocket::error with QWbSocket::errorOccured in QCoroWebSockets module (#174, Marius P)
  • Fix QCoro::connect() not working with lambdas (#179, Johan Brüchert)
  • Fix library name postfix for qmake compatibilty (#192, Shantanu Tushar)
  • Fix std::coroutine_traits isn't a class template error with LLVM 16 (#196, Rafael Sadowski)

Full changelog

See changelog on Github

Tuesday, 5 December 2023. Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.27.10.

Plasma 5.27 was released in February 2023 with many feature refinements and new modules to complete the desktop experience.

The bugfixes are typically small but important and include:

  • Powerdevil Backlighthelper: Implement support for the FreeBSD backlight(8) interface. Commit.
  • KWin: Allow running kwin5 windowed in kwin6. Commit.
  • Discover: Support AppStream 1.0 and 0.x versions. Commit.
View full changelog

Sunday, 3 December 2023

KStars v3.6.8 is released on 2023.12.03 for Windows, MacOS & Linux. It's a bi-monthly bug-fix release with a couple of exciting features.

Aberration Inspector

John Evans introduces the very exciting Aberration Inspector tool. The Aberration Inspector is a tool that makes use of Autofocus to analyze backfocus and sensor tilt in the connected optical train. It solves up to 9 virtual tiles on the sensor as defined by the existing Mosaic Mask.

The information is then used to analyze:
  • Back focus.
  • Sensor Tilt.
There are 4 sections:
  • V-curve for the each tile.
  • Table of data detailing the curve fitting results.
  • Analysis of back focus and tilt.
  • 3D Surface graphic to explain the Petzval Surface intersection with the sensor.
This release provides display only functionality. In future it would be possible to add functionality to offer recommendations for adjustments using Octopi, PhotonCage, etc.

Sub-exposure Calculator

Joseph McGee continues to add improvements and fixes for the Sub-exposure calculator. For usability, the window is now re-sizeable, an issue with the display of tool tips was corrected, and an indicator has been added for the sensor type of the selected camera (Mono / Color).  For functionality: the upper limit of the Noise Increase input parameter was increased, support was added for cameras with non-variable read noise, (cameras with CCD sensors).

Several new camera data files were added to the KStars source code repository, and a function to allow direct direct download of camera files from the repository was enabled. (Note: users who have created their own camera data files, may wish set the file attribute to read-only, and/or make a back up copy in case of an accidental over-write from the download function if the camera file has the same name).

A new experimental graphical tool to determine an appropriate number of sub-exposures for integration was added. This tool allows the selection of an exposure time to noise ratio for a stacked image; the tool will compute the number of sub-exposures required to achieve that value.

Added several new camera data files:
  • Atik-16200CCD_Mono.xml
  • FLI-16200CCD_Mono.xml 
  • QHY_CCD_294M_Pro.xml
  • QHY_CCD_461_PH.xml
  • QHY_CCD_163C.xml 
  • QHY_CCD_163M.xml
  • QHY_CCD_268C.xml
  • QHY_CCD_294M.xml
  • QHY_CCD_600_PH.xml
  • Pro.xml ZWO_CCD_ASI294MM
  • Pro.xml ZWO_CCD_ASI533MC
  • Pro.xml ZWO_CCD_ASI2600MC
  • Pro.xml ZWO_CCD_ASI6200MC
  • Pro.xml ZWO_CCD_ASI533MC
  • Pro.xml ZWO_CCD_ASI533MM
  • Pro.xml Nikon_DSLR_DSC_D5100_(PTP_mode).xml Nikon_DSLR_DSC_D700_(PTP_mode).xml

FITSViewer Solver

Hy Murveit added a very useful feature to the FITS Viewer: a built-in solver!

The FITS Viewer Solver is used to plate-solve the image loaded in the FITS Viewer's tab. It only works with the internal StellarSolver. You get the RA and DEC coordinates for the center of the image, the image's scale, the angle of rotation, and the number of stars detected in the image. Its main use case is debugging plate-solving issues in Ekos, though the information displayed can be generally useful. The controls and displays are described below.

This adds a new tool inside the splitter on the FITS Viewer. It plate-solves the displayed image, and allows the user to experiment with a number of plate-solving parameters, and thus help debug plate-solving issues.

How to test it out?
  • Open the sliding panel on the left part way, click on Plate Solving, and resize the windows appropriately.
  • Experiment with the parameters available (Use Scale, Use Position, the scale and RA/DEC positions, choose a profile and/or edit it)
  • Click Solve, and the image is solved and the solution presented in the Scale and RA & DEC and Angle boxes.
  • If you enable "Mark Stars" above the image window, you will also see the stars that were detected.

Quality of Life improvements

  • Make "Set Coordinates Manually" dialog more intuitive.
  • Telescope name specified in the optical trains are now saved in the  FITS header (the mount name was saved before).
  • New placeholders for ISO, binning and pure exposure time added.
  • Add a new not-default scheduler option to disable greedy scheduling.
  • Reduce latency between captures, especially when guiding / dithering.
  • Fix issue with differential slewing.
  • Separate Business Logic from UI in Scheduler.
  • Fix bug in estimating job time, capture delays were misinterpreted.
  • Fixed guide start deviation was not saved properly in esq file.
  • Bugfix in one-pulse dither. Dither pulses were going the wrong way.
  • Fix Scheduler hangs when Focus does not signal Autofocus start failure.
  • Focus Guide Settle Bug.