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! 🙂
Disabling CSD using gtk3-nocsd has served me well, and I hope will keep serving me. Consistency and predictability brought me to XFCE.
https://github.com/PCMan/gtk3-nocsd
https://www.reddit.com/r/linux/comments/8lb19a/disabling_client_side_decorations_entirely/
You guys already anticipated the CSD-haters like me 😉 I’m glad you are very aware of pro/con and I trust you will make good design decisions. I use XFCE on a daily basis; your work is appreciated!
Thanks for the links… looks like I’m gonna need them in a not so distant future…
=(
I’m not really missing anything currently in Xfce at this point, it already does everything I want beautifully. Just worried de DockBarX plugin may soon stop working. But still, some very good news!
I hope you will migrate directly to gtk4. I know that gtk4 is in beta, but this could be an advantage for you because then you will be able to influence the gtk4 api. As I have understood when gtk4 is released the api can’t be changed before gtk5.
If you migrate to gtk3 you will use a version that has been under maintenance for over 3 years and not optimized for modern Wayland api:s.
Regarding the “Night Light” – I’m not sure it is really needed as interested individuals can easily install Redshift.
Redshift doesn’t work on Wayland, and Wayland support may be needed if X11 gets firmly into the “legacy software” category.
Well, I guess I’m in the market for a new DE, then. I can’t stand CSD, and the mockups linked look like a straight up downgrade to me. It’s a shame, because I have been on XFCE exclusively for my entire Linux time, but I don’t think I can get used to this, or even want to try.
That said, thank you for all the work so far, XFCE has always been my #1 example of amazing Free Software product. In the end, you can’t please everyone, and obviously a non contributor has no place in demanding how the project is run. I hope the future keeps being bright for this project, and thanks for all the fish. 🙂
> and storing view settings per directory.
This is more than welcome. One bug requesting exactly this has been open on the Bugzilla tracker since 2007.
why does it say 4.15 in the url, 4.16 all through the post except at the end where it talks about getting 4.15 going again? am i in some sort of twisted dimension where i can never know the true version numbers of anything? some manner of nerd super hell? 🙂
4.13 was the development branch that became 4.14, and 4.15 will be the development branch that becomes 4.16 — it’s an old convention still used by a fair number of projects. Odds = dev, evens = stable.
Apparently odd numbers are development versions, even numbers are releases.
Hi!
What are the benefits of migrating to CSD?
I ask this cause In my opinion, mixing normal and CSD is a pain. There is no way to have a uniform experience and appearance when using almos tall GTK themes but the awful Adwaita and window composition like Compiz, Compton, etc. and I had to make some tricks to avoid some CSD effects.
In my opinion, HeaderBars are a non-sense. You only have a good desktop experience when you only use CSD+HeaderBars apps, which is impossible cause a normal user uses a lot of applications that does not follow these UI Guidelines. Also a normal user uses QT applications inside GTK environments. At least you have no plans to use HeaderBar, which is good news.
But, I’m a bit worried about the new CSD implementation. So, please, help us to understand why this is preferable.
Thanks a lot!
Are CSD and roll up the window titlebar compatible?
No. You can try it with Chrome/Chromium. If you config it to use CSD you won’t be able to roll up, but if you config it to use normal Window Manager, it is possible as expected.
😉
Nope, it’s removing functionality users may rely on, for mainly aesthetic reasons.
There seems to be a vocal minority against users having control of the look and functionality of window management (the things that traditionally a window manager keeps consistent rather than allowing branding/alteration of) and to date Xfce has been on the side of users.
If Gnome’s one-size approach was optional / coexisted better with user accessibility needs and preferences, it’d probably be seen less as an ideological hell-cancer at risk of infecting other DEs, provoke fewer shitstorms, etc.
First thanks for the amazing work done. I’m using xfce since the version 3 and I convert some of my friends and colleagues to xfce because of its simplicity and because you can customize it to match your workflow.
About CSD my main concern is not the design or the consistency of the UI between different applications but more the features of xfwm which make really a difference compare to other window managers.
Is it still possible to have actions like moving window with ALT+left-click, resize window ALT+right-click, send window to the back with middle-click, vertical or horizontal maximization, … with CSD?
You can get a good idea by testing with software that provides a choice of normal window management and a CSD alternative, such as Sean’s Catfish search tool.
Generally if the interaction is with the window content, it’ll work, and if it’s with the window manager elements such as borders it won’t unless the CSD handling implements those features. With Catfish the ALT+ shortcuts seem fine but eg horizontal maximisation doesn’t work because the application is drawing the borders. The user loses the expected behaviour.
This is also why CSD tends to be terrible for accessibility — eg people rely on chunky window borders for resizing due to limited mobility or vision. Overriding the functionality and look of the window manager theme/settings they’ve selected is anti-user and more than a bit arrogant. Unfortunately it’s also very common in modern development.
SUGGESTIONS:
– Being able to have 2 panel
– one at the top
– one at the left
but i don’t want them to overlap, i want the panel at the left to snapt the height so it fits right
– Global menu, just like Unity and macOS
Then you win my hearth
For the XfceTitledDialog apps, why not simply remove the title widget and leave everything else as is? I always thought the title widget was redundant.
CSD is a slippery slope if you ask me. Drop it in a few places in 4.16 and by 4.18 full headerbars will be everywhere. Testing it on the “low-hanging fruit” is the issue, since it’s unlikely to cause the overwhelmingly negative response you’d get by putting it on Thunar right away. So what are the problems with that? As others have noted, it removes much of the functionality you get with a dedicated window manager (see “separation of concerns”). Worse, combining the titlebar, toolbar, and menu bar is a huge oversimplification, and would necessarily result in certain functions, which are currently easily accessible, being hidden under clunky menus or removed entirely. I prefer Xfce because it *doesn’t* feel like GNOME, because it strikes a good balance between feature-richness and ease-of-use.
The new panel features on the other hand–dark mode and desktop actions–have actually been on my wishlist for a while.
Good job, guys!
xsettings > Gtk > IconSizes is not working anymore. Except the Xfce terminal, cycling between tabs with the mouse wheel no longer works. There is no way to avoid those hideous symbolic icons. Changing the alpha setting of the panel in the color picker is a pain in the ass, the slider of the 4.12 panel was perfect as it was. I downgraded xfce4-panel to 4.12 because of that (and other small annoying changes).
There are some new Xfce contributors coming mainly coming from the Ubuntu world who should keep three simple principles in mind:
1- KISS
2- If it’s not broken don’t fix it
3- Stupid changes are not synonymous of useful progress…
To add to my first comment, it has been shown in the past that it’s not a good idea to rely too much on GNOME-specific “anti-functionality” and “anti-design” craps. Remembering the excellent Xfce mixer that was killed by porting it to gstreamer?
I think it would be a shame if Xfce followed Gnome with CSDs. It’s important that Cinnamon, MATE and Xfce offer an alternative to Gnome. If these desktops stick to traditional titlebar and layout then application developers will always be able to make traditional applications with GTK. If CSD becomes default, GTK devs may remove the possibility to create traditional applications with GTK.
Maybe a few Xfce users (and the devs it seems) are interested in CSDs. I think CSDs will alienate the majority of Xfce users and drive them to MATE and Cinnamon. If CSDs are necessary, maybe make them optional?
Xfce 4.14 is a good release so thanks for that one. MATE ported the GTK2 color picker (with transparency) to GTK3 so if Xfce could borrow that code (in panel configuration) it would be a nice improvement.
Its sad to see that window management is going away, that’s one of Gnome’s problems. And why I don’t use Gnome.
Xfce 4.16 development phase starting – Simon's Secret
https://danadigennaro.blogspot.com/2019/10/rahasia-tembus-togel-hongkong-pakai.html
Good news. The previews look great!
I think it would be appropriate to drop all the GTK2 support already in 4.14. We could get along with 4.12 until then. Features that will come with 4.16 would be already delivered by 4.14 and I suppose switching to GTK3 would be much easier.
I don’t see why to put this “night light” function in the power manager. This has nothing to do with power management and only Xfce users who have the Xfce power manager installed (I don’t) will have this new feature.
Why not in the display settings dialog?