Skip to content

Tuesday, 28 March 2023

I’m happy to announce KTechLab release version 0.51.0. KTechLab is an IDE for microcontrollers and electronics. This new release contains the following changes:

  • updated and improved translations
  • the Serial Port component, for better compatibility, uses Qt’s QSerialPort, instead of operating-system specific library calls
  • experimental support for Windows; it requires MSVC 2019 compiler
  • various stability fixes
  • modernisation of the codebase, porting away from some deprecated APIs

The release tarball of version 0.51.0 can be downloaded from KDE servers. Its checksums are:

SHA256Sum: 046b9ce1f2c2a93e1da734a416674a5bb5da3203ac773d49ed693b8492f6d212
SHA1Sum: 7729b67050caee5b65fe4dd1dfbfce213cea44ac
MD5Sum: 2853c6867535995c1ead598e98fce6e3

KTechLab has a mailing list at KDE called ktechlab-devel: https://mail.kde.org/mailman/listinfo/ktechlab-devel

On IRC, developers are mostly reachable on freenode.net, on #ktechlab channel.

The source code of KTechLab is available in KDE Git, at https://invent.kde.org/sdk/ktechlab

Instructions for building and running KTechLab are available in the README file from the source code; online version of that file is available at https://invent.kde.org/sdk/ktechlab/-/blob/master/README ; The very short instructions are: run sh build-simple.sh and then sh run-simple.sh.

The notes from joining KDE: https://community.kde.org/Incubator/Projects/KTechLab

KTechLab bugs at KDE bugtracker: https://bugs.kde.org/buglist.cgi?quicksearch=ktechlab

We're happy to announce the new release 5.10.0 of KPhotoAlbum, the KDE photo management program!

The ChangeLog for this version is as follows:


