Add atk-bridge patches and make dbus dependency optional

[stefan11111]

I don't know if these patches are right for this project, but here are the patches for making the dependency on dbus optional by disabling atk-bridge.
I tried my luck with upstream, but they said no and stopped responding.

[lah7]

Found the upstream report:
https://gitlab.gnome.org/GNOME/gtk/-/issues/5964

I appreciate the art of a lightweight, as few dependencies as possible OS, so I am happy to accept the patch. #40 confirmed that it was once possible to use --without-atk-bridge at build time, which was removed over a decade ago.

However, because GTK 3 apps these days might expect "ATK Bridge" to be present, I think our "classic" patchset should still ensure it is built by default, but allow users to explicitly opt out of this and keep all the pieces if it breaks.

We don't know what in the wild might mysteriously break/crash because it used an accessibility feature or indirectly needed D-Bus, which seems risky for this project to have disabled by default.

The changes proposed here look good, so I think we just need to change:

-option('atk_bridge', type: 'boolean', value: false,
+option('atk_bridge', type: 'boolean', value: true,

so that on the packaging side (Arch, Ubuntu, etc), this doesn't accidentally build without atk_bridge and potentially break things.

[stefan11111]

Setting it to be enabled by default, like you proposed, is the better choice.
I copied the patches from my gentoo patches directory, where I had to set it to default-disabled because there is no way to toggle it without a patched ebuild.

I suspect something similar might need to be done for the gentoo ebuild for these patches, given that it's supposed to work alongside gtk+ from ::gentoo. Maybe a use flag to switch between adding these patches or not.

Also, I am really curious how you manage to dig out there old upstream commits. Is there a tool to search through commits?

[lah7]

Not familiar with Gentoo myself, but as this default arrangement works then it's all good. I'll get this merged.

Also, I am really curious how you manage to dig out there old upstream commits. Is there a tool to search through commits?

I didn't find that one - it was from issue #40.

Though, Git's "blame" feature is useful for tracing back how a line of code had changed. There's a "blame" button when looking at a file in GitHub or GitLab. There is also a way to see the file prior to that commit:

Otherwise, searching within GitHub/GitLab is powerful too - code, issue or commit. From there you could explore the repository to piece together how things came to be.