On Friday May 15 2015 10:19:00 Thiago Macieira wrote: > This means you used QtDBus, which tried to connect to the bus daemon, which > was compiled with support for launchd but the .plist file wasn't loaded into > launchd.
I don't use it, not explicitly at least. Does Assistant use QtDBus, for instance? > But since Qt doesn't ship with the daemon, the D-Bus libraries or the .plist > file, the problem here is that your system *does* have them but didn't > configure This isn't (entirely) true. I indeed have DBus installed, and also running on my "console" session, so that for instance KMail (which I'm typing in right now) works. > them. Why do you have the D-Bus library somewhere that QtDBus could find it > but > didn't configure it properly? The exact same way a similar situation can arise on Linux: logging in remotely over SSH without starting a dedicated session DBus and starting an application to display remotely using the xcb plugin. On Linux you'll also get an error when you don't have a launched that session DBus, but only when the application actually tries to connect to it. You don't get that error with Assistant for instance. AFAIK, it is not possible to launch multiple session DBuses with the OS X implementation. That should be fine as long as you don't actually use it, and it would be nice if there were only an error message when an attempt is made to use DBus functionality. NB: when I login over SSH I can start Qt applications for local display (on the "console", regardless of who is logged in there (*)), and then there is no error message. Yet `launchctl export` doesn't show me the DBUS socket variable that it shows from a local shell. *) I've reported that as a bug, because a remotely logged in user B should not be able to open applications on/in the local session of a user A. I hope this made it a bit clearer... R. _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
