xfce4-power-manager 1.6.1

After almost two years I finally managed to get around to release a new version of the power manager, including many bugfixes that have accumulated over this time over the original Gtk+3/GDBus port that is 1.6.0.

Users will mostly notice the improved support for Desktop systems (they used to have the “battery-missing” icon displayed in the panel plugin – a regression over 1.4.x, which handled desktops more gracefully). Those who also use xfce4-notifyd’s recent logging mechanism will notice that now not every power manager event (e.g. changing the brightness) ends up in the log, as many notifications are marked as transient.

xfce4-panel 4.12.2 and 4.13.2

Both the stable 4.12 series and the 4.13 development series saw releases of late.

4.12.2

4.12 saw a small feature release adding support for the much and often requested “primary monitor” feature of RandR. So when you now define a panel’s location as “Output: Primary” it will dynamically move to the monitor marked as “primary” through the xfce4-display-settings dialog.

The default value “Automatic” for the Output option remains, so users will not notice any invasive changes here. Also the behavior of this default option remains unchanged (usually pushing the panel to the left-most monitor – aka x=0/y=0 – by default).

4.13.2

4.13 also saw a release, introducing GObject Introspection support, which should enable people to write Panel plugins in different languages (e.g. Python). We still need a template for that (volunteers forward!) so people can get their hands dirty more easily, but I think this is a very nice addition.

Apart from this I fixed a lot of smaller and bigger issues in the panel’s core plugins (actions, clock, launcher, tasklist and systray) and the settings dialog can now again be plugged into the xfce4-settings-manager dialog.

After quite a bit of development time I’m happy to announce the next development point release of xfce4-settings in the 4.13 series.

There are many fixes in this release – most visibly also UI improvements. This includes consistent padding/margin etc across all dialogs as well as a restored hover-effect in the Settings Manager. Finally both the advanced (fake panel as indicator for primary displays, re-arranged settings and distinct advanced tab) and the minimal display dialog (new icons, improved strings) received a facelift.

But – despite the nature of the 4.14 cycle – there is also a new feature:
display profiles.

This new feature allows you to store one or more profiles for a particular display configuration that you may be using. In order to uniquely identify single displays we rely on the so-called EDID (Extended Display Identification Data) so a profile becomes a combination of those unique EDIDs. As already mentioned, you can store multiple profiles per setup to cover use-cases like rotating single screens or when enabling/disabling or re-arranging certain screens may be necessary. For instance in office situations where you switch a lot between one or multiple docking stations, projectors and other external devices, this feature will allow you to do so with ease.
Every scenario just has to be configured and saved once.

It is important to note that the list of available profiles is always filtered based on the currently connected displays. To be exact: this means that at least the currently connected displays need to be part of the profile definition for the profile to appear in the list. In turn this also means that if you only have your internal laptop display connected, you will see all profiles because your laptop display will always be part of every profile (even if it is disabled!).

To make the deal a little sweeter I implemented auto-applying of profiles when new displays are connected. This is an optional feature that automatically enables the first – if there are multiple defined for the set of currently connected displays – matching profile.
This action is also triggered if you open the minimal dialog, giving you a shortcut to auto-apply profiles. 

What is not yet implemented is profile-awareness for xfsettingsd. So the settings daemon does not automatically enable a profile if you simply start your session, but previously worked in a different display setup. However, this is a point I would like to address in a future release.

In the meantime, enjoy xfce4-settings 4.13.5!

As some may have noticed I have lately patched “Primary Display” support into a few of our components. It all started with the display settings dialog… But let me start right at the beginning.

“Primary” is a setting of X11’s RandR extension that “is expected to be used by desktop environments to mark the screen that should hold the primary menu bar or panel” (quoted from the specification). So in short: the “Primary Display” should hold your panels, your desktop icons, your notifications, potentially your presenter’s screen (if you use LibreOffice) etc. in a multi-display setup.

In 2016 I started by introducing a hidden setting in xfce4-notifyd. This meant your notifications wouldn’t pop up during presentations on external displays anymore (because the default setting before was to follow the mouse pointer’s location). I personally needed/wanted this and it felt like an easy fix.

