Skip to content

Friday, 7 April 2023

Flatpaks are amazing and all that. But application sandboxing, so an application cannot do anything it wants, is a challenge - even more so when you have two applications that need to talk to each other. Perhaps it shouldn’t come as a surprise that native-messaging sandboxing support for Flatpak has been in development for over a year. To celebrate its anniversary I thought I’d write down how to drill a native-messaging sized hole into the sandbox. This enables the use of native messaging even without portal integration, albeit also without sane degrees of sandboxing.

First off, please understand that this undermines the sandbox on a fairly fundamental level. So, don’t do this if you don’t keep your Firefox updated or visit particularly dodgy websites.

For the purposes of this post I’m assuming Firefox and KeePassXC are installed as Flatpaks in user scope.

First order of business is setting up KeePassXC so it writes its definition file in a place where Firefox can read it. Fortunately it has a setting for this:

~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/ is the path inside Firefox’ home where the defintion file will be written. Naturally we’ll also need to adjust the Flatpak permissions so KeePassXC can write to this path.

flatpak override --user --filesystem=~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts org.keepassxc.KeePassXC

At this point Firefox knows about the native messaging host but it won’t be able to run it. Alas. We need some rigging here. The problem is that Firefox can’t simply flatpak run the native messaging host, it needs to spawn a host process (i.e. a process outside its sandbox) to then run the KeePassXC Flatpak and that then runs the NMH.

Fortunately the NMH definition files are fairly straight forward:

{"allowed_extensions":["keepassxc-browser@keepassxc.org"],
"description":"KeePassXC integration with native messaging support",
"name":"org.keepassxc.keepassxc_browser",
"path":"/home/me/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC",
"type":"stdio"}

The problem of course is that we cannot directly use that Flatpak bin but need the extra spawn step in between. What we need is a way to manipulate the definition file such that we can switch in a different path. systemd to the rescue!

systemctl edit --user --full --force keepassxc-native-messaging-mangler.path

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

[Path]
PathChanged=/home/me/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

[Install]
WantedBy=default.target

and the associated service file…

systemctl edit --user --full --force keepassxc-native-messaging-mangler.service

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

[Unit]
Description=keepassxc mangler

[Service]
ExecStart=/home/me/keepassxc-native-messaging-mangler

lastly, enable the path unit.

systemctl --user enable --now keepassxc-native-messaging-mangler.path

Alright, there’s some stuff to unpack here. KeePassXC on startup writes the aforementioned definition file into Firefox’ NMH path. What we do with the help of systemd is monitor the file for changes and whenever it changes we’ll trigger our service, the service runs a mangler to modify the file so we can run another command instead. It’s basically an inotify watch.

Here’s the mangler (~/keepassxc-native-messaging-mangler):

#!/usr/bin/env ruby
# frozen_string_literal: true

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

require 'json'

file = "#{Dir.home}/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json"
blob = JSON.parse(File.read(file))
blob['path'] = "#{Dir.home}/Downloads/keepassxc"
File.write(file, JSON.generate(blob))

It simply replaces the path of the executable with a wrapper script. Here’s the wrapper script (~/Downloads/keepassxc):

#!/bin/sh

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

exec /usr/bin/flatpak-spawn --host --watch-bus "$HOME/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC" "$@"

flatpak-spawn is a special command that allows us to spawn processes outside the sandbox. To gain access we’ll have to allow Firefox to talk with the org.freedesktop.Flatpak DBus session service.

flatpak override --user --talk-name=org.freedesktop.Flatpak org.mozilla.firefox

And that’s it!

➡️ KeePassXC writes its NMH definition to Flatpak specific path ➡️ systemd acts on changes and starts mangler ➡️ mangler changes the path inside the definition to our wrapper ➡️ Firefox reads the definition and calls our wrapper ➡️ wrapper flatpak-spawns KeePassXC flatpak ➡️ Firefox (flatpak) talks to KeePassXC (flatpak)

Thursday, 6 April 2023

Buttons are a fundamental element in user interfaces, but it’s easy to make some accessibility mistakes when using icon-only buttons in QML.

First, please avoid icon-only buttons and only use then, when the icon is very well known (e.g. arrows, delete or favorite icons) and the space is limited.