Changed

  • View-related actions formerly found in the "Settings" menu were moved to the "View" menu.
  • Make options "Display Labels in Thumbnail View" and "Display Categories in Thumbnail View" reachable via the "View" menu and allow both actions to be assigned keyboard shortcuts (Implements: #145346).
  • Store the untagged tag information inside the index.xml file instead of the Settings (Implements: #461206).
  • Change scroll direction in the annotation dialog's date edit fields to match common (western) expectations and the date picker.
  • Prevent scrolling past the occupied areas of the date bar.
  • Files are now always created with group read/write permissions (Fixes: #438128).
  • When exiting the demo mode, the demo database is now always saved if it isn't deleted.

Dependencies

  • CMake: 3.18
  • Qt5: 5.15
  • KDE Frameworks: 5.78

Fixed

  • Improve readability of "Show Tooltips in Thumbnails Window" tooltip.
  • Fix image selection order for newly added images (Fixes: 442325).
  • Improve date bar behavior when zooming the date bar and changing views (Fixes: 357237).

Removed

  • Default shortcut for "View" images was removed.
    Pressing "Enter" to open the viewer is now the preferred way. To restore the old behavior, reassign the shortcut via "Settings | Configure Keyboard Shortcuts...".

Thanks to everybody having contributed to this release! The authors were (according to git log and in alphabetical order):

  • Christophe Giboudeaux
  • Tobias Leupold
  • Luigi Toscano
  • Johannes Zarl-Zierl

Have a lot of fun with the new version!

— Tobias

Sunday, 26 March 2023

As you probably have heard by now the lastest development versions of Plasma and KDE Frameworks require Qt6. This transition has been in the works for a few years by now, but it was only somewhat recently that we took the plunge and started relying on Qt6 exclusively for Plasma. Plasma 5.27 is the last Plasma 5 release and continues in bugfix-only mode.

For people who want to hack on Plasma features this raises the obvious question: How do I build Plasma 6 to hack on it?

Before diving into this, a word of warning: Current Plasma master is in no way “ready for production”. There are known-broken things and things may temporarily regress at any time. That said, the only way to get towards a stable thing is to dig in and fix things. So let’s see how to do that.

For this explanation I’m assuming you have build KDE software with kdesrc-build before. If not we have some extensive documentation for that. First you need at least Qt 6.4 installed. The usually best way to get that is from your distribution. If your distribution does not have Qt6 packaged yet please complain^Wtalk to them. CMake should complain about any missing Qt6 modules/development files, but make sure you have the qtpaths tool installed beforehand. It should be named something like qtpaths6 or qtpaths-qt6.

Now we need to teach kdesrc-build to build Plasma with the right configuration (git branches, CMake arguments etc) for building with Qt6. The easiest way to do that is by using a separate kdesrc-buildrc file. kdesrc-build comes with a sample Qt6 configuration file that you should use as a starting point. Replace the line include ~/kde6/usr/share/kdesrc-build/kf6-qt6-build-include with a path to your existing kdesrc-build installation. For me that would be include ~/kde/src/kdesrc-build/kf6-qt6-build-include. You can also apply other customizations that you usually do in your kdesrc-buildrc. Then save the file as e.g. ~/kde6/kdesrc-buildrc. This configuration will download, build, and install everything under ~/kde6. Currently it is very important to keep Qt5-based and Qt6-based builds separate since there will be conflicts between the installed files.

Now you can invoke kdesrc-build as usual, with one slight difference. Passing --rc-file=/home/user/kde6/kdesrc-buildrc will make it use the Qt6 configuration. If you omit the --rc-file argument it will use the old, Qt5-based configuration, so you can keep building Qt5- and Qt6-based stuff in parallel (but installed into different locations). Since kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc is a bit of a mouthful you might want to configure a shell alias like kdesrc-build6 for it.

Now you can do kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc workspace to build Plasma. Note that it’s expected that not all modules successfully build since not all of them are adjusted to Qt6 fully yet.

Once Plasma is build you want to log into the new session. To do that go to ~/kde6/build/plasma-workspace and run sudo ./login-sessions/install-sessions.sh once. Then you can select the new session at login in SDDM.

Now for some question that might be on your mind:

Q: Is it stable?

A: No, see above.

Q: When will it be stable?

A: Time will tell. It will be several more months before we can consider a Plasma 6 release.

Q: I tested it and found a problem, what should I do?

A: Report it to bugs.kde.org, and state that you are using Plasma master. Or try fixing it yourself.

Q: I want to work on a Plasma feature, what should I do?

A: Try developing it against Plasma master. If you find yourself blocked by anything please tell us.

Q: Does this apply to other KDE software as well?

A: Yes. Note that most applications allow building against Qt5 and Qt6 from the same branch though. And some apps aren’t ported to Qt6 at all.

Q: I did not understand a word of what you just said but I’d still like to help.

A: One way to help is by donating to KDE. Your donations help me have time to do things like working on Qt6 support or writing this blog post

After the recent release of KBibTeX 0.9.3.2 as the last release of the 0.9.x branch, it is now time to make a stable release of KBibTeX 0.10.0. Tar-balls are as usual available at KDE’s download mirrors. Some of the changes were documented more than two years ago in a pre-release (0.9.90), but here are the highlights taken from the ChangeLog:

  • New online search: Semantic Scholar
  • Migrating Inspire Hep to REST API
  • Fixing and revamping ACM's Digital Library (a.k.a. ACM Portal) online search
  • Refactoring NSA ADS to use official API
  • Updating BibSearch code: cover page improved, preparing code for translations, adding progress bar
  • Tabs in the entry editor can show short messages to use, e.g. in which tab DOIs or URLs are to be entered
  • Fixing UI issues with ColorLabelWidget
  • Using KRatingPainter instead of home-made StarRating's paint function
  • Various improvements and refactoring when (PDF) files get associated with an entry
  • Use Qt's own QOAuth1 class instead of external library QOAuth
  • Having ICU as an optional dependency only, provide internal, static translation from Basic Multilingual Plane (BMP) characters to ASCII-only representations
  • Greatly refactoring and modernizing CMakeLists.txt files, generation of camel-case headers, private/public linking to libraries, ...
  • Updating translations (contributions by various authors)
  • KDE Bug 421612: When suggesting entry ids, do not count ‘small words’
  • KDE Bug 424033: Can't associate a file with a relative path without having the file copied
  • KDE Bug 423976: When formatting IDs, non-word characters should be used as word separators
  • KDE Bug 426856: File encoding is not always stored
  • KDE Bug 379443: Slowdown when loading citation with many authors
  • KDE Bug 433005: Cannot unselect entry list view columns in BibLaTeX mode
  • KDE Bug 433084, KDE Bug 453455: Fixing crash when opening .bib file
  • KDE Invent issue 1: Properly handling letter modifiers such as \c{e} instead of \ce
  • Adding and extending numerous automated tests
  • Numerous other fixes, clean-ups, refactoring, ...

Thank you to everyone who contributed. Happy compiling and packaging!

Tuesday, 21 March 2023

Working on the Nextcloud desktop client, I stumbled into a nasty little bug. If you tried to add or remove a user account, the app would often freeze for a while.

This was super annoying during testing, so I decided to look into it. Surprisingly this wasn’t a new bug I’d unwittingly introduced; tracing the source of the freeze led all the way down into QtKeychain, which is what the desktop client uses to store user credentials.

QtKeychain, like Qt itself, is great at making life easy for developers targeting multiple platforms as it abstracts away the different keychain/keyring/wallet implementations for the different platforms. Looking at the Objective-C++ code handling Apple platforms, QtKeychain’s different job classes called code using Keychain Services functions, as expected.

Fortunately the problem was pretty clear. All of the calls to the Keychain Services functions — SecItemUpdate, SecItemDelete, SecItemAdd, SecItemCopyMatching — block the calling thread. From Apple’s documentation:

SecItemUpdate blocks the calling thread, so it can cause your app’s UI to hang if called from the main thread. Instead, call SecItemUpdate from a background dispatch queue or async function.

This means that, when called on the main thread, doing any QtKeychain operations would lead to freezing the UI. Since this is not a problem on other platforms (that I know of!), it’s pretty easy to overlook this quirk of Keychain Services’ API. 

void DeletePasswordJobPrivate::scheduledStart()
{
    const NSDictionary *const query = @{
            (__bridge id) kSecClass: (__bridge id) kSecClassGenericPassword,
            (__bridge id) kSecAttrService: (__bridge NSString *) service.toCFString(),
            (__bridge id) kSecAttrAccount: (__bridge NSString *) key.toCFString(),
    };

    const OSStatus status = SecItemDelete((__bridge CFDictionaryRef) query);

    if (status == errSecSuccess) {
        q->;emitFinished();
    } else {
        const ErrorDescription error = ErrorDescription::fromStatus(status);
        q->;emitFinishedWithError(error.code, Job::tr("Could not remove private key from keystore: %1").arg(error.message));
    }
}

With use of Grand Central Dispatch, a fix was relatively straightforward. All that needed to be done was to call the offending functions from a different dispatch queue. I rewrote the Apple-specific keychain implementation in order to call the Keychain Services functions asynchronously from the global queue, passing an interface object that would call the relevant completion methods and signals on the read/write/delete QtKeychain jobs.

static void StartDeletePassword(const QString &service, const QString &key, AppleKeychainInterface * const interface)
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
        NSDictionary * const query = @{
            (__bridge NSString *)kSecClass: (__bridge NSString *)kSecClassGenericPassword,
            (__bridge NSString *)kSecAttrService: service.toNSString(),
            (__bridge NSString *)kSecAttrAccount: key.toNSString(),
        };

        const OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);

        if (status == errSecSuccess) {
            dispatch_async(dispatch_get_main_queue(), ^{
                [interface keychainTaskFinished];
                [interface release];
            });
        } else {
            NSString * const descriptiveErrorString = @"Could not remove private key from keystore";
            dispatch_async(dispatch_get_main_queue(), ^{
                [interface keychainTaskFinishedWithError:status descriptiveMessage:descriptiveErrorString];
                [interface release];
            });
        }
    });
}

