Allow dbus module to be optional

[ag-eitilt]

New dependency on the QtDBus module. If this requirement is an issue for you or your distribution, please open an issue! Note that a DBus connection at runtime is still optional.

I recognize that I'm just one person weighed against the maintenance burden of an entire non-standard configuration, but this is indeed a bit of an issue for me. I'm putting together a FreeBSD daily driver that's tuned to be lightweight and relatively auditable.[^audit] dbus and the ecosystem around it is built on a "we'll handle things for you" that makes it difficult for me to reason about (besides it subjectively running counter to how I want to manage the system), and I've successfully disabled it from the vast majority of the system -- including having built QT without the dbus modules. So, when I try to start qutebrowser up, I get "No module named PyQt6.QtDBus".

Unless I'm missing something, it looks like the only thing qutebrowser uses dbus for are notifications, which I don't mind being forced to one of the fallbacks in content.notifications.presenter for (or even losing entirely if it came to that). Needing to re-introduce dbus into the build stack just to satisfy an interface I'm never going to activate is rather nonsensical. Is that note at the top something that can still be followed up on and the dependency made fully optional? I wouldn't even be against needing to maintain a custom patch in my own ports build scripts if this was deemed overly-fiddly for the main project, but unlike C/C++ it's not something I can simply cut out with the right preprocessor directive; even moderately-advanced Python is rather opaque to me.

[^audit]: In the personal sense -- Linux From Scratch-esque, not legal requirements, and certainly not at the codebase level. The general idea is that I should be able to concretely explain everything in ps -ax, what purpose it serves, and when/how it was launched. (Bonus points if I'm able to instrument things to put up on a dashboard.) I'm not at that point yet since there's a number of kernel processes I still need to immerse myself in, but that's the goal I'm working toward.

[The-Compiler]

Thanks for the detailed description! To be completely honest, given this has been around for 4.5 years and this is the first complaint I hear, I won't be spending any time on this myself in the forseeable future.

Getting this to work will probably indeed be easier as a patch which just removes the dependency in a hardcoded way vs. doing it the proper way as an optional dependency.

In a nutshell (untested):

• In check_libraries in qutebrowser/misc/earlyinit.py, remove QtDBus as required dependency
• In qutebrowser/browser/webengine/notification.py remove the from qutebrowser.qt.dbus import
• Remove type annotations and @pyqtSlot decorators until things work again (or for the former, possibly add from __future__ import annotations to the file; for both, possibly pass them as strings instead)
• In DBusNotificationAdapter.__init__, immediately raise an error

[ag-eitilt]

To be completely honest, given this has been around for 4.5 years and this is the first complaint I hear, I won't be spending any time on this myself in the forseeable future.

Completely fair.  I figured it wouldn't hurt to ask since you had that note when it was introduced, and since the dependency hasn't grown in scope since then, but I did figure I'd probably wind up maintaining my own patch.  Side note:  That's my favorite thing about source distros/BSDs -- you really can make the system your own, so long as you have the skill.

Getting this to work will probably indeed be easier as a patch which just removes the dependency in a hardcoded way vs. doing it the proper way as an optional dependency.

Good point, I had managed to overlook that; my typical approach is to add a build option on the off chance the ports-tree maintainers want to adopt it, but in this case since it's digging into something fundamental to serve a subjective purpose which I'll never want to toggle myself, I may as well just tear the whole thing out.  I'm much more confident in my mediocre Python skills to do that and to clean up the edges afterward than, like you said, to implement an entire, functional toggle.

Thanks for the roadmap!  I'll post my patch here once I've got it written up in case anyone else comes along wanting to do the same (since I've not gotten a spot set up to host all my patches centrally yet), but without any pressure for you to merge it, or even really to review it.

[ag-eitilt]

Haven't validated this yet since I'm still getting rendering issues ("neither GLX nor EGL are enabled", etc.; system issues rather than qutebrower ones) that prevent me from loading any page in the first place, but so far as I'm able to get, this seems like it solves the notification issues. There's still a message about trying and failing to connect to dbus, but since that's happening in bus.cc (line 407) instead of anything Python, my guess is that it's a library not being entirely dbus-free rather than qutebrowser itself. If I get the rest of the system straightened up and find that this isn't cleanly removing things I'll update the patch, but in the mean time: patch-disable_dbus.patch. It's following FreeBSD's naming scheme (*.orig) rather than git's (a/*+b/*) so it might need metadata tweaking to adapt to whatever tooling is being used. @mschilli87, sounds like you might be interested in running this if I'm reading your emojis correctly, and if you do you'll probably be the first to run into anywhere it goes wrong. 😉

Remove type annotations and @pyqtSlot decorators until things work again (or for the former, possibly add from future import annotations to the file; for both, possibly pass them as strings instead)

I really hate the several layers of separate hacks that make up Python's type system. For the record, I did use strings for the annotations (*shudder*) to minimize the diff's impact, but the @pyqtSlot annotations didn't accept that so they got removed entirely.

EDIT: Got the rendering fixed (forgot to update the Mesa build options to be appropriate for the laptop (integrated Intel GPU) rather than the desktop/build host (AMD card)), and notifications seem to be working correctly. Still haven't tested with tray/DE notifications, but the in-browser view is showing up well, and no complaints are getting printed to the console (except for the aforementioned bus.cc on startup).