Bountysource update
I quickly wanted to share an update to my previous post our leaving Bountysource behind (at least as platform for individual bug bounties).
Bountysource support has informed us that “All bounties on Xfce issues have been refunded and backers notified.”
If you are a backer of one of our issues registered on Bountysource and haven’t been refunded or at least approached please reach out to Bountysource support! (support@bountysource.com)
Meanwhile others (e.g. the elementary project) have also decided to move on for the same reasons…
Thunar, GtkAction and a big mess
Overview
My journey into the GtkAction abysses of Thunar began in the mid of 2019. Be warned, it is no story of success. It is rather a story about finding a way through a maze while walking into almost every dead end.
Actually I just wanted to fix #198 (Merge all file-context-menus into one). But somehow things got weird. More than half a year later and after numerous interactive rebases I finally merged my branch into master \o/
Motivation
The old Thunar used to create the same menu items in different places using different code. In the past that led to inconsistencies. E.g. the location bar only provided a very minimal context menu, no custom actions at all.
From time to time I found myself right-clicking on a location-button, just to find out that there still is no custom action. At some point of maximal annoyance I decided to fix that problem … not sure if I would have done so when I knew how long that road would be.
Looking at thunar-location-buttons.c revealed a lot of duplicated code. thunar-standard-view and thunar-window both used the deprecated GtkActionEntry to define menu item labels and related actions. The location buttons just mirrored parts of that code. On top some other actions were defined in thunar-launcher or had their own classes, inheriting GtkAction.
So yay, lets just copy+paste the missing stuff to the location buttons? Nah, that would be too easy. As a developer who values DRY, it would hurt my belief in clean code to produce more mess.
Let’s Start Hacking
I started to do some coding .. first I created a new widget thunar-menu which internally is a gtk-menu, and moved menu-item creation and the related actions for copy/cut/paste/delete/move_to_trash there to have them at some central place, so they can be reused by different menus. I as well moved the actions from thunar-launcher to thunar-menu (I guess the original intention of the launcher was, to actually launch things, not to manage menu-items) and replaced separate action classes in favour of methods inside thunar-menu.
Meanwhile the location-button-menu and the context-menu, which I used for testing, were populated with some items again.
The old code made massive use of the deprecated GtkAction and GtkActionEntry classes together with GtkUiManager. I did not want to add more G_GNUC_BEGIN_IGNORE_DEPRECATIONS to silence warnings. So I decided to replace the deprecated calls.
Looking into the gtk3 documentation revealed that there now is GAction and GActionEntry which provides some service around accelerator activation, and there is GtkMenu/GMenu for which at that time I had no clear idea why there are two of them.
The documentation of GAction told me that it should not be used for anything related to labels, icons or creation of visual widgets, damn. So at that time I did not see an advantage in using this class. I decided to rather go for GtkMenu together with some custom replacement for GtkActionEntry: XfceGtkActionEntry.
In retrospective ignoring GAction might not have been my smartest move. Meanwhile I understood how GAction can be used with GtkMenu, and I will most likely go for it at some later point.
Regarding GtkUiManager: The definition of menu-items of Thunar was scattered across 7 different *-ui.xml files, making it hard to figure out what belongs together. Because of that I decided to just get rid of the deprecated GtkUiManager and create menu-items in the code instead of predefining their order in xml. IMO the usage of xml files might be nice for static GUI’s, though for dynamic menu-creation it just introduces unnecessary complexity.
So I started to build XfceGtkActionEntry and some support methods.XfceGtkActionEntry is a structure which holds labels, tooltips, icons, types, the accelerator paths and callbacks to the related actions. Like GtkActionEntry it is just a struct and can be filled in a static way.
Next problem: The menus in Thunar so far did not get destroyed, but were updated whenever the selected items got changed, and got shown when needed. That sounded wrong to me. Why should I want to update menu-items, which can be expensive, while no menu is visible at all ? There were bugs about menu flickering and slowness while rubber banding/mass select which seem to be related. Since I anyhow needed to touch that part, I decided to build menus only when they need to be shown.
Things went well, I came to the point where I needed some items from thunar-window, like the zoom-section and the view-specific settings. As well most file-menu items in the thunar-window menu did not work any more since I moved management of them from thunar-launcher to thunar-menu. So next step clearly was: Introduce XfceGtkActionEntry to thunar-window … and than shit hit the fan.
So far the thunar-window menu was always present and took care for any accelerator actions. Since my concept was “create menu on request”, there was no menu instance which could take care for accelerators any more, leading to dysfunctional accelerator keys, rendering my whole concept as faulty .. aargh.
Start all over again
After some time of grieve and doubts I fixed the problem by moving most of the code from thunar-menu back to thunar-launcher, which lifetime is coupled to thunar-window.
From now on thunar-menu was more or less just an convenience wrapper for thunar-launcher … still useful, but sadly it lost its glory. thunar-launcher now builds volatile menu items on request and permanently listens to the related accelerators. Finally accelerators started to work fine, and I was able to continue to fight with the window menu.
I had much more trouble with that menu, too much to tell it here .. however somehow I managed to get it functional, so that it mostly worked like before.
An unpleasant discovery
Later on, while reporting a bug against gtk I learned that the class gtk_accel_map, which I use as a central part will be deprecated soon … aargh again. The gtk devs so far just missed to set a deprecation macro. So it seems like I will need to touch the accelerator part again. This time I plan to make use of the GActionMap interface .. going to be a story for another day.
Testing and open issues
For first testing and code-review I luckily got support of some early adopters. They found many more defects and regressions which kept me busy a long while. Fortunately nothing concept-breaking was found.
While writing this there are still some regressions I introduced, waiting to get fixed by me before a stable release:
- Regression: Missing accelerators for bookmark items
- GObject-WARNING on closing thunar in some conditions
And there are related tasks on my agenda, for which I just did not find the time so far:
- rename
thunar-launcherto e.g.thunar-action-manager - use
thunar-menuinbookmark view - use
thunar-menuinTree view - many minor things
Conclusion
Finally I ended up with 25 commits and +4717 / -7149 line changes. The occurrence of G_GNUC_BEGIN_IGNORE_DEPRECATIONS got reduced from 250 to 35. The remaining 35 occurrences will further drop when using GtkMenu for bookmark-view/tree-view. That should simplify the move to gtk4 in the future. The location-button context menu shows custom-actions now, and as well some other bugs got fixed with the changes.
So overall, the result does not look too bad I guess.
Well, this blogpost grew by far too long. I hope you nevertheless enjoyed the journey into the Thunar internals!
… enough storytelling for now, I really need to take care of these remaining regressions! :)
Thanks to Reuben, AndreLDM, DarkTrick and others for early testing and bug reporting! Special thanks to AndreLDM, motivating me to write this blogpost at all :D.
Thunar, GtkAction and a big mess
Thunar, GtkAction and a big mess
Overview
My journey into the GtkAction abysses of Thunar began in the mid of 2019. Be warned, it is no story of success. It is rather a story about finding a way through a maze while walking into almost every dead end.
Actually I just wanted to fix #198 (Merge all file-context-menus into one). But somehow things got weird. More than half a year later and after numerous interactive rebases I finally merged my branch into master \o/
Motivation
The old Thunar used to create the same menu items in different places using different code. In the past that led to inconsistencies. E.g. the location bar only provided a very minimal context menu, no custom actions at all.
From time to time I found myself right-clicking on a `location-button`, just to find out that there still is no `custom action`. At some point of maximal annoyance I decided to fix that problem ... not sure if I would have done so when I knew how long that road would be.
Looking at thunar-location-buttons.c revealed a lot of duplicated code. thunar-standard-view and thunar-window both used the deprecated GtkActionEntry to define `menu item labels` and related actions. The `location buttons` just mirrored parts of that code. On top some other actions were defined in thunar-launcher or had their own classes, inheriting `GtkAction`.
So yay, lets just copy+paste the missing stuff to the location buttons? Nah, that would be too easy. As a developer who values DRY, it would hurt my belief in clean code to produce more mess.
Let's Start Hacking
I started to do some coding .. first I created a new widget thunar-menu which internally is a gtk-menu, and moved menu-item creation and the related actions for copy/cut/paste/delete/move_to_trash there to have them at some central place, so they can be reused by different menus. I as well moved the actions from `thunar-launcher` to `thunar-menu` (I guess the original intention of the launcher was, to actually launch things, not to manage menu-items) and replaced separate action classes in favour of methods inside `thunar-menu`.
Meanwhile the location-button-menu and the context-menu, which I used for testing, were populated with some items again.
The old code made massive use of the deprecated `GtkAction` and `GtkActionEntry` classes together with `GtkUiManager`. I did not want to add more `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` to silence warnings. So I decided to replace the deprecated calls.
Looking into the gtk3 documentation revealed that there now is GAction and GActionEntry which provides some service around accelerator activation, and there is GtkMenu/GMenu for which at that time I had no clear idea why there are two of them.
The documentation of GAction told me that it should not be used for anything related to labels, icons or creation of visual widgets, damn. So at that time I did not see an advantage in using this class. I decided to rather go for `GtkMenu` together with some custom replacement for `GtkActionEntry`: XfceGtkActionEntry.
In retrospective ignoring `GAction` might not have been my smartest move. Meanwhile I understood how `GAction` can be used with `GtkMenu`, and I will most likely go for it at some later point.
Regarding GtkUiManager: The definition of menu-items of Thunar was scattered across 7 different *-ui.xml files, making it hard to figure out what belongs together. Because of that I decided to just get rid of the deprecated `GtkUiManager` and create menu-items in the code instead of predefining their order in xml. IMO the usage of xml files might be nice for static GUI's, though for dynamic menu-creation it just introduces unnecessary complexity.
So I started to build `XfceGtkActionEntry` and some support methods.`XfceGtkActionEntry` is a structure which holds labels, tooltips, icons, types, the accelerator paths and callbacks to the related actions. Like `GtkActionEntry` it is just a struct and can be filled in a static way.
Next problem: The menus in Thunar so far did not get destroyed, but were updated whenever the selected items got changed, and got shown when needed. That sounded wrong to me. Why should I want to update menu-items, which can be expensive, while no menu is visible at all ? There were bugs about menu flickering and slowness while rubber banding/mass select which seem to be related. Since I anyhow needed to touch that part, I decided to build menus only when they need to be shown.
Things went well, I came to the point where I needed some items from `thunar-window`, like the zoom-section and the view-specific settings. As well most file-menu items in the `thunar-window` menu did not work any more since I moved management of them from `thunar-launcher` to` thunar-menu`. So next step clearly was: Introduce `XfceGtkActionEntry` to `thunar-window` ... and than shit hit the fan.
So far the `thunar-window` menu was always present and took care for any accelerator actions. Since my concept was "create menu on request", there was no menu instance which could take care for accelerators any more, leading to dysfunctional accelerator keys, rendering my whole concept as faulty .. aargh.
Start all over again
After some time of grieve and doubts I fixed the problem by moving most of the code from `thunar-menu` back to `thunar-launcher`, which lifetime is coupled to `thunar-window`.
From now on `thunar-menu` was more or less just an convenience wrapper for `thunar-launcher` ... still useful, but sadly it lost its glory. `thunar-launcher` now builds volatile menu items on request and permanently listens to the related accelerators. Finally accelerators started to work fine, and I was able to continue to fight with the window menu.
I had much more trouble with that menu, too much to tell it here .. however somehow I managed to get it functional, so that it mostly worked like before.
An unpleasant discovery
Later on, while reporting a bug against gtk I learned that the class gtk_accel_map, which I use as a central part will be deprecated soon ... aargh again. The gtk devs so far just missed to set a deprecation macro. So it seems like I will need to touch the accelerator part again. This time I plan to make use of the GActionMap interface .. going to be a story for another day.
Testing and open issues
For first testing and code-review I luckily got support of some early adopters. They found many more defects and regressions which kept me busy a long while. Fortunately nothing concept-breaking was found.
While writing this there are still some regressions I introduced, waiting to get fixed by me before a stable release:
- Regression: Missing accelerators for bookmark items
- GObject-WARNING on closing thunar in some conditions
And there are related tasks on my agenda, for which I just did not find the time so far:
- rename `thunar-launcher` to e.g. `thunar-action-manager`
- use `thunar-menu` in `bookmark view`
- use `thunar-menu` in `Tree view`
- many minor things
Conclusion
Finally I ended up with 25 commits and +4717 / -7149 line changes. The occurrence of `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` got reduced from 250 to 35. The remaining 35 occurrences will further drop when using GtkMenu for bookmark-view/tree-view. That should simplify the move to gtk4 in the future. The `location-button` context menu shows custom-actions now, and as well some other bugs got fixed with the changes.
So overall, the result does not look too bad I guess.
Well, this blogpost grew by far too long. I hope you nevertheless enjoyed the journey into the Thunar internals!
... enough storytelling for now, I really need to take care of these remaining regressions! :)
Thanks to Reuben, AndreLDM, DarkTrick and others for early testing and bug reporting! Special thanks to AndreLDM, motivating me to write this blogpost at all :D.
Why Bountysource? Why?
TL;DR
- No more Xfce bugs on Bountysource.com (no support for GitLab)
- All remaining bug bounties returned to original backers
- Xfce Team account on Bountysource remains intact for now (including all donations so far)
Some background
When we kicked off Bountysource as one way to contribute to Xfce financially, this platform really seemed to be in a different place. It supported a multitude of bugtrackers (including our own, now archived, Bugzilla instance) and the web interface was frankly much more reliable.
When Bountysource decided to change its Terms of Service yesterday (note: the ToS change has been withdrawn since) this was a bit of a wake-up call for us. Let me briefly summarize: All uncollected bounties would after a fixed amount of time would have been withdrawn and the money retained by Bountysource. I can only presume that the business model of the platform is seriously struggling if such a drastic measure is imposed on the community when at the same time the fee of withdrawing/collecting bounties is at a not exactly unconsiderable 10%.
This all comes also after a so-called “inactivity fee” was introduced in 2018, which already felt strange and made me wonder what Bountysource does with all the money it holds for its users to justify such a fee. (Just putting the money in a regular bank account while holding on to it would earn you a little interest, as opposed to costing you – inflation ignored).
In any case, even if my reasoning above is not sound, we took the decision to disable bug bounties for Xfce starting now. This is the only reasonable step because GitLab is not supported, so we don’t have any way of updating our issues or confirming that they were closed (GitHub is the only supported platform these days).
The Bountysource Support team confirmed that all existing bug bounties will be returned to the original backers by them.
Please note that this change does not affect the Xfce Team account. We haven’t decided what our next step will be there but for the time being we will leave things as they are. So you can still donate to the Team and we can withdraw that money to use it for the project (footnote: we have not withdrawn anything so far).
GitLab CI is up and running
As announced less than two weeks ago, the next steps in our GitLab migration are following. While we originally planned that the migration from Bugzilla to GitLab issues would be the next step we received generous support from the brand new fosshost project: They provided us with the virtual infrastructure to be able to set up our first GitLab Runner.
A huge thank you to the fosshost for welcoming us aboard (and in record time)!
Standing on the shoulders of the xfce-test project by Florian and with support from A nice side-effect of having this container published on Dockerhub is that everyone can easily use it locally by running docker pull xfce/xfce-build.
If you’re curious what’s inside the container you can take a look at the Dockerfile. In short we use the latest Ubuntu 20.04 as a basis and then compile the Xfce core libraries based on the latest Git tag on the master branch.
The first project I set a pipeline up for is xfce4-settings. So from now on every commit and merge request will be built automatically and we as developers will receive immediate feedback. If you want to see what this looks like feel free to click here.
Next steps
Enabling the pipeline in more core repos will certainly be the next step. This should be as easy as adding this .gitlab-ci.yml file to the repository’s master branch and enabling the CI/CD feature of the project.
In parallel we have continued to work on the Bugzilla migration, but more on that later. Stay tuned!
Xfce switches to GitLab
GitLab is here!
Starting today, May 1, we’re switching from our cgit/gitolite setup to GitLab. Our old server, git.xfce.org, is now a ready-only in-sync mirror (so you can still pull code). Our new server is gitlab.xfce.org.
(The detailed version of this blog post can be read in my announcement on the Xfce Mailing List.)
For users nothing changes.
For distributors nothing changes (presuming you’re using the release tarballs and not Git tags).
For developers and contributors quite a few things change.
- Most importantly: The Git URL changed, so you need to update the remotes of your local repositories. Feel free to use our helper script.
- Fork repositories and use branches and merge requests!
- If you don’t have an account yet (we created quite a few for you regulars already) please sign up! We have opened registrations for GitLab accounts as well as allowing you to register with your GitHub account (if you have one).
Please poke us on IRC or the mailinglist if you’re lacking repository access or ownership. (By default new users cannot fork before being manually approved. Yes. We are afraid of the spambots.)
Have a nice GitLab!
Xfce PulseAudio Plugin 0.4.3 Released
Xfce PulseAudio Plugin 0.4.3 has arrived! It includes improved MPRIS compatibility and support for the Plasma Browser Integration plugin.
What’s New?
General
- Exo 0.11 or newer is now required
- Fixed various memory leaks and warnings
- Removed unused dbus-glib include (Xfce #15343)
- Replaced g_type_class_add_private deprecations
- Updated copyright years
- Updated URLs from goodies.xfce.org to docs.xfce.org (Xfce #16173)
MPRIS Enhancements
- Support for filename icons (Xfce #14329)
- Support for single-string variants on xesam:artist
- Support for the DesktopEntry property (Xfce #14412)
- Support for the plasma-browser-integration plugin (Xfce #15487)
- Detection of artist and title from the track title
Preferences
- Fixed icon rendering for known players
Translation Updates
Albanian, Belarusian, Chinese (Taiwan), Galician, Interlingue, Slovenian
Plasma/Browser Integration
Plasma/Browser Integration is an extension for Firefox and Chromium-based browsers that better integrates those browsers with the Plasma Shell. It enables the following functionality for Plasma desktops:
- MPRIS2 media controls
- Sending links via KDE Connect
- Showing and controlling downloads from the notification area
- Finding browser tabs in the Run Command window
Thankfully, this extension does not require Plasma to run! With just a few adjustments to the Xfce PulseAudio Plugin, Xfce users can now also utilize the MPRIS2 media controls and link sharing.
How to Install
Instructions adapted and simplified from the KDE Community website. Check this link if these instructions no longer work.
The extension requires two components: the browser extension and the native host. Once both are installed and correctly configured, active streams should appear in the Xfce PulseAudio Plugin menu.
Browser Extension
Install the plugin appropriate for your browser. Most Chromium-based plugins support extensions installed from the Chrome Web Store.
- Chromium-based browsers including (but not limited to) Google Chrome, Chromium, Brave, and Vivaldi: Chrome Web Store
- Mozilla Firefox: Firefox Add-Ons
Native Host
Most distributions should now include a plasma-desktop-integration package in their repositories. Find yours here at Repology. If you’re using Ubuntu or a derivative, installing the native host is as easy as:
sudo apt update
sudo apt install plasma-browser-integration
Once both components are installed, the extension should start working!
Downloads
$ md5sum xfce4-pulseaudio-plugin-0.4.3.tar.bz2 3d86032acb9364d47e0a144350c63e1a
$ sha1sum xfce4-pulseaudio-plugin-0.4.3.tar.bz2
5682fa1ed6976e94fa01c91fc5b7839bfe804241
$ sha256sum xfce4-pulseaudio-plugin-0.4.3.tar.bz2
5a518237e2137341d8ca6584938950525e20c28a0177e30ecaea3ba8e7a2615b
Xfce PulseAudio Plugin 0.4.3 is included in Xubuntu 20.04 “Focal Fossa,” which will be available in April. Users testing the daily images should be able to check it out now.
Xfce PulseAudio Plugin 0.4.3 Released
Xfce PulseAudio Plugin 0.4.3 has arrived! It includes improved MPRIS compatibility and support for the Plasma Browser Integration plugin.
The post Xfce PulseAudio Plugin 0.4.3 Released appeared first on Sean Davis.
Xfce 4.14 Maintenance and 4.15 Updates
Xfce 4.14 Maintenance
As promised we’re trying to be much better at doing maintenance releases for Xfce 4.14. In part, we had a hard time doing maintenance for Xfce 4.12 because with all the porting work it was hard to focus on fixing Gtk+2 bugs and many bugreports/fixes didn’t apply to both 4.12 and 4.14.
This has now changed and as many bugs apply to both Xfce 4.14 and the current 4.15 development versions we can much more easily backport fixes. Consequently we have already done quite a few maintenance releases so far and this week a few more followed, fixing bugs and featuring improved translations:
- xfce4-panel 4.14.3 (4.14.2 had a bad release build)
- xfce4-session 4.14.1
- xfce4-settings 4.14.2
- xfdesktop 4.14.2
Xfce 4.15 Updates
One of the major UI changes that we announced for the 4.16 cycle was the switch to GtkHeaderBars or so-called Client-side decorations (CSD). The first big step in this direction has now happened in libxfce4ui, our main user interface library. With the change, almost all dialogs will be converted to using CSD by default without any code changes in existing projects.
There are quite a few advantages we’re looking forward to (improved resize areas, consistent theming etc) by making use of this core Gtk feature.
A few more features that got released (in the xfce4-panel 4.15.1, libxfce4ui 4.15.1, libxfce4util 4.15.0 and xfce4-settings 4.15.0):
- an improved “About Xfce” dialog that features basics of the system properties
- improvements to the “Display” dialog (show Aspect Ratio, show Preferred Mode)
- only show Gtk themes that support Gtk3 in the “Appearance” dialog
- function for improved application icon lookup (used in Xfce Session’s settings dialog and in the Xfce Panel’s systray settings for now)
- the panel’ dark mode got enabled by default (which means it will look nicer with Adwaita e.g. on Fedora by default)
- the Directory Menu plugin now allows you to directly create Folders and Files
- we also bumped the overall Xfce version to 4.15 so people testing 4.15 packages should see the right version in e.g. the “About Xfce” dialog.
Enjoy! 
(and don’t forget to write bug reports 
)
Some Screenshots
Technical background: XfceTitledDialog with CSD
(This subsection is targeted at developers.)
Some components (namely Thunar, Thunar volman, xfce4-panel, xfce4-settings, xfburn and xfce4-mixer) inherit the XfceTitledDialogClass explicitly when creating their dialog object have to be fixed by using the new API introduced in the upcoming release libxfce4ui-4.15.1.
All other dialogs should work out of the box and not require any additional meddling.
- xfce_titled_dialog_create_action_area (to initialize the custom action area)
- xfce_titled_dialog_add_button (as an equivalent to gtk_dialog_add_button)
- xfce_titled_dialog_add_action_widget (as an equivalent to gtk_dialog_add_action_widget)
- xfce_titled_dialog_set_default_response (as an equivalent to gtk_dialog_set_default_response)
The point of the new API is packing the dialog’s action buttons in the action area at the bottom of the dialog (vs. the standard GtkDialog behavior of packing them in the GtkHeaderBar as part of the window decorations). This means that dialogs remain in their previous/traditional layout with minimal effort on the developer’s/maintainer’s side, in part because the parameters were kept the same as in their upstream GtkDialog counterparts.
Here is a (very simple) example commit of how to port existing dialogs that use XfceTitledDialogClass:
https://git.xfce.org/xfce/xfce4-panel/commit/?id=35440ee2d9540a3c1afdcbff5f50dc0ee2f83d9b
Catfish 1.4.12 Released
Welcome to 2020! Let’s ring in the new year with a brand new Catfish release.
What’s New
Wayland Support
Catfish 1.4.12 adds support for running on Wayland. Before now, there were some X-specific dependencies related to handling display sizes. These have now been resolved, and Catfish should run smoothly and consistently everywhere.
Dialog Improvements
All dialogs now utilize client-side decorations (CSD) and are modal. The main window will continue to respect the window layout setting introduced in the 1.4.10 release.
I also applied several fixes to the new Preferences and Search Index dialogs, so they should behave more consistently and work well with keyboard navigation.
The new dialogs are more streamlined and standardized.
Release Process Updates
I’ve improved the release process to make it easier for maintainers and to ensure builds are free of temporary files. This helps ensure a faster delivery to package maintainers and, therefore, to distributions.
Translation Updates
Albanian, Catalan, Chinese (China), Chinese (Taiwan), Czech, Danish, Dutch, French, Galician, German, Italian, Japanese, Norwegian Bokmål, Russian, Serbian, Spanish, Turkish
Downloads
$ md5sum catfish-1.4.12.tar.bz2
9aad6a0bc695ec8793d4294880974cb2
$ sha1sum catfish-1.4.12.tar.bz2
4e78e291a2f17c85122a85049bdc837b49afdd66
$ sha256sum catfish-1.4.12.tar.bz2
c3fb30e02b217752aa493b49769be1a5fc2adde70b22aef381e6c67d5227134a
Catfish 1.4.12 will be included in Xubuntu 20.04 “Focal Fossa”, available in April.