Note that after these changes, your application will need to either use QGuiApplication or you will need to initialise NSApplication yourself if you use QCoreApplication.

Testing the changes with a fresh build of QtKeychain, I was happy to see the freezes are now gone in the Nextcloud desktop client. 🙂

vid

Thanks to Frank Osterfeld for reviewing the pull request!

Today we are announcing the availability of the latest release of LabPlot: Say hello to LabPlot 2.10!

This release comes with many new features, improvements and performance optimizations in different areas, as well as with support for new data formats and visualization types.

The major new features are introduced below. For a more detailed review of the changes in this new release, please refer to the ChangeLog file.

The source code of LabPlot, the Flatpak and Snap packages for Linux, as well as the installer for Windows and the image for macOS are available from our download page.

What’s new in 2.10?

Worksheet

LabPlot’s worksheet comes with new visualizations and more advanced plots, including:

  • Bar plots
  • Plot templates that allow you to save and re-use custom plot configurations
  • Error bars in histograms
  • Rug plots for box plots and histograms
  • More flexible and customizable box plots
  • Reference ranges, that is, custom areas on the plot to highlight x- and y-ranges
  • LaTeX error messages in text labels when rendering with LaTeX

Spreadsheet

The Spreadsheets gain more functions and operations to modify and generate data:

  • Data sampling (random and periodic methods)
  • Data flattening to convert pivoted data to column base format
  • Baseline subtraction using the arPLS algorithm
  • Heat-map formatting for categorical data in text columns
  • Column statistics for text columns, including the frequency table, bar and Pareto plots
  • Functions to access arbitrary cells of columns with cell (f(index), g(column, ..))
  • Functions to work with column statistics (size, mean, stddev, etc.)
  • Ability to specify the seed number when generating random numbers

