Xfce 4.16 development phase starting

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

https://wiki.xfce.org/_media/releng/4.16/roadmap/general_ui/panel-dark-csd.png

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 released! (Yeah, like a week ago ;))

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!

Xfce 4.14pre3 released!

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…

Xfce 4.14pre2 released!

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.

xfce-panel’s grouped window indicators

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!

Xfce 4.14pre1 released!

Good news everyone, finally the first pre-release of the long-awaited Xfce4.14 is here! \o/

Some highlights

Note: A lot has happened since Xfce 4.12 was released four years ago and this announcement only covers the changes that were included in the latest development releases dubbed as Xfce 4.14pre1. Also, we have noticed some confusion by people or news outlets that seem to mistake xfdesktop for the “Xfce Desktop Environment”¹.
The comprehensive changelog will be provided with the Xfce 4.14 final release, but here go some select highlights that were released in the last week (chosen subjectively by the author).

xfce4-session
Most notably the so-called FailSafeSession (which is the default session for every user that doesn’t specifically save a session) has been fixed to use startup priority groups. Previously xfce4-session started all applications at once, leading to all kinds of race conditions (unthemed xfce4-panel, multiple instances of nm-applet etc.). Now xfce4-session launches only all applications per priority group at once, leading to a much more controlled session start.
Several UI improvements have also landed as well as allowing users to trigger scripts on logout, restart, suspend etc.
Finally it’s worth mentioning that we decided to drop the splash screens.

xfwm4
Lots of improvements to vertical blanking support have been added, including a switch to GLX as default method. Furthermore the support of Gtk+3’s window scaling feature – aka HiDPI support – has received many fixes.
Also, lots of other bugfixes (and a new default theme).

xfce4-settings
A new colord frontend has been added to xfce4-settings, meaning you can now manage the color profiles you created. Furthermore the display profile functionality has been improved and expanded, ensuring a more flicker- and frickle-free experience when changing display setups frequently.

xfce4-panel
Most notably a bug with (semi-)transparent background images was fixed.

Other components
Many of the other components have seen mostly bugfix releases, but in any case, we have to keep some stuff for the final announcement of Xfce 4.14, right? 🙂

Each of the core components (aka everything listed in the xfce group here) has very recently had a release that has been tagged as xfce-4.14pre1 (in addition to the normal release tag). As an example, for xfwm4 4.14pre1 corresponds to xfwm4-4.13.2.
These additional tags shall help packagers who want to provide a testing environment with a quick and reliable way to get all core components in the correct versions. The full version table is available here (with hyperlinks to the respective git tags).

Where can you get it?

It’s probably worth mentioning that several major Linux distributions (Fedora, Xubuntu etc) have already decided to ship Xfce 4.13 components, so you can expect to find a lot of Xfce 4.14pre1 in their next releases. (For Xubuntu specifically the packages will show up in the experimental staging PPA also for the current stable release 19.04.)

We will soon also provide a docker container (aka xfce-test) thanks to Florian with Xfce 4.14pre1 inside for all of those of you who want to play around and test without compromising their main systems. So stay tuned for ubuntu_19.04-xfce-4.14pre1 to show up on dockerhub

Please take these latest releases for a spin and report bugs!
Also, submit patches if you can or support us morally 🙂
(Or through bountysource.)

Next steps

Our next very obvious step is Xfce 4.14pre2, which is scheduled for June 30, and after that the – optional, depending on overall stability – Xfce4.14pre3. Feel free to check out our roadmap page for more detailed infos!
(Also, if you’re wondering what the pre-releases mean feel free to take a peek into our release model.)

 


¹ The Xfce Desktop Environment is a collection of components of which xfdesktop is one. Xfdesktop is the ‘desktop manager’ and as such mostly responsible for setting a background image (“wallpaper”) or color and drawing icons on the desktop.

Color profile support for Xfce

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
Xfce4 Color Profiles

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.

New xfce4-panel development release

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.

Preferences Dialog with the new icon option
32px panel with 16px plugin icons

 

 

 

 

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

Adventures in primary display land

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.

Display Settings Primary information

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!

New xfce4-settings release

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!

New releases for xfce4-panel and xfce4-power-manager

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.