In 2017 I added the feature to xfce4-panel. Before that you had to either hard-code the location of the panels or use the “Automatic” setting, which always puts your panels at the left top part of the screen (x=0, y=0). In combination with the display settings option this provided an easy way of moving the panel around and keeping it on certain displays even when connecting new additional ones.

In late 2018 I started working on the big missing piece of the puzzle, which is xfdesktop. At the time of writing, my patches are still in review in this bugreport (testing welcome!), but things work ok or at least well enough to give me hope that we will see this in the next development release.

In parallel to the xfdesktop patch I also picked up the display settings dialog again after gathering some input from friends at work and decided to pull in all the information about the usage and configuration of the “Primary Display”, as its settings are spread across several components and dialogs. The point of this popover is to show the current configuration status as well as adding a shorthand for accessing all those settings dialogs.

I also went with a new way of highlighting which display is configured as “Primary Display” that is hopefully more easily understandable than the panel I added in the 4.13.5 release. The star is shown both in the displays widget as well as in the properties list of each display, so users can easily visually match which display is primary and what that means.

Enjoy!

What better way to start a new year than with a release?

xfce4-panel 4.13.4

After patching up xfce4-settings and finishing the “primary display” story with the patches against xfdesktop I decided to turn to the panel and continue making it 4.14-ready. Next stop: xfce4-panel 4.13.4.

New plugin icon size feature (plugin devs continue reading)

A few things had bugged me there for a while, for one the lack of consistent icon sizing. What the new “icon size” property I implemented gives you is a way to set one icon size per panel instance, so you can have e.g. a 60px panel with 48px icons, or a 32px panel with 16px icons (which gives the icons more padding/breathing room visually). If you set icon sizing to “automatic” (the default value) the panel will try to calculate meaningful sizes for your icons based on the panel size, as before.

So while the panel’s API call xfce_panel_plugin_get_icon_size has been around for a while in the 4.13 cycle, I extended this now to also handle fixed sizes set by the user per panel instance.
I highly encourage every plugin developer/maintainer to use the API call mentioned above in their panel instead of custom size calculations, as it will lead to consistent sizing of all panel plugins per panel.
You can find examples of its usage here (panel core plugin) and here (external plugin).
The logic is always the same:
1) Connect to the size-changed signal
2) Get the icon size with xfce_panel_plugin_get_icon_size
3) Set the plugin’s icon with gtk_image_set_pixel_size

Correct menu positioning (again, plugin devs please read)

Luckily I’m not the only one currently hacking away on the panel. So another thing Alistair was fixing is the menu positioning on the panel’s core plugins. This is however a fix that all plugin developers/maintainers should pull in against their plugin. It leads to consistent positioning of the plugin menus in general and in overflow situations. You can find a good example for the correct usage of gtk_menu_popup_at_widget (which is used for showing plugin and other menus) here.

Tasklist fixes

After deciding to use the panel’s “Window Buttons” (aka “tasklist”) plugin more to test its stability I managed to fix a few bugs in window grouping. For instance the buttons of grouped windows now support the “active”, “minimized” and “urgent/blinking” states and are consequently more consistent with ungrouped buttons.
I also dug a little into libwnck – which we rely on for the app icons and the grouping in tasklist – and was able to get us high resolution application icons. While it worked fine for a single panel instance or for multiple tasklist instances with the same icon sizes, adding multiple tasklist plugins with different icon sizes led libwnck into a signal loop. Due to this unfortunate bug (or: mis-implementation) I had to revert this commit/feature. Ultimately the issue has to be resolved in libwnck – or alternatively we may come up with a separate tasklist-based plugin that relies on bamf instead of libwnck (future plan).

Small theming updates

Apart from the things mentioned above, I have also introduced some new CSS style classes which can be used by themes/themers.

To be more concrete, for orientation-specific theming (e.g. margins or paddings) you can now use .xfce4-panel.horizontal and .xfce4-panel.vertical.
For the tasklist I have introduced a group-buttons class which you can use to visually distinguish single-window buttons from group-buttons. This is useful as the behavior of those two buttons is different (group buttons pop up a menu with all associated windows, single-window buttons focus the window in question).

