Xfce 4.14 Maintenance and 4.15 Updates

Xfce 4.14 Maintenance

As promised we’re trying to be much better at doing maintenance releases for Xfce 4.14. In part, we had a hard time doing maintenance for Xfce 4.12 because with all the porting work it was hard to focus on fixing Gtk+2 bugs and many bugreports/fixes didn’t apply to both 4.12 and 4.14.
This has now changed and as many bugs apply to both Xfce 4.14 and the current 4.15 development versions we can much more easily backport fixes. Consequently we have already done quite a few maintenance releases so far and this week a few more followed, fixing bugs and featuring improved translations:

  • xfce4-panel 4.14.3 (4.14.2 had a bad release build)
  • xfce4-session 4.14.1
  • xfce4-settings 4.14.2
  • xfdesktop 4.14.2

Xfce 4.15 Updates

One of the major UI changes that we announced for the 4.16 cycle was the switch to GtkHeaderBars or so-called Client-side decorations (CSD). The first big step in this direction has now happened in libxfce4ui, our main user interface library. With the change, almost all dialogs will be converted to using CSD by default without any code changes in existing projects.

There are quite a few advantages we’re looking forward to (improved resize areas, consistent theming etc) by making use of this core Gtk feature.

A few more features that got released (in the xfce4-panel 4.15.1, libxfce4ui 4.15.1, libxfce4util 4.15.0 and xfce4-settings 4.15.0):

  • an improved “About Xfce” dialog that features basics of the system properties
  • improvements to the “Display” dialog (show Aspect Ratio, show Preferred Mode)
  • only show Gtk themes that support Gtk3 in the “Appearance” dialog
  • function for improved application icon lookup (used in Xfce Session’s settings dialog and in the Xfce Panel’s systray settings for now)
  • the panel’ dark mode got enabled by default (which means it will look nicer with Adwaita e.g. on Fedora by default)
  • the Directory Menu plugin now allows you to directly create Folders and Files
  • we also bumped the overall Xfce version to 4.15 so people testing 4.15 packages should see the right version in e.g. the “About Xfce” dialog.

Enjoy! 🙂

(and don’t forget to write bug reports 😉 )

Some Screenshots

Appearance Settings (Adwaita)
Appearance Settings (Greybird)

 

 

 

New Settings Manager layout
New and shiny About dialog

 

 

Better app icons (Panel Systray)

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