Analysis

The new analysis tools added to LabPlot 2.10 include:

  • Maximum likelihood estimation for several distributions
  • Guess start values of fit parameter for polynomial models by linear regression
  • Export the results of a computation to a new spreadsheet
  • Fourier filtering for DateTime data

Import/Export

LabPlot 2.10 adds support for new file formats and multiple optimizations to improve import performance:

  • Import of Excel .xlsx files
  • Export spreadsheet and matrices to Excel .xlsx format
  • Import of Binary Log File (BLF) files from Vektor Informatik
  • HDF5: support VLEN data import
  • Reduced memory consumption when importing from a database table into a spreadsheet
  • Reduced memory consumption during the spreadsheet export to SQLite databases
  • Faster import of files with a large number of columns

Notebook

The 2.10 release Improves the variable panel and plot export:

  • Show the type of a variable, its size (in Bytes), and its dimension (number of rows and columns) for backends that provide this information
  • Properly show the values of Octave’s row vectors and matrices
  • Allow to copy variable names and values to the clipboard
  • Export plot results to vector graphic formats (PDF and SVG)

Tuesday, 14 March 2023

KBibTeX 0.9.3.2 got released, tar-balls are available at KDE’s download mirrors. This is the last release of the 0.9.x branch. Next is 0.10, where I will prepare release candidate tar-balls in the next few days and hopefully we will see a final release 0.10.0 this Spring.

A number of issues got fixed, including but not limited to:

  • Bugs 463398, 459150, 464607, and 464606.
  • Various online searches got revamped and should work again.
  • Building against newer Qt versions (thanks to Albert Astals Cid)

See the full ChangeLog for all the details.

Some spoilers about what is happening in the ‘master’ branch: I have been working on an exporter to Microsoft Word’s bibliography XML. Writing scientific manuscripts with references in Word is a painful experience, but this exporter allows you to continue to use your favorite BibTeX editor even under dire circumstances.

Monday, 13 March 2023

Dear digiKam fans and users,

After three months of active maintenance and other bugs triage, the digiKam team is proud to present version 7.10.0 of its open source digital photo manager.

See below the list of most important features coming with this release.

Bundles Internal Component Updates

As with the previous releases, we take care about upgrading the internal components from the Bundles. Microsoft Windows Installer, Apple macOS Package, and Linux AppImage binaries now hosts:

Thursday, 9 March 2023