Lots of deprecation, bug fixes and translation updates

Finally, we also managed to fix a lot of bugs and deprecations in the code (thanks Alistair!).

Get it while it’s hot!
https://git.xfce.org/xfce/xfce4-panel/tag/?h=xfce4-panel-4.13.4

This year I had the chance of joining the FOSDEM conference again and as always it was great to meet up with other FLOSS enthusiasts.
It was also a good chance to meet with some Xfce folks (Harald, Florian) and sponsors (Volkan) and finally it was a good time to hack on stuff. This year I sat down with Florian in the evenings and invested some time into colord integration.

About colord

colord is – in short – a system service that enables you to manage, install and generate color profiles to accurately color manage input (webcams, scanners) and output devices (displays, printers). colord itself comes only with a commandline tool (colormgr), which is not great in terms of discoverability and usability. Both Gnome and KDE have already integrated colord support into both their settings dialogs and settings daemons, but in Xfce there was no easy way to achieve a color-managed session.

Status of the integration into Xfce

In order to enable people to set up color management I decided to start with the frontend. In theory you can already get a working setup in Xfce by relying on cupsd (for printers), saned (for scanners) and xiccd (for displays) and handling colord through the colormgr commandline tool.

What we managed at FOSDEM was still pretty rough but I took a few days (read: nights) and polished the dialog so it became more and more user friendly and the final product can be seen in the screenshot above.

The dialog enables you to:

• Enable/disable color management per device
• Add or import color profiles per device
• Enable a profile and set it as default

What it doesn’t do:

• calibration – you still have to use e.g. displaycal to calibrate your display
• show detailed profile information (like a horseshoe color diagram), you still have to use e.g. gcm-viewer for that

“So, that’s great – what else is missing?” I hear you ask. That’s quite simple: In short, we need to integrate the backend for colord into xfsettingsd so we don’t have to rely on xiccd anymore. While it seems to run stable here for me it’s yet another daemon, so xfsettingsd integration would definitely be a plus.
The cool thing about the frontend is however that everyone can already use it for printers and scanners, because those are natively supported already.

“When can I have this?” may be your reasonable follow-up question. I’m still ironing out small kinks (not too many hopefully) and I still have quite a bit of code cleanup ahead of me, but my current plan is to get this feature merged before we release Xfce 4.14, so the likelihood of it showing up in the next (or subsequent) development release of xfce4-settings is high. It then still depends on your Linux distribution whether the colord integration is included, because it’s a compile-time option (not every user/distro may want having to pull in colord, as it’s yet another service that’s running all the time).
Finally I’m not sure I’ll have time for the backend part in the very near future, so we’ll have to see about that. Luckily the dialog is useful even as it is.

In the meantime you can support me through friendly words, posting a bug bounty on colord backend integration or you can do some testing and provide me with feedback through checking out my branch, currently hosted on GitHub.

Some highlights

Where can you get it?

Next steps

As scheduled, the team has released the second pre-release for Xfce 4.14, which is due later this summer, yesterday evening. As this release was mostly focused on bugfixing there are not that many highlights, but as with Xfce 4.14pre1 I’ll try to point out a few – as before, not completely unbiased.

Some highlights

xfce4-panel
Several bugs were fixed, most notably Bug #15044, which caused applications used with multi-touch devices to regress into single-touch.
A new visual indicator for grouped windows was introduced to the tasklist plugin and the default panel layout was refreshed, adding several plugins (if not installed/shipped, they will simply be automatically and silently removed from the panel on its first run).
Furthermore some usability tweaks were done (e.g. more mnemonics) and translations have been updated.

xfwm4
Several fixes and improvements to compositing (GLX backend), HiDPI and theming have made it into the latest release.

thunar
A bug where writable shares were wrongfully detected as read-only was fixed as well as some other, less critical bugs.

xfce4-settings
Several regressions and bugs were fixed in the color dialog, the display dialog (the display settings were not retained across sessions) and the settings manager.

xfdesktop
The new “Add Next Background” option was added as well as several fixes around interactivity (drag-and-drop, open items on keypress) and theming.

xfconf
The settings backend of Xfce gained support for GObject introspection and vala.

Testing

