On Tue, Dec 28, 2021 at 2:24 PM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
I confess to not know what D-Bus is, except that I see references to it in the logs since several years ago, complaining of this or that, in every computer. Thus I'm not intentionally doing anything about D-bus. The only thing I know is that there was no delay in 15.2, and there is a long delay in 15.3 :-)
So if the application can work without dbus, and there is a way to tell the application to not try dbus, I suppose I would be happy.
This is the same as asking an application to not try TCP/IP protocol to work around DNS resolution issues.
Well, maybe I miss something obvious, but AFAIK, when working over ssh dbus doesn't work, yet the application works fine, so why even try?
Complain to desktop developers. Linux desktops became rather complex and need much more than just a plain X11 server to work. Apparently nobody is motivated enough to design "desktop application forwarding". Personally when I need GUI I just start VNC. Unfortunately, even that fails because developers are not willing to support more than one graphical session per user ... I wonder if I can start "virtual seat" so that two sessions do not conflict.
D-Bus is a communication protocol. It is the de-facto standard today for communication between desktop components. You cannot "tell the application to not try dbus". At most you can tell the application to not attempt to contact service that causes delay. But I do not know how to do it. For a start, I do not know why xdg-portal service is invoked at all - all I have seen so far suggests that it should be opt-in.
So far the only way to eliminate this delay I found was to forward Unix socket from remote client to local user D-Bus socket and tell remote side to use it. But that sounds horribly wrong for multiple reasons.
I suggest you open a bug report to clarify whether this is an upstream issue or caused by the local SUSE patch.
Ok, will do.
Please post bug number here.
The delay doesn't happen when I run the same command locally.
Of course it does not. In this case you have a consistent desktop environment where your application runs.
Still, desktop belongs to user "cer" and application is run as root.
How are we supposed to know what you did? You said "I run the same command" and the command was "meld". You did not say "I used su or sudo to run this command as root" which is implied now. I can reproduce your issue when ssh into a local host and different user or doing "su - otheruser". In both cases I get the same delay. If you provide exact steps when issue does *not* happen, we could test it.