Regarding that pesky xfdesktop memory leak that presents itself in Slackware, I don't know what triggers it. Guaranteed trigger is to right-click on the desktop, but sometimes something else triggers the leak and I don't find out until I notice how sluggish things are getting. Htop in a xfce-terminal window showed four xfdesktop processes at the top of the list, all physical ram allocated and the swap space use increasing. A `kill -SIGKILL` cleans up the process list and restores the usual fast responsiveness, but a new xfdesktop process appears with this command: `xfdesktop --display :0.0 --sm-client-id [big number deleted for brevity]`, however `man xfdesktop` says there should be only one xfdesktop process running with no options. "Only one instance of xfdesktop can be running at a time, and should be started by run-ning xfdesktop without any arguments." A bit of scanning duckduckgo.com leads me to believe that the arguments are for gnome-wm, gnome-panel, other assorted gnome programs, not xfdesktop. Gotta ask, why is xfdesktop invoked with gnome arguments and which process notices the shortage of xfdesktop processes?

I feel like I should just go run LXDE and leave xfce4 until it becomes a lot less gnomish, but lxde appears to be too debianish. Mate is an option, but I haven't gotten around to compiling it without the power-manager dependency [I don't have a laptop, the computer and peripherals eat a lot less leptons than the heat pump when it's 110 outside with 5% humidity. Power saving is not a concern, as long as my UPS has ten minutes of spare leptons.]

Give i3wm a try. My desktop is progressed from KDE => XFCE => fluxbox => i3

It is a different experience at the beginning. But once you get used to it, you will love its simplicity.

1 members found this post helpful.

The slow right click menu on Desktop is not from a memory leak, but a known bug in the way icons are handled(I think not properly cached) in the application menu. You can either disable the application menu being in the right click menu or disable display of application menu icons. Though if you use an SSD like on my laptop the bug becomes non-existant since the drive is so fast. These option are under Settings Manager>Desktop>Menus.

As far as multiple xfdesktops, maybe a corruption of your xfce session? try deleting your xfce session in Settings Manager>Session & Startup>Session

Also the multiple xfdesktops could be from multiple x sessions being started. if there are listing different than --display :0.0 say numbers like --display :1.0, this would be on a different x screen on the same monitor, so one of your virtual x console that can be reached by Ctrl+Alt+F8

The --sm-client-id is also a session management id. So if these are different it would imply seperate sessions

So my guess is you have inadvertently started several separate x sessions on your virtual x consoles. Or something else is starting them

Though it could be a corrupted session as well.

Xfdesktop launches three processes. There shouldn't be a --sm-client-id parameter to xfdesktop.

/proc/$(ps ax | grep xfdesktop | grep tty2 | awk '{ print $1 }')/task shows two additional pids. The root process task/comm is "xfdesktop"; the other two /proc/pid/task/comm are "gdbus" and "gmain" respectively. All three have /proc/pid/smaps that are close to 50,000 lines long. Someday I'm going to learn gdbus introspect and other commands in the gio reference manual, but I'm running xfce. I have a few mate-slackbuild applications because I like the image viewer and pluma, maybe the calculator. I suspect that since those are gnomey, they bring in gnomey sytem utils, maybe the session manager?
Thank you, pataphysician and qunying for helping me! When my tasklist permits, I'll work on this again. Meanwhile, I have a perl script that records the main status:VmPeak, sleeps a while, wakes up and checks VmPeak against the previous value. When things start getting above 600Mb, the klaxon tells me to go kill the thing.

Oddly enough, I removed all of the KDE and MATE packages; the runaway VmPeak memory allocation in gmain and xfdesktop vanished. I now have a right-click menu for my desktop once again.
Judging by the gnomish command options to re-launched xfdesktop session, I suspect something in the MATE package is involved. I'll re-install things one at a time and test for VmPeak allocations from 500Mb to the gigabyte range so I can warn other XFCE/MATE folks. Meanwhile, I'm going to close this thread (as soon as I can figure out how to do that).

I would be curious to know if you think it is related to any MATE packages. I run MATE packages built from our MSB repo and have not noticed any slow drawing, slow clicking, memory leaks from what I can tell.

Also, the mate-power-manager is not in the base set of packages so it's not required.

I suspect MATE because it relies on Gnome libraries. The leak is in xfdesktop, which initially launches with no switches. When the runaway proc is killed, another instance of xdesktop is launched with switches such as --sm-client-id. Xfwm wouldn't do that. I, too, have run a clean installation of MATE with no problems. The problem presents itself with XFCE as the startx desktop and a few MATE apps along with their dependencies installed. /proc/<pid>/status:VmPeak is the metric that keeps increasing until the swap partition starts filling up. It is only after all of available physical ram is allocated while VmPeak is still increasing by invoking the swap partition that things start slowing down. Under normal use, the kernel never uses the swap partition, 4Gb of physical ram is enough to keep everything I usually do in physical ram (shared libraries helps). When a process continually allocates memory from the swap partition, the kernel can't get enough swap space to keep all of the other Xwindows applications running smoothly. Kill the main xfdesktop, *poof* things return to normal, except for the command options to xfdesktop. According to `man xfdesktop`, it "...should be started by running xfdesktop without any arguments."

I've got everything reinstalled, except that instead of installing each dependency eom, atril, pluma and gtksourceview complains about, I've copied only the /usr/share/glib-2.0/schemas from pre-built packages like mate-desktop, without installing the rest of those packages. I may have mentioned mate-power-manager while I was hunting down "org.mate.lockdown.gschema.xml" which is a #define in power-manager. I found the full xml file in mate-desktop. Everything works. That's why I suspect mate-desktop and xfdesktop may not work well together. Because MATE is still not entirely independent from gnome, gnome processes were appearing without invitations. "/usr/libexec/at-spi2-registryd --use-gnome-session" might have something to do with that. I don't know why /usr/libexec/gconfd-2 and /usr/lib64/xfce4/xfconf/xfconfd need to be running simultaneously.

Someday I'll look into what launches `/usr/bin/python /usr/share/system-config-printer/applet.py` which is superfluous because cups manages all of the printing.

Please address anything I haven't covered. Although I'm a trained scientist, I'm working without a notebook, so there are probably related issues that I forgot to mention.