In case you still want to use an icon-only button. Make sure to set the text: property and that it is also translatable. Otherwise, a screen reader won’t know that to say about the button. This is because the text: property is used as default value for the Accessible.name: property, so when it is not set Accessible.name is empty and the screen reader can only say that the currently focused control is a button. The trick to have both the text: property set and an icon-only button is to use the display: property and assign it to the AbstractButton.IconOnly.

This gives us the following code:

import QtQuick 2.15
import QtQuick.Controls 2.15

Button {
 text: i18n("Favorite")
 icon.name: 'favorite'
 display: AbstractButton.IconOnly
}

Finally, another essential part is that an icon-only button requires a tooltip. We need the tooltip in case the user is unsure about the meaning of the icon and we need more details.

import QtQuick 2.15
import QtQuick.Controls 2.15

Button {
 text: i18n("Favorite")
 icon.name: 'favorite'
 display: AbstractButton.IconOnly

 ToolTip.text: text
 ToolTip.delay: Kirigami.Units.toolTipDelay
 ToolTip.visible: hovered
}

Note that this used the ToolTip attached property instead of a separate item ToolTip {} as it is more memory efficient. With the attached property, we share the tooltip instance across the entire application instead of instanciating a ToolTip popup for each button.

Sunday, 2 April 2023

The KDEPIM team like most got impacted by the pandemic and had to let go of lovely traditions. One of those being to meet in Toulouse at the beginning of spring. The last one was in 2019 so reviving that meeting was long overdue.

Since the last time, quite a few things changed in Toulouse of course… for instance the old venue wasn’t available anymore. Luckily, with a couple of friends we revived the local C++ Workshops a few months back in a new venue as well. Since it is a cool fablab very well situated in the town center we asked them if they’d be ready to host Free Software hackers for a whole week-end and they happily agreed to it.

Thanks to this nice conjunction of events, we organized the KDEPIM Sprint 2023 the first week-end of April

The Warm-up

Some of the team (namely Ingo and Volker) arrived early before the official start. Of course, we planned for that and had access to the venue from the Friday afternoon.

But before heading there, we had to visit the now mythical Cake Place™ for lunch. With a pair of happy hackers fully loaded with fat and sugar, the work could start.

Happy Ingo and Volker

We thus finished preparing and planning what would happen during the week-end once we would be joined by Laurent and Carl. We also managed to get started on some of the explorations around KCalendarCore which would end up being a recurring theme for some of us.

Day 1

After a quick breakfast at the venue, we started listing the topics we wanted to discuss during the sprint. Most of it was already captured on the wiki before we arrived but a couple more appeared at that point.

We basically identified two types of conversations:

  • those for which we needed bigger discussions with everyone to set the overall direction;
  • those for which we already had agreement on the direction but needed a finer grained look at them to actually have a proper battle plan, they didn’t require everyone and we did break out groups for those.

All of this was time boxed with proper debrief and capturing notes on the wiki to try to avoid loosing too much context. This pretty much filled up our day but we managed to have a few patches done during that time.

Processing discussions

As for the conversations they covered mostly the following topics:

  • decoupling KDAV from KIO
  • easing the use of KCalendarCore::Calendar for asynchronous code (since it exposes a synchronous API)
  • overall shrinking KCalendarCore::Calendar’s API, it’s fairly large and unfocused currently, we want to focus it on an easy to use core
  • deciding on a new custom properties API for KCalendarCore
  • retiring the mixed maildir and the kolab resources which is easier said than done, since we want to ensure minimal disruption for the users using those resources
  • improving the Windows compatibility, especially important for Kalendar at the moment
  • retiring the Kross based account wizard for a modern QML one
  • fixing important dependencies in akonadi-contacts to reduce reliance on widgets (necessary for Kalendar and mobile)
  • using QtKeychain in KMailTransport properly
  • removing the KMailTransportAkonadi API
  • eliminating Kalendar’s reliance on some of the KOrganizer settings
  • improving our APIs for QML consumption and factoring out some of Kalendar internals for reuse
  • and of course, planning and the overall timeline towards a “PIM 6” release

The KDEPIM team being currently fairly small, one of the constant concern which forced some of the choices we made was to keep it realistic. It’s no use to make grand plans we can’t execute on the large codebase we have to maintain with only a handful of people.

Now if more contributors are coming in (hint hint) we could of course be more ambitious at places in the future. We definitely have the ideas, so if you want to have fun and help, get in touch!

Day 2

