Why would Gtk complain about a missing gdbus.exe in a directory that is not related to my current project? And we also never used gdbus.exe in VICE (the other project). The dir “C:\vice” is in my Windows $PATH and also in my msys2 $PATH, so perhaps Glib-GIO searches there for gdbus.exe, in which case the question becomes: how does Gtk search for that binary?
The gdbus binary is needed to create a session bus on Windows, which doesn’t have a DBus server spawned automatically when the session starts. When GTK tries to acquire the application’s name on the session bus, it will spawn the DBus server provided by GIO on Windows. The component responsible for searching the gdbus.exe binary is GIO, not GTK.
The gdbus.exe binary should be installed in the same directory as the GIO DLL.
My binary finds the libgio DLL in C:\vice and thus expects to find gdbus.exe there. When I rename C:\vice. to C:\vice.bak, my application finds libgio (and other required libs) in the msys2 tree:
So it looks like I have to be careful with $PATH. After removing ‘/c/vice’ from $PATH in the msys2 shell, and renaming c:\vice.bak back to c:\vice, my application properly finds the gdbus.exe in /msys64/bin/ and links to the DLL’s in /msys64/bin.
You’re strongly encouraged to never depend on “system” or shared installations of your dependencies on Windows. You should always copy all the dependencies, including ancillary binaries, into your application’s directory. This also makes it easier to package and distribute.
Yes, I do that for Gtk3 applications, not yet for this one since I haven’t got to creating make install or make bindist rules.
Once I do, it’ll be similar to how Windows distributions of the VICE emulator are done: copy all DLLs and required binaries (such as gspawn-winxx-helper*.exe) into a directory and use subdirs such as share/ and lib/ for glib schemas, icons, gdk-pixbuf loaders and such.
Now that we’re talking about properly distributing Gtk applications on Windows, I think we (VICE) don’t exactly follow the rules, we store our bins in the root of a dir, while I seem to recall reading some docs claiming binaries should be installed in .bin/ (with bla.exe then looking in …/share etc for supporting files).
Are there any docs about creating a proper Windows distribution with Gtk? We’ve been working on making VICE respect the ‘normal’ Linux/BSD/XDG rules, might as well get the Windows stuff right.
There are no hard rules for the directory layout of projects on Windows.
The path of least resistance is typically to have your binary in the same directory are your DLLs; you can manipulate the environment from within your binary and change the look up paths for most other assets—things like GSettings schemas, icon theme paths, etc.—but if you don’t want to, following the same layout as a Linux installation is fairly easy.
In many cases, like ancillary files and other assets, it’s recommended to use GResource; GTK can load a lot of things from resource paths, like UI descriptions, themed icons, etc.
With VICE we use a gresource file containing some icons, logos etc and load that from the filesystem, since we have 11 different emulator binaries, so compiling in the gresources via .c/.h files would only add bloat. We also don’t use UI descriptor files, since that’s not flexible enough to allow reusing dialogs or custom widgets for those emulators.
With my own project I do compile/link in the gresource.{c,h} and use UI descriptor files since it’s a single binary and it doesn’t use 200-600+ interacting settings like VICE.
But anyway, I think the original question was answered, so thanks for that.
The installers that I provide can be used to install Gtk system wide, but you can also easily include them into your own installation scripts (like Inno Setup or NSIS) and ensure they are available only to your own binaries.
The libraries and executables are fetched from the MSYS2 project, so you will need to use that to compile and link your own code for this to work, but that seems to be the case already
Thanks for that, but currently it won’t be of much use to us. We currently ship only the gtk/glib libs we used to compile against, and a bunch of other non-gtk libs depending on configure options.