There has been some recent discussions about how KDE applications (or Qt apps in general) should look and feel like outside of the Plasma desktop, particularly in a GNOME environment.

During this discussion I noticed two major disconnects between the involved parties. One of them is technical in nature, where (understandably) not everyone involved has deep knowledge about how Qt and KDE apps work. The other one is cultural in nature, where there’s opposing views about who gets to decide how an application should look and feel like on a given platform.

I can’t do much about the cultural issue, but I can help the conversation by giving some much needed overview of how any of this works on a technical level. Everyone being on the same page technically could help foster a more productive conversation about this complex topic.

First of all it’s important to note that Qt to its core is an abstraction across various plaforms (most important here are Linux, Windows, and macOS, but also to some degree Android and iOS). Whenever possible Qt tries to use the platform’s native facilities to do anything, whether that’s rendering, file dialogs, widget styles etc. This becomes somewhat messy when you consider that “Linux” isn’t exactly a single, well-defined “platform”. Qt does usually have non-native fallbacks for things like file dialogs and widget styles, but they aren’t necessarily something you want a user to have to see. It’s also important to mention that Qt has two somewhat competing ways of defining UIs, the traditional QtWidgets, and the more recent QtQuick/QML.

There are several somewhat independent pieces involved in how a Qt application looks and feels. Jan Grulich already talked about some of them in the context of GNOME and QGnomePlatform, but there are also things specific to KDE applications that aren’t mentioned.

The first piece is the “Qt Platform Theme (QPT)”. Despite the name it doesn’t have much to do with the visual style. It is responsible for applying settings from the platforms. This for example includes font settings, the double click interval, or whether a file should be openend on single or double click. It also defines how standard dialogs look like, most importantly the file picker dialog, but also dialogs like a color picker. Third, it defines the color palette (QPalette) the application is using. More on that later. Qt itself ships platform themes for non-Linux platforms as well as somewhat generic Linux platform themes for GNOME and Plasma. Notable out-of-tree plugin exist, like plasma-integration which you are using right now if you are on Plasma, the aforementioned QGnomePlatform targeted towards GNOME (and to some degree similar environments), and qt5ct, which isn’t aligned to a specific environment and provides generic control over platformtheme things.

The second, and perhaps most well-known, knob is the widgets style (also called QStyle). It controls the majority of the appearance of a QtWidgets application. Well-known examples include Breeze (the current Plasma default), Oxygen (the KDE4-default), adwaita-qt, as well as built-in styles for Windows/macOS. Qt also comes with a built-in Fusion style. QStyles are implemented using C++ plugins. Whenever the app needs to render some piece of UI, e.g. a button, it defers that to the style plugin. Some style, like e.g. Windows then use platform native APIs to render widgets, others like Breeze draw the widgets from scratch. Application developers can also include custom styles for complete control over the appearance.

The third important concept is QPalette. A QPalette is a set of colors used to draw UI elements. The palette is defined by the platform theme(!). For example Plasma uses this to apply the color scheme set in System Settings. QGnomePlatform uses it to apply Adwaita-like colors. The selected QStyle may (or may not!) use this palette when drawing controls. The application developer can also manually query colors from the palette for drawing custom widgets while still respecting the platform’s wanted colors. A platform theme may only offer a single palette this way, or include light and dark variants, or allow the user to configure arbitrary color sets (like we do on Plasma). It is also possible for application developers to override the system-provided palette, for example to offer an in-app dark mode switch.

For applications using QML there is another relevant component: The Qt Quick Controls 2 Style. For reasons I’m not going to go into QtQuick Controls don’t use QStyle for their styling. Instead they come with their own stying system, which is itself based on QML. In Qt5 QML apps only have a very basic and broken default theme that should never be used. In Qt6 they use Fusion by default.

These are the relevant knobs every Qt app has. Some app developers choose to use them to control the appearance of their apps themselves, but many others leave it to the environment to apply a suitable look and feel. Furthermore, there are some relevant KDE-additions to this that are important to understand.

