New comment by furryfixer on void-packages repository

https://github.com/void-linux/void-packages/issues/21766#issuecomment-627047559

Comment:
My knowledge is limited in this area, but I confirm this issue occurs with lxdm and xdm as well, so would not suspect DM's to be at fault.  The issue does NOT occur at all with LXQT and same DMs. 

Arch (or systemd specifially?) creates a dbus socket at "/run/user/$UID/bus" and assigns $DBUS_SESSION_BUS_ADDRESS to that socket.  Void (elogind specifically?) does not (for any desktop environment I have installed).

 In Void, at each login, both KDE and LXQT  create a file in "~/.dbus/session-bus/" directory.  This file contains a "$DBUS_SESSION_BUS_ADDRESS=unix:abstract=..." variable assignment for apps that want it.  The comments indicate this can/will be used if "$DBUS_SESSION_BUS_ADDRESS is not otherwise set.  It seems to be that, these electron apps at least,  are not looking here. I assume because they always expect the bus address to be assigned (to the socket perhaps).

The difference between LXQT and KDE Plasma seems to be that LXQT actively assigns the value found in the file  within "~/.dbus/session-bus/" directory to the  $DBUS_SESSION_BUS_ADDRESS variable.  This could perhaps be done somehow for the Void KDE Plasma package?  Otherwise, Xsession scripts could use the method suggested above, "exec dbus-run-session @" for example, or "export $(dbus-launch)" prior to the exec line.  Or, as we did when dbus stopped autolaunching X11 (before dbus-x11):
```
[ -z "$DBUS_SESSION_BUS_ADDRESS" ]  && eval `dbus-launch --sh-syntax`
export  DBUS_SESSION_BUS_ADDRESS
exec .....

```