The option was remove to reduce the number of supported configurations, and I don't think our thinking has changed here.

You don't find it that strange either that you have to run an X server running as root to start a 'simple GUI program without integration'.

Dear Matthias,

X-server have nothing to do with integration of applications. It is necessary to draw the application on screen. And it definitely doesn't look strange to me, that I need it, if I want a GUI application. But your right, it is strange that X-server requires root privileges.

I have a suggestion about the next step of reducing of the number of supported configurations: just force people to install the whole GNOME environment in order to run any GTK application. You will have only one configuration to support. :)

Best regards

the entire premise of the bug is fallacious.

DBus has nothing to do with window managers or desktop environments: it's a standardised IPC mechanism. GTK uses it through the file system integration, the settings backends, and to ensure behaviour like being able to communicate between application instances. DBus is used by desktop environments like KDE, GNOME, XFCE, and by smaller window managers. with the advent of Wayland as the display architecture for Linux, things that were deferred to X11 will also move to DBus specifications.

Dear Emmanuele,

Unfortunately, I don't know how it looks from inside, but I can see only from user point of view. As far as I understand it, ideologically GTK is something that allows applications to create windows (with buttons, text fields, comboboxes, etc), transforms to graphical primitives and sends it to X server in order to draw on screen. And of course it delivers to the application about user interaction with widgets.

The mechanism to deal with filesystem is provided by the system itself (functions fopen, mkdir, unlink, rename, etc from stdlib.h). I am not sure what do you mean by "settings backend". Most of applications on my computer just use simple text/xml files to store settings (and it is the most convenient for me since I can edit them with text editor and put them in SVN to have history and easily share between machines). Some of them use SQlite. I guess SQlite or libxml can be called "settings backend" in such case. But what is the reason for toolkit to communicate with SQlite/libxml in other way than through the application?

In my case I have a system with GTK-2.24.20 and GTK-3.4.4, but without DBUS. All GTK-aplications including file manager (emelFM2) works absolutely fine with filesystem and storing their settings. emelfm2 can be linked to any of GTK-2 and GTK-3 (by changing the appropriate USE-flag and reinstalling) and I can be sure it works in both versions.

I don't know the mechanism, but if Firefox is already running and I write in terminal: firefox http://example.com/ it opens the link in a new tab in running instance of Firefox, but not in new one. If claws-mail is already running and I start it again, it exits at once and the old instance try to become an active window. It means that communication between instances works fine without DBUS, too.

I have never tried Wayland. Could you please give a couple of examples of things that were deferred to X11 and will also move to DBUS specification? Because I can't imagine that it can change the situation drastically. If DBUS still will be only a message bus, then it still will be necessary only for those who needs an integration between applications. Or may be Wayland communicates with application through DBUS, but not UNIX-socket? Anyway for X11 users it doesn't matter.

Best regards

> I don't know the mechanism, but if Firefox is already running and I write in
> terminal: firefox http://example.com/ it opens the link in a new tab in running
> instance of Firefox, but not in new one. If claws-mail is already running and I
> start it again, it exits at once and the old instance try to become an active
> window. It means that communication between instances works fine without DBUS,
> too.

Sure, you can invent your own ipc mechanism, or choose another one of the preexisting ones. Which is what we've done. We've chosen D-Bus. I don't think there is anything problematic or questionable in that choice.

Dear Matthias,

You are absolutely right! And I hope you can see from this examples, it's up to application developer to choose IPC mechanism. Not toolkit developers.

Developers of GNOME applications have choosen DBUS and I believe it's wise choice in this case. But other developers using GTK can choose/invent another IPC (or no IPC at all). But now their programs will hard depend on DBUS.

hi tot-to,

Gtk has a hard dependency on GLib, as it has since GLib was created over a decade ago.  This will never go away, as I'm sure you understand.

GLib itself contains a D-Bus client library implementation (GDBus) since about three years ago.  This is a core part of GIO and will also never go away.

In a sense, therefore, Gtk will _always_ have a D-Bus client library implementation in-process.

I believe that your complaint is specifically that Gtk indirectly pulls in the 'dbus' package (in order to use libdbus-1).

GNOME has the goal of porting all existing users of libdbus-1 to GDBus.  When this occurs for at-spi2-core, the indirect dependency of Gtk on the dbus package will disappear.

It's worth noting that this is strictly a build and (unused) run dependency.  It's still possible to start Gtk applications perfectly well without a dbus-daemon running.  The only argument here is over which D-Bus client library (GLib vs. libdbus-1) is _not_ being used, and if it's possible to remove the dbus-1 package from the system.  This is a fairly minor concern, from our viewpoint.

As stated, we plan to eventually remove all uses of libdbus-1, but this is a low-priority for us, and there are many more substantial problems with at-spi2-core that we'd like to address at the same time or before we did this.

I hope that explains the situation a bit better, and I hope you can understand why this isn't a huge priority for us.