We managed to conclude the last discussion we planned before Laurent had to head back home. This means we successfully covered all of the 15 topics we had to deal with while everyone was around. We tried to make sure they all led to actionable items.

All done... creating actions

That’s why to plan and drive the effort, we created a new project on Gitlab. This already got filled with the results of our discussions. Some of the issues being actively worked on as I’m typing this. Merge requests are already pouring in various PIM related repositories!

I’m looking forward to running my scripts on said repositories in a couple of weeks to see how noticeable the uptick of activity will be. ;-)

Last but not least

I’d like to thank Artilect and KDE e.V. to make this event possible. This wouldn’t be possible without a venue and without at least partial support in the travel expenses.

Also, I’d like to give a special thanks to Sébastien Dinot who has been my partner in crime pulling this off. He’s been a big help with some of the logistics and a very patient key master.

Finally, if you like such meetings to happen in the future so that we can push forward your favorite software, please consider making a tax-deductible donation to the KDE e.V. foundation or contacting Artilect for a donation as well (they unfortunately don’t have a donation page up yet but that’s coming).

Friday, 31 March 2023

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


The Twitter API is now effectively unmaintained | snarfed.org

Tags: tech, fediverse, twitter

Twitter continues its slow death… That likely explains why the Mastodon to Twitter bridge I’m using has become so unreliable. I’ll just keep ignoring it I guess.

https://snarfed.org/the-twitter-api-is-now-effectively-unmaintained


Cerebras-GPT: A Family of Open, Compute-efficient, Large Language Models - Cerebras

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

Clearly aims to demonstrate the superiority of their specialized hardware for training. That said it’s nice to have proper open models available (architecture, training data, weights… it’s all in the open).

https://www.cerebras.net/blog/cerebras-gpt-a-family-of-open-compute-efficient-large-language-models/


What is the origin of model-view-controller? - Quora

Tags: tech, architecture, design, history

Nice historical perspective from Alan Kay about the MVC architecture pattern.

https://www.quora.com/What-is-the-origin-of-model-view-controller


Biscuit authorization

Tags: tech, cryptography, security

This looks like an interesting new authorization scheme.

https://www.biscuitsec.org/


Making Python 100x faster with less than 100 lines of Rust

Tags: tech, rust, python, profiling, performance

Nice walk through for a use of PyO3 to make some Python code much faster. Nice to see how useful py-spy turn out to be in such scenarii as well.

https://ohadravid.github.io/posts/2023-03-rusty-python/


Make your own Optionals

Tags: tech, programming, java, type-systems

There are nice mechanism in the Java type system nowadays to no rely on Optional all the time. This is a good reminder of the main alternative.

https://mccue.dev/pages/3-28-23-custom-optional


The Ambiguous Zone - Ben Northrop

Tags: tech, team, craftsmanship, organization

We might start in a software career attracted by the “perfection of the machines” (already debatable) but indeed to make anything meaningful we need to interact with other people. I often say it but I’ll say it again: it is a team sport.

https://www.bennorthrop.com/Essays/2023/the-ambiguous-zone.php


Why Engineers Need To Write - by Ryan Peterman

Tags: tech, craftsmanship, writing, remote-working

Indeed, this is the most important skill we need next to coding. Especially in a remote work culture.

https://www.developing.dev/p/why-engineers-need-to-write


The Definition of Senior: A Look at the expectations for Software Engineers

Tags: tech, career, management, leadership, engineering

Nice (even though a bit long) explanation of the skills needed for a senior software engineers. Definitely a bunch of good advises in there.

https://loige.co/the-senior-dev/


Incompetent but Nice - Jacob Kaplan-Moss

Tags: management

Note it’s not about impostor syndrome, I guess lots of us think we’re in this category, that doesn’t make it real.

Anyway, from the management point of view this is indeed a baffling situation when you encounter someone like this. What to do? Definitely not always easy, sometimes induced by the organization as well so it would be too easy to blame on the person alone. We need to pay more attention to those and there’s clearly no magical recipe to handle them.

https://jacobian.org/2023/mar/28/incompetent-but-nice/


The age of average — Alex Murrell

Tags: culture, architecture, design

This is indeed a phenomenon which I find odd. Everywhere you look, culture seems like it became homogeneous… I don’t like this much, but indeed it means it’s easy to be distinctive if you want to.

https://www.alexmurrell.co.uk/articles/the-age-of-average