If you want to get a taste of Xfce 4.14 pre2 without compromising your main system you can grab the Docker container of xfce-test that we tagged today as ubuntu_19.04-xfce-4.14pre2 with all the components in their up-to-date versions from dockerhub. If you haven’t used xfce-test before I heavily recommend reading its helpful Readme.

Furthermore, several distributions have already commenced on packaging (Xubuntu, Fedora, Manjaro, OpenBSD etc) so we hope to get even more testing and feedback until the final release of Xfce 4.14.

Next steps

The next release – aka pre3 – is optional, so we may decide to skip it and go straight for the final release if the release team is confident that there are no showstoppers.
Until then enjoy Xfce 4.14pre2!

The final pre-release before Xfce 4.14 stable is out since two days ago so here goes a quick look at the most notable bugfixes. While this release was optional, we decided to give ourselves a little more time for bugfixes and translation updates to flow in, which results in sticking to the original plan of releasing 4.14 in mid-August.
That said, many components only received translation updates, which hopefully means there are no more bugs to fix in them

Some highlights

xfce4-session
We worked again towards the reducing of race conditions between xfsettingsd (which applies all kinds of X and Gtk related settings like font, theme, display layout)  and other Xfce components that rely on these settings (like xfwm4 or the xfce4-panel).

xfmw4
Various fixes related to compositing found their way into the release as well as improvements to looking for fallback window icons, especially helping with e.g. Electron-based applications.
Another fix in this release concerned the placement of new windows, which are now defaulting to the current display (i.e. the one with the mouse cursor).

Thunar
A fix for mounting external drives was part of this release (sometimes they were erroneously mounted with root privileges) as well as a bug that caused Thunar to use 100% CPU when the parent directory wasn’t readable.
Finally some usability improvements were added (right-click drag and drop, additional zoom accelerators, keyboard shortcuts for switching tabs).

xfce4-panel
Various bugfixes, most of them affecting plugins (tasklist fixes for the new group indicator, directory-menu, clock). As with Xfwm4, we also improved the fallback lookup for window icons for the panel.
Considered disabling Gtk+2 support by default but then reverted because of problems with building docs. In general support for Gtk+2 plugins will remain as part of the final 4.14 release of the panel and will only be removed in the 4.16 cycle.

xfce4-power-manager
Support for xfce4-screensaver was added in this release. Furthermore the power manager now checks if the panel plugin is present and automatically hides the systray item in this case. This is especially interesting for distributions like Fedora that ship a vanilla Xfce and would end up with both the systray item (which is enabled by default in the power manager to always have a fallback for the user) and the panel plugin (which got added to the new default panel layout). Finally screen-dimming and the inactivity-action (e.g. suspend on inactivity) now get inhibited by video playback in players that support this (e.g. a YouTube video in Chromium). A patch for parole for this feature is already in review.

What’s next?

Well we’re currently ironing out the (hopefully) last quirks and bugs that we find – some of them may actually result in a bit of work for translators.

Furthermore we have finally branched off the 4.12 documentation on docs.xfce.org and started to update and extend it for 4.14. As an example, we have added a WIP page about the newly added color dialog of xfce4-settings.

Only two more weeks until the final release…

So finally – here goes the official post for the Xfce 4.14 release…

Why is the release manager late to the party with his blog post? The explanation is simple: We prioritized sticking to the schedule and getting our releases out to everyone as planned, as our codebase was ready. What was not (entirely) ready was some parts of the website, which were brought up-to-date over the course of last week.

So I’m pleased to give you the official Xfce 4.14 tour, which nicely summarizes many of the nice user-facing changes that we pushed into the release (despite it being planned as feature-less, porting-only).

