> Can't ask users about such
tradeoffs, they will be annoyed and won't be able to answer. These days you
can ask the printer via d-bus. The printer knows more about itself than its
users know about it.

D-Bus is used for communication between processes. So the configuration and operation of a printer is split between several different components, which use D-Bus to communicate with each other.

I question this architecture. Why should an application need a system bus to pass messages between its own components? CUPS is not using D-Bus and is able to print to other printers; only HPLIP uses D-bus, so far as I am aware. Why not keep using the same method/interfaces that are proven for decades? What is the benefit? How are printers from other manufacturers supported?

Above architecture /may/ be beneficial to a number of use cases. E.g. interactive desktop users that want also a simple GUI tool in an integrated desktop environment. Imposing a hard dependency on an additional component (D-Bus) may not server other use cases well or at all if they cannot use D-Bus.

So I am left with below choices:

* Accept no printing
* Accept HPLIP+D-Bus if possible
* Fork and change HPLIP or develop something new to do the job, if I have the abilities/motivation.

At least this is an option in free software world.