Bicycle – Bartosz Ciechanowski

Tags: science, physics, bike

Once again an excellent deep dive… We’re getting into the physics of biking, and there are some surprises along the way! In any case this is fascinating all the thinking which went into such an object, the wheels alone are a very clever system.

https://ciechanow.ski/bicycle/


Treat your to-read pile like a river | Oliver Burkeman

Tags: culture, productivity

Good advice to fight against FOMO as far as reading material is concerned… just pluck things as they pass by. There’s so much content there’s likely redundancy anyway, hopefully. Yeah… I’m not cured.

https://www.oliverburkeman.com/river



Bye for now!

Wednesday, 29 March 2023

Another month in the year, another collection of bugfixes and features I contributed to KDE!

Documentation Improvements

Something I want to improve for KDE Frameworks 6 is the API documentation, it’s pretty bad sometimes:

How do I even import this component?

[Bugfix] For plasma-framework, we started marking private QML types as internal. I’m in the process of manually fixing up the custom QQuickItem types in plasma-framework too, although I haven’t gotten around to opening up a merge request for that.

[Feature] I opened a doxyqml1 merge request to make it’s output more useful, by automatically adding import statement hints to the page:

Example of the new doxyqml output

Plasma 6 Porting

[Feature] Early this month, I ended up porting most of our applets to Plasma 6! The current hitlist is:

Screenshot of the applets running on Plasma 6!

The two I’m still working on and need further testing and reviewing:

I also fixed activity switching, and fixed KRunner’s broken layout.

For those who are building Plasma 6 for the first time, extragear modules are now built by default!

PlasmaTube

[Feature] I started using PlasmaTube which is KDE’s Youtube Client, to replace FreeTube. I started by cleaning up and overhauling the account management, so it flows better.

The new login page

[Bugfix] I also made the info chips non-interactable, fixed the spacing on video grid text, added more loading placeholders and stop desktop users from being able to drag the video page.

Ruqola

[Feature] Because of $work, I discovered that we have a Rocket.chat client! I miss being able to quickly switch my presence via the tray icon, so that’s the first thing I opened a merge request for.

Screenshot of the presence context menu

Dr. Konqi

[Feature] Someone pointed out that the margins in the bug reporting wizard was terrible, so I started a redesign of the whole UI trying to update it to look similar to our modern applications:

WIP Bug Context Page WIP Backtrace Page

Tokodon

In preparation for the 23.04 gear release, I added a slew of new features and bugfixes!

Screenshot of the inline reply previewScreenshot of the newly added notification filter types

And of course, there are of course many bugfixes:

[Feature] As a treat for people who manage popular accounts - like our great KDE and Krita promo teams - I have a work-in-progress merge request to allow you to group notifications! I expect to find time next month to finish and polish this feature, but no promises yet.

Screenshot of the notification grouping (work in progress)

Miscellaneous


  1. Doxygen doesn’t support QML natively, so doxyqml is a plugin to help generate doxygen pages for QML types. ↩︎

Tuesday, 28 March 2023

gcompris 3.2

Today we are releasing GCompris version 3.2.

This new version contains some bug fixes on multiple activities such as "Discover the International Morse code", "Control the hose-pipe" and music activities.

It also contains new graphics for all memory activities and for "Baby puzzle".

A new command-line argument (--difficulty {value|min-max}) has been added which allows users to force the difficulty filter at a given value or range.

The Andika font has been updated to its latest version (6.200).

It is fully translated in the following languages:

  • Breton
  • Catalan
  • Catalan (Valencian)
  • Greek
  • UK English
  • Spanish
  • Basque
  • French
  • Croatian
  • Italian
  • Lithuanian
  • Malayalam
  • Dutch
  • Norwegian Nynorsk
  • Polish
  • Portuguese
  • Brazilian Portuguese
  • Romanian
  • Slovenian
  • Turkish
  • Ukrainian
  • Chinese Traditional

It is also partially translated in the following languages:

  • Azerbaijani (99%)
  • Belarusian (79%)
  • Czech (88%)
  • German (99%)
  • Estonian (99%)
  • Finnish (94%)
  • Hebrew (99%)
  • Hungarian (99%)
  • Indonesian (99%)
  • Macedonian (94%)
  • Russian (99%)
  • Slovak (77%)
  • Albanian (99%)
  • Swedish (98%)

Thank you all,
Timothée & Johnny

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!