We’re also working on other aspects of our website, like the screenshot reel on the frontpage, which is mostly up-to-date now, and the screenshots section. If you have more screenshots that you think we – and everyone else – should see, please get in touch via IRC (join #xfce on freenode) or the mailing list and if we like it too, we’ll gladly add it!

What’s next?

Well, obviously Xfce 4.16, for which the planning phase just started. We want to certainly stick closer to our release model (which prescribes a 6-month release cycle) this time and go for roughly a year to get to our next stable release. To some extent the schedule will depend on the outcome of the planning phase, but one thing I’m pretty sure I can announce straight away is that we’re not going for the next technological jump (yet) – so don’t expect Wayland or Gtk4 to play a major part in the coming cycle.

However, what we will need to do is some house-keeping and improving things for ourselves and potential contributors. We are strongly considering to follow freedesktop.org and Gnome in terms of switching to Gitlab (for Git and issues at first). They have done a tremendous job and as someone who recently contributed to one of the Gnome libraries I can say the bar is so much lower than what we currently have with Xfce (read: create bugzilla account, report bug, attach patch, wait patiently…).

In any case, enjoy Xfce 4.14 and join us to make 4.16 a great (and shorter) cycle!

As promised we’ll try to stick to a tighter schedule this time, so without further ado: the development phase towards Xfce 4.16 has officially started!

This means that we have a list of features we will try to work on (that is not guaranteed though) and that is detailed on our roadmap page and its subpages. I’ll try to summarize and highlight some (obviously with a focus on the stuff I know better because I’m more involved) of it for you here.

Dependency Update

Let’s start with one very important and obvious change: we will drop Gtk2 support with Xfce 4.16. This will have a concrete effect on old Panel plugins or Gtk2 applications that rely on libxfce4ui.

Xfce 4.16 will introduce a new dependency on libgtop to display information about the system (in the “About” dialog). We hope this will also have a positive side-effect on e.g. Panel plugins to standardize on this library.

General UI

In the 4.14 cycle we tried to do a 1:1 port of what used to be our Gtk2 desktop environment, avoiding visual changes. In the 4.16 cycle we plan to harmonize the appearance of certain elements that either became inconsistent through the port or already were inconsistent before (e.g. toolbars or inline toolbars).

We will also play with client-side decorations where we feel it makes sense (for instance replacing the so-called XfceTitledDialog, that is used for all settings dialogs with a HeaderBar version). Before anyone gets too excited (both positively or negatively): It is not planned to redesign more complex applications (like Thunar) with Headerbars in 4.16. We will however try to keep the experience and looks consistent, which means gradually moving to client side decorations also with our applications (please note that client side decorations are not the same as HeaderBars!). Through this change e.g. “dark modes” in applications will look good (see the part about the Panel below).

Now before there is a shitstorm about this change I would kindly ask everyone to give us time to figure out what exactly we want to change in this cycle. Also, switching to client-side decorations alone is not a big visual departure – feel free to also dig through the client-side decorations page if you want to read/see more on this.

Thunar

As mentioned before: no big redesign. But lots and lots of smaller improvements and goodies are planned to up the user experience of the file manager you love!

This includes extending the API for plugins, installing some Thunar actions by default and storing view settings per directory.

Panel

Some of the building blocks of what shall be done for the panel is already underway, so I can show off some screenshots in this section (shameless self-advertisement).

As dark modes are all the rage everywhere and it really makes sense for the panel to have one, here it goes. Now you can easily get a dark panel – even with bright themes like Adwaita! With having client side decorations, the window borders of the preferences dialog will also look consistent with the rest of the dialog (remember that Xfwm4 doesn’t – and won’t – support the dark Gtk variant).

The panel’s autohide modes received a “slide out” animation, so it’s more intuitive to understand where the panel went. (We may tweak this feature further or even make it optional, but for the time being it’s there by default.)

The launcher plugin will receive a feature from garcon, i.e. showing the Desktop Actions of a launcher item in its right-click menu (i.e. “Open Private Window” for Firefox). This is really just a feature preview though, the code is in working but very hacky/rough state.

Some other core plugins (workspace switcher, tasklist) will also receive tweaks and improvements.

Settings

Especially the display settings shall receive more attention, introducing support for scaled mirror mode (helpful if not all displays share a reasonable resolution) and more.

We may also include our own daemon to talk to colord directly to eradicate the need for xiccd.

Power Manager

“Night light” (as in: a timed function that applies a colorfilter to your display to reduce strain on the eyes) will likely be added to the power manager. (Although if we figure out it’s easier to implement in the settings daemon it may be moved there.) Also some improvements to the panel plugin are planned as well as including a battery histogram in the settings dialog to visualize battery drain.

For all other components only smaller changes are planned.

Let’s get on with it

As mentioned before this cycle is intended to be more lightweight to enable us to “stick to the plan” and get a release to our user base sooner than with the previous two releases. Also keep in mind that we want to renew some of our infrastructure, which will also take away some time.

So now let’s get the 4.15 releases going!

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

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!

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 Jason we managed to get a Docker container xfce-build up and running that we now use for a (for now: very basic) test, aka “does it build?”. 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!

TL;DR

1. No more Xfce bugs on Bountysource.com (no support for GitLab)
2. All remaining bug bounties returned to original backers
3. 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).

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…

