> 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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
