Category: News

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.

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.

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

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!

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!

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 only 2 months of work I was today ready to release xfce4-notifyd 0.4.1 (thanks in part to Viktor’s fix for make distcheck) with a bunch of fixes and some small features too (and of course lots of translation updates).

Features

The panel plugin that was introduced in 0.4.0 received some attention, gaining a new hidden option (log-icon-size) for users to set the icon-size for the notifications that are displayed in the menu. Furthermore I added a “Clear log” button and finally decided to revamp the layout of the menu a little, inspired by some work of the elementary folks. Now the “Do not disturb” item is on top (or bottom, depending on your panel layout) of the list for easy and quick/er access and sports a GtkSwitch because the GtkCheckMenuItem was not visible enough.
To top off the changes to the plugin I added a placeholder text in case the log has been cleared or there are no notifications to display (e.g. if the “only notifications from today” filter is set but the log only contains entries from yesterday and before).

Furthermore spent some more time on the notification window layout and it should be very consistent now, so equal spacing between the icon, subject, body, buttons and the edge of the bubble.

Finally I added a configure option to use autostart instead of dbus (Bug #13989), which is a feature some distros (like Mageia) have done already via downstream patches so far and which helps if people have multiple DEs and therefore notification services installed in parallel.

Bugfixes

Regarding bugfixes there are also a few notable mentions. With the help of several contributors the following issues were tackled:

• Ensure body and summary of notifications are correctly ellipsized (Bug #12674)
• Fix warning about gdk_window_get_origin (Bug #13935)
• Ensure the panel plugin icon resizes with Xfce 4.12
• Treat icon_data only as pen-ultimate fallback option (Bug #13950)
• Remove deprecated functions (Gtk+ 3.22)
• Fix warnings reported by Clang (Bug #13931)

Download

So get it while it’s hot here: http://archive.xfce.org/src/apps/xfce4-notifyd/0.4/xfce4-notifyd-0.4.1.tar.bz2

After quite some development time I have decided to push out xfce4-notifyd 0.4.0 today. This is not just a bugfix, but a feature-packed release.

Panel plugin

Among the biggest changes there is a panel plugin which displays the most recent notifications as well as allowing for quick access to the do-not-disturb mode. It also serves as a status indicator for the do-not-disturb mode, so you can easily see whether notifications are shown or hidden overall.

Improved logging

I’ve also spent some time on improving the notification image handling in the log. While handling icon-names is easy (just save them as string) handling the pixbufs was a little more challenging. I decided to do it the Git way and deduplicate these pixbufs based on their (unique) hashes, so that each picture would only be saved once. All of those pictures end up in a sub-directory of the log (which by default is ~/.cache/xfce4/notifyd/icons). Currently there is no monitoring of how much space these images consume and no button to clear them away, maybe I’ll add that later if people feel it would be useful/necessary. After using this feature for several months I have accumulated less than 7MB.
The log also received some more love in terms of markup support and character escaping. Multi-line notifications should now be correctly logged.

New animation: slide-out

Just for the fun of it I also worked out a new animation optional addon to the standard fade-out. I called it slide-out and it’s a fairly wide-spread animation mix of fade-out and sliding the bubble (depending on its location on the screen of course) off-screen.

New logo

As this turned out to be a bigger release I went for a bigger version jump and also included the new logo I had been working on for a while. I evaluated several “notification” metaphors and went for the ‘ol bell (notification bubbles felt a little odd and not easy to depict, as they look usually very diverse).

Bugfixes

Some people may be happy to know that I dropped the feature that let xfce4-notifyd exit after 10 minutes of inactivity. I can only guess but I presume this was implemented to save resources. Nowadays it feels more annoying if a daemon has to be restarted and the first notification that’s that split-second longer to appear.

A few more tweaks have been done to the geometry of the notification bubble windows to not take more space than needed and distribute things evenly (no more strange margins) and the configuration dialog now shows a warning if xfce4-notifyd is not detected as running.

Download

As always, you can download and build/install the tarball or wait for your favorite distribution to package and ship it to you.

https://git.xfce.org/apps/xfce4-notifyd/snapshot/xfce4-notifyd-0.4.0.tar.bz2

After a looong waiting time – the original port of the panel was first kicked off in March 2013 by Nick – the first development release of the xfce4-panel is out and I am happy to say it is usable! 🙂 There are however some regressions and of course a lot of potential bugs that simply haven’t been uncovered because of the limited usage and testing so far (I guess I haven’t gone through all possible kinds of panel setups).

General functionality and features

I know this is very boring, but the Gtk+3 version of the panel is on par with 4.12.1. Most of the functionality is there (see regressions and known issues), but no dramatic new features were introduced (apart from what the Gtk+3 toolkit brings to the table itself).

One notable feature that people have also been requesting for a while – in fact yours truly originally reported the bug – is support for RandR’s “primary monitor” feature. This means the panel will not stay on the left-most monitor by default but jump to the monitor that you define as “primary” in xfce4-settings Display dialogue.

Known issues and regressions

• Not all panel settings may be kept as the configuration is not 100% backward compatible (e.g. we’re using GdkRGBA instead of GdkColor for the background)
• Moving panel plugins via drag and drop on the panel directly via the plugins context menu action “Move” is currently broken (works fine in preferences dialog)
• Small regression with intelligent hiding (when opening a menu, the panel hides and comes back immediately while it should just remain visible)
• Enter/leave opacity does not work for Gtk2 plugins
• The panel is not visually focused by default (fixed in Xfwm4>=4.12.4)

There is also one deprecation that is worth mentioning. While the panel relied on xfce_panel_image in Gtk+2 (i.e. pixbuf drawing and scaling) we decided to deprecate this approach in favor of using the toolkit’s features directly (which is now possible more efficiently with Gtk+3). The newly added xfce_panel_plugin_get_icon_size relies on GtkImage directly and which introduces defined, meaningful icon size-steps to avoid fuzzy icons in the panel.

Theming

I have already added some basic theming for the panel to Greybird and I hope this will help others. I’ve also noticed that the GtkCalendar widget in Gtk+3 is visually broken (actually also codewise really terrible, and likely therefore unmaintained) and made some effort to improve that in Greybird.

What’s next?

Well, there are still a lot of things to do. The top two of the todo list for the panel are of course fixing all known and not yet reported bugs as well as cleaning up more deprecations (currently your terminal’s backlog is filled with warnings when running make, which makes it hard to distinguish the meaningful from the meaningless information).

How can you help?

Do some testing, either by using something like VirtualBox or xfce-test or use a distribution that is brave enough to package the panel (I presume we will see it in some Ubuntu PPA in the near future). Set the panel up your way and just use it and hopefully we will manage to cover all existing use-cases and have them working in 4.14 as well.

Please report bugs against the 4.13.0 version of the panel so that we can get a clean todo list for the next development release!

Thanks to everyone involved!

Finally let me give a big shout-out to everyone involved in the port – more people than I could meaningfully mention here.

The translators, everybody who reported bugs or did testing so far and of course the developers who invested a lot of their free time and energy in this enterprise.