One such addition is KColorScheme. You can think of KColorScheme as a superset of QPalette, i.e. it provides additonal color roles and thus finer-grained control over colors. When changing the Colors setting in Plasma’s System Settings you are picking a color scheme. This gets applied to QPalette via the plasma-integration QPT, but can also be queried directly by the application developer for custom painting. Contrary to QPalette a KColorScheme is not porgrammatically filled based on plaform values (that happens only on Plasma), but it is a static, textual list of colors. Here we have the first problem for running KDE applications under e.g. GNOME. When running a KDE app on GNOME QGnomePlatform will apply Adwaita colors using QPalette. However, this does not affect colors the application directly pulls from KColorScheme, which unless explicitly configured has a default that resembles Breeze. This means we get mixtures of two different color sets, giving unpleasant results. This is especially noticeable when using a dark system theme combined with the light default colors from KColorScheme.

How do we solve this? Well, I’ve been banging my head against that problem for a while. Short of removing the concept of KColorScheme entirely I see two realistic options, not necessarily mutually exclusive. QGnomePlatform could create a KColorScheme definition with Adwaita-like colors and apply that to the application. If exuted correctly it would likely give very good results, but obviously only on platforms that use QGnomePlatform. The other option would be to programmatically derive a KColorScheme definition from a QPalette, which is likely much harder because KColorScheme is a superset of QPalette, but it would be a generic solution for all platforms.

The second noteworthy thing for KDE applications affects QML apps in particular. I’ve mentioned that QML has a separate theming system compared to QtWidgets. Because maintaining two style definitions for different systems is no joy KDE maintains a “hack” around this. qqc2-desktop-style implements a Qt Quick Controls style that fetches style information from a QStyle, which means all the existing QStyles out there keep working for QML apps. It works amazingly well, until it doesn’t. One of the shortcomings of this approach is that qqc2-desktop-style internally heavily relies on KColorScheme, which makes the aforementioned mismatch between QPalette and KColorScheme much more prominent. Possible solutions are the same as mentioned before.

I hope this gives some much needed overview over technology and terminology of involved components and helps with a productive way forward with addressing the problems we have. You are welcome to join this discussion. There’s some other relevant things to talk about, like icon loading, theming, and rendering, but that’s for another day.

Wednesday, 8 March 2023

Screenshot of version 0.5.3 with gradients

We're excited to announce the release of Glaxnimate 0.5.3! This update includes a number of new features, bug fixes, and improvements to the user experience.

Editing

Glaxnimate 0.5.3 introduces several new editing features:

There's a new keyframe preset called "Fast" that basically has the reverse effect of "Ease".

Additionally, this release adds support for conical gradients.

Users can now select the first Bezier node from the node's context menu.

Version 0.5.2 introduced the ability to animate along a path, 0.5.3 makes this easier as now there's a new context menu entry for position properties showing a dialog to select a shape to follow.

User experience

In addition to editing improvements, Glaxnimate 0.5.3 includes several UI enhancements. We've made color values in tree views more visually appealing, and removed extra items from the "Move To" dialog.

Changing fill, stroke, and gradient properties now applies to the whole selection rather than the last selected object.

We've also revamped the context menu for properties, making them consistent between the timeline and the canvas.

Editing tools are more forgiving now when you release modifier keys before finishing the shape.

Users can now choose whether the timeline scrolls vertically or horizontally without modifiers, and we've added new layout presets to better accommodate a variety of screen sizes.

File Formats

This release also includes updates to Glaxnimate's import and export functionality.

The main new feature here is the ability to import and export Android Vector Drawables, the animation format used when making animated icons for Android.

We've also fixed various issues with the SVG parser, improving support for animated paths.

Opening raster images now uses the file basename as layer name, and we've resolved a bug affecting plugin export.

Bug Fixes

Finally, Glaxnimate 0.5.3 includes a number of bug fixes. We've addressed an issue with layers created by drawing tools not having an end frame, and fixed several other small bugs affecting the user experience.

We encourage all users to upgrade to Glaxnimate 0.5.3 to take advantage of these new features and improvements. You can download the latest version of Glaxnimate from the download page.