After we successfully released Xfce 4.16 as an early Christmas gift to all users last year I personally fell into the typical “post release fatigue” (PRF). On the one hand I was exhausted, on the other hand that’s how far our plans had taken us so there were no clear next steps we had settled on (apart from taking a break and recharging :)).

So what’s been going on since then…

Xfce 4.16 maintenance

First of all, we’ve done quite a few maintenance release of 4.16 to ensure it’s stability. We already provided lots of bugfix releases of 4.14 – some even very recently (Desktop, Appfinder) – but it looks like 4.16 may end up being (at least: among) the best maintained Xfce release so far.

Thunar is probably the active component with a 6th patch release being available already. Here goes an overview of all patch releases since 4.16.0 in December 2020:

• Thunar: 4.16.1, 4.16.2, 4.16.3, 4.16.4, 4.16.5, 4.16.6
• Panel: 4.16.1, 4.16.2
• Xfwm4: 4.16.1
• Garcon: 4.16.1
• Appfinder: 4.16.1

Developer documentation

In order to improve documentation for developers and make it more readily available we have started developer.xfce.org. For now this site hosts the API documentation of most relevant core components. This documentation is automatically kept up-to-date as part of our GitLab CI for the xfce/xfce-build Docker container and re-deployed on every week based on the latest 4.16 release tags.

Furthermore, we improved the shell-based helper scripts for developers, e.g. xfce-build (to locally run distcheck in the same Docker container used in our CI) with subcommands.

Task manager

I have fixed some bugs and done maintenance releases of the 1.4 series and started the 1.5 development series, which features a port of Task manager to Xfconf and Client-side decorations.

New icon naming scheme

As we changed the icon names for all Xfce components during the 4.16 cycle, I also migrated some plugins to the new naming scheme.

To briefly explain the rationale behind our change in 4.16: the previous names were highly inconsistent, overlapped with icons also used/shipped by other packages in distributions (so shipping our own icons with those “old” / “used” names would lead to unsolvable packaging conflicts). Especially the “standard” names like “preferences-desktop-*” would have been impossible to update and ship for us. In order to provide a consistent look and also to make it easier for icon theme maintainers to set up icons for Xfce we decided to follow the rDNS naming scheme for desktop files. The same naming scheme is already followed by Gnome, so it is fairly widespread in Gtk-based environments. Finally: previously no icon theme maintainer could even provide dedicated icons because the names overlapped and would also appear in other contexts or Desktop Environments.

Being an icon theme maintainer myself, I understood that this would lead to work for others. Sean even created a script to make it easier for everyone to update existing themes.

Plugin updates

I have taken a look at the three more prominent “monitoring plugins” of Xfce, namely CPU-graph, Systemload and Netload. I have created new icons for all three of them in a style consistent to the icons introduced in Xfce 4.16 and also ported Systemload to Xfconf.

I have also updated the Weather plugin quite a bit, adding a new icon, porting to Xfconf and improving the UX of the settings and forecast summary windows.

Finally some of the plugins mentioned above now implement the xfce_dialog_show_help API, which creates a “Help” button linking to the plugin’s documentation. This has been made possible by Kev, who ported the plugin documentation pages to docs.xfce.org and harmonized them, where possible. He also helped with adding more of these “Help” buttons and we’ll probably continue updating our plugins in parallel to the 4.18 cycle to make it easier for users to find the corresponding online documentation.

What’s next

The next step for me will likely be to focus on kickstarting the 4.18 cycle, which is still in its planning phase.