47 thoughts on “Xfce 4.14 Maintenance and 4.15 Updates”

  1. I really dig the new dialog style, especially as I use XFCE mostly on my netbook so the vertical space gain compared to the older headers is really a plus for me (better handling of dark-style is also something that I’m looking forward, especially on panels)

    1. To add to this, I’m really desperate for the combination launcher/task manager option, ala / modern windows/mac/plasma/gnome. I hate having to load both a task manager and application launcher, it’s ugly and redundant 🙂

      1. Unfortunately this would imply some extra daemon like bamfd running (basically a huge cache of all .desktop files in the system), because there is no standard way to identify an application.

        Window grouping is also working a little heuristically, but while it sounds very similar, it’s based on window groups, which can be set by an application. Finding the original executable/app is much more trick and not just looking up a window property (at least on X11).

        In order not to rely on a daemon like bamfd we haven’t implemented anything like this in the core panel.

  2. Aww man. I like the current window bars and such, they’re pretty slim. I guess updating technologies is more important and has to be done at some point. It’s okay though, plenty of other things to like about XFCE! 🙂

  3. 1) So are Xfwm themes being abandoned?

    1a) If so, is that along with removing the options for action buttons supported by Xfwm?

    2) From an accessibility point of view, can you make sure that the window manager (independent of theme) allows a — preferably configurable, but if not more than a pixel or two — margin for the user to ‘grip’ the edge of window, so that users with limited mobility aren’t disadvantaged?

    Seems a retrograde Gnomification and at odds with Xfce’s development as a traditional/normal desktop environment, to be honest.

    1. I share your “fear” regarding the mentioned “Gnomification”.

      Xfce-developers shall be always aware what they signed up for:
      Producing the most stable and modular Desktop Environment for X11.

      It might seem like nostalgia when i say this, but it isn’t:
      The move of Debian to Gnome 3 has helped Gnome 3 only, not the other way around. Still Debian is THE most stable Distro for the Linux Kernel and there will never be an equivalent (for X11) to Xfce4, that actually does respect the same virtues and reaches out to steadily reinvent itself for the sake of stability, predictability and usability.

      There are many alternatives, from which only two can stand in a row to Xfce:
      Enlightenment (which should be seen as the becoming equivalent of Xfce for the Wayland-route of Evolution) and …
      FluxBox (which is officially “only” a WindowManager)

      For Debian i hope they can be brave and take a step back to the more-than-proven combination with Xfce as the most sane default. And Xfce-developers should find bravery as well, to stay on course with the given paradigm.

      It is a good “default” to perfection the given – because of the hard work of you Xfce-developers – solid-as-a-rock foundation, that it is for a time that can already been seen as leaping “eras” in computing and it will be if the “rules” are not only taken for granted, but kept alive.

      Xfce is one of the few projects people worldwide can “rely” on. Don’t give that up. Make it your concept, for all time.

    2. 1) No. Not every application will use CSD (look at Gimp, to name a prominent example).

      2) The resize area is much much bigger with CSD than without, because it spans the whole window shadow.

      1. 1) If Xfce’s own default applications ignore its native window manager’s themes or don’t support its action buttons, how long is that functionality realistically going to remain?

        2) Good to know. Would it be practical to give users a consistent experience that doesn’t depend on CSD/non-CSD or theme?

        As a minor point CSD windows appear to still have shadows when shadows are turned off on other windows.

        1. 1) I’m not sure I understand the question.

          2) Implementing a similar virtual resize area would be a lot of effort in Xfwm4, that’s why we never got it so far. With CSD we get it for free.

          1. 1) Xfwm4 features are being removed/de-supported from various Xfce core applications; how long before someone decides to remove those features (Xfwm themes, shade/stick icons) from Xfwm4 itself?

            It feels like it’s reached the point it’s time to stop using any Xfwm4-specific window buttons (I’m not anyway, never liked the “roll up” concept) and recreate any preferred Xfwm4 themes in Gtk3 (which’ll be a learning experience).

            2) That also makes it sound as if Xfwm4 is heading towards obsolescence, or at least parts of its feature set being divested.

          2. Drawing decorations is only a very small part of a window manager’s tasks. If you understand this, you’ll understand that Xfwm4 (and it’s features) will never be obsolete as long as we’re on X.

            Also, if you look at the screenshots, the action buttons are still at the bottom, not the headerbar (re: your Gnome comparison).

          3. Might be talking at cross-purposes. From the Xfce wiki documentation, “Xfwm4 can use up to six action buttons – stick (sticky windows), menu, shade, hide, maximize and close.”

            CSD windows don’t appear to support shading/rollup.

      2. I think GNOME Shell/mutter uses CSD to draw all window borders, basically drawing an “empty” header bar, with only window controls. This seems like a good choice, since it makes window borders and controls more consistent

  4. Very nice job ! Thx for the hard work, and bug puzzle solving !

    I think XFCE 4.15 will be used in variants of Ubunu 2020, which will have paid LTS support for 10 years.

    All the nice work that you did will be useful to many people for a decade .
    Social services, small and family businesses can build a stronger foundation on more stable software.

    Real economic and social value creation comes from that and we can be happy about it.

  5. Thank you for your work, it’s appreciated!
    Can you elaborate please why is it “advantage” and “improvement” for “consistent theming”? I’m using Greybird as well currently, all the decorations are very slim and consistent. They are consistent because they are identical. You are claiming some apps will not use HeaderBars so some will have 3x times thicker borders than others, how is it consistent? Not to mention a dramatic waste of vertical space (we need it on laptops).
    Best regards,
    Alex

    1. With the current change we’re saving vertical space. Compare the 4.14 version of the settings Dialogs to the screenshots in this post.

      Gtk and Xfwm4 themes are not connected whereas the CSD decoration is part of the Gtk theme, therefore it’ll always be consistent (and not only if you have and select a Gtk and Xfwm4 theme that was designed to work together).

      1. The current 4.14 Settings windows fill 60px of vertical space with a bar. To “solve” this, rather than remove the bar the title bar the user has set in the window manager to be used consistently across the desktop environment is being removed, so the window looks and behaves differently.

        This is partly why Gnome comes in for so much criticism and distros with other DEs may hesitate to mix in certain Gnome apps — the change to putting additional elements in the bar at the top of a window removes any option the user has to do differently, other than abandoning that application. The way CSD is badged as an initiative and promoters turn up and file “bugs” against major projects for not supporting their odd-one-out approach probably accounts for a lot of the rest.

        If Xfwm4 theming support is being omitted from core Xfce applications, it’d perhaps be kinder to kill it in one go as users have already lost the option of a consistent environment.

        This isn’t intended as a personal attack; from what you’ve said elsewhere Xfwm4 isn’t in a good state for feature development and CSD ticks some other boxes. Abandonment may ultimately make sense or be the only option.

      2. Thank you for your response.
        You are right actually, I can see it.
        Still, some people may find *acOS-ish interfaces ugly (and I think many of these people fleed from GNOME to Xfce), it’s sad we can’t have the option to switch the look back.
        Regards,
        Alex

  6. I dig the idea, XFCE is such a great desktop, CSD decorations makes sense if the desktop uses GTK. It will also make themes look much better in XFCE and favor designers in the long run if xfwm gets to the point that it’s not needed.

  7. I’m not super bothered by most of CSD stuff, but the merging of search bars into the header bar makes me very uncomfortable for some reason. I’m old and not familiar with the technical aspects, but I don’t suppose it’d be possible to reposition them to the bottom?

    1. I’d question the need for the search bar, since there aren’t many settings applets and they all fit onto an average screen. It seems to only provide a live filter based on the name of an applet, rather than trying to find applets that might do what a more non-technical user is looking for.

      We tend to regard things that aren’t symmetrical as ‘off’, added to which having the contrast of a white box on grey (rather than a white box in a white area of the window, as it is at the moment) draws the eye, plus it’s oversized next to the small min/max/close icons.

      In most cases chunky headerbars are a solution looking for a problem, trying to fit items that are differently sized with good reason into an area of the screen that’s reserved for specific functions.

  8. Not a fan of CSD. There can all too easily be inconsistency across applications; and if the application is unresponsive in any way (Windows-style modal dialogue boxes, for one), at least some of its windows aren’t movable.

    I plan to stick with server-side decorations.

    1. Out of interest, are you planning to fork, to replace components or to stop using Xfce?

      Personally I’m fairly confident of being able to stylesheet around the visual inconsistencies – there’s likely to be enough selectors to hide subtitles, avoid having massive chunky title bars for no reason, etc.

  9. Apparently CSD windows can’t be vertically maximised, either.

    In what way can losing access to basic features of the window manager be considered a plus?

  10. Ah, presumably no links allowed in blog comments.

    Apparently the approach in Manjaro when using Xfce and MATE has been to patch GTK to remove CSD completely — see the project ‘gtk3-mushrooms’ on Github.

    It’s interesting reading reactions across the web.

  11. Hi! Good to see xfce regaining momentum and moving forward!

    I’ve built 4.14 and now wanted to update the packages mentioned in your blog. But I couldn’t find sha-sums or .sig-files for verification. Would be nice if you could give me a hint where I might find them.

    Thanks for your work and good luck!

    1. We currently don’t have signatures in place and while our release manager (home brew) does check the SHA1 when we upload to archive.xfce.org, it doesn’t provide those hashes to the users/downloaders yet.

      We’re not investing time and effort into the release manager though because we hope to resolve this problem with our transition to GitLab.

Leave a Reply

Your email address will not be published. Required fields are marked *