xfce 4.14 released

[Stevo]

Wait a day or so until I get all the panel plugins in there, too. Lots of them won't work until they get rebuilt against the new panel libraries.

You'll also be on your own if your existing gtk2 theme doesn't support GTK 3 very well, and will have to use a new one or use one of the builtin ones.

[dreamer]

Wait a day or so until I get all the panel plugins in there, too. Lots of them won't work until they get rebuilt against the new panel libraries.

You'll also be on your own if your existing gtk2 theme doesn't support GTK 3 very well, and will have to use a new one or use one of the builtin ones.

OK.

[Stevo]

OK, everything seems to be settled in the repo now.

For the adventurous, here's how to get 4.1.4 from the OBS repo:

It seems that the xfce4-messenger, cellmodem, and quicklaunch plugins are not longer maintained and will be removed by this update. I got the rest of the plugins updated.

For a Stretch base, run the all the following in a root terminal, to prepare, add the repo and its key, then update apt:

Code: Select all

echo 'deb http://download.opensuse.org/repositories/home:/stevenpusser:/xfce-4.14/Debian_9.0/ /' > /etc/apt/sources.list.d/home:stevenpusser:xfce-4.14.list

rm -f Release.key && wget -nv https://download.opensuse.org/repositories/home:stevenpusser:xfce-4.14/Debian_9.0/Release.key -O Release.key

apt-key add - < Release.key && rm -f Release.key

apt update

and then upgrade:

Code: Select all

apt full-upgrade

or use MX Updater. Then log out and back in.

Your present theme may not support GTK 3 well, so you might have to switch to one that does. Your Conky on the desktop may also lose its pseudotransparency, but I think you just need to change one word in its file to get it back. Look for a line(s) that says

Code: Select all

own_window_argb_visual no

and change that "no" to "yes", then turn on compositing in MX Tweak.

We are getting some input now from the XFCE developers that the 4.14 XFCE compositor may have some issues with the default glx backend with AMD and Nvidia graphics drivers. AMD seems to work better with xrender. We are discussing making that easy to set in MX Tweak instead of the rather obscure commands you need in the terminal now. Intel GPUs should be fine with the default setting.

The repo also has armhf (Pi) and arm64 packages, as well as separate repos for Raspian 9 and 10. Debian Buster users can use the same directions, except replace "Debian_9.0" with "Debian_10.0" in the two places it appears.

[Head_on_a_Stick]

We are getting some input now from the XFCE developers that the 4.14 XFCE compositor may have some issues with the default glx backend with AMD and Nvidia graphics drivers. AMD seems to work better with xrender. We are discussing making that easy to set in MX Tweak instead of the rather obscure commands you need in the terminal now.

I can confirm this problem occurs with my Vega 8 (AMD) graphics but only if the TearFree option is not used for the amdgpu DDX driver (xserver-xorg-video-amdgpu). If the TearFree option is applied then the compositor artefacts do not corrupt the screen.

Unfortunately whilst the xpresent backend (not xrender) stops the glitches[1] it also fails to stop screen tearing. I can recommend compton as a working alternative compositor that will control screen tearing and add some effects like transparency & drop-shadows:

Code: Select all

compton -B --backend glx

Anyway, here's a spoiler scrot:

[Stevo]

Hey, thanks for that information! So the quickest method for AMD would be to apply the tear-free in MX Tweak?

We have another developer with AMD that uses compiz-reloaded, and he said that it was glitchy until he switched to xrender, though--though compiz is its own compositor, so maybe that makes the switchover smoother.

[Head_on_a_Stick]

So the quickest method for AMD would be to apply the tear-free in MX Tweak?

Using the XFCE compositor without the TearFree option enabled causes terrible screen corruption on my hardware whenever a window or it's contents move. Enabling the TearFree option removes the corruption and allows the native compositor to work without any other problems. Changing from glx to the xpresent backend for the compositor's vblank_mode removes the corruption but also removes tearing protection so that will need the X.org configuration file tweak anyway.

It would be interesting to hear from any NVIDIA users to see if their compositing pipeline can also help with this problem.

We have another developer with AMD that uses compiz-reloaded, and he said that it was glitchy until he switched to xrender, though--though compiz is its own compositor, so maybe that makes the switchover smoother.

I don't think XFCE's native compositor could be made to run at the same time as Compiz. But I may be wrong.

[richb]

I don't think XFCE's native compositor could be made to run at the same time as Compiz. But I may be wrong.

That is certainly true with XFCE 4,14, The native compositor has to be disabled for Compiz to work.

[Stevo]

I also have to disable Compton on the present XFCE 4.12 before I can get compiz to successfully start.

[Head_on_a_Stick]

ToZ has put up an official guide for dealing with the problem:

https://forum.xfce.org/viewtopic.php?id=13233

It's also been discussed on the Arch Forums: https://bbs.archlinux.org/viewtopic.php?id=248388 & https://bbs.archlinux.org/viewtopic.php?id=248526

[asqwerth]

@Stevo, I note that the packages for xfce 4.14 you packaged for MX doesn't have the "About XFCE" information window.