Simon's Secret

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.

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…

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).

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!

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 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

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! 🙂

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!

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…

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!