hplip qt

hplip qt

[Nils Gillmann]

Tobias Geerinckx-Rice <me@tobias.gr> added in 407ef4b38ad394e0b63320b029d95afdd3da6888
support for Qt to Hplip. What feels like a lifetime ago, my patch with the same
intention was reviewed and to be worked in a separation of Qt and hplip, which
I found reasonable at that time but drowned in all the branches I had back then.
Not forgotten though, just very low priority.
I still find Qt as a dependency for hplip unreasonable. Can we split the package up
as we did for Octave?

Thanks.

Re: hplip qt

[Tobias Geerinckx-Rice]

Hullo ng0,

Nils Gillmann wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> added in 
> 407ef4b38ad394e0b63320b029d95afdd3da6888
> support for Qt to Hplip. What feels like a lifetime ago, my 
> patch with the same
> intention was reviewed and to be worked in a separation of Qt 
> and hplip, which
> I found reasonable at that time but drowned in all the branches 
> I had back then.

Where was this?

> I still find Qt as a dependency for hplip unreasonable.

One possible problem is that our PyQt doesn't benefit from the 
modularity (FWIW) of our Qt packages. I doubt HP's widgets need 
qtmultimedia, qtwebchannel, or qtlocation, but there they are 
anyway, probably wasting a few hundred MiB in total.

> Can we split the package up as we did for Octave?

If you can separate the GUI tools from the driver without breaking 
anything — including user expectations — go for it! Any idea how 
other distributions handle this?

I agree that a separate UI output (ideally) or package would be 
nicer than the monolith we have now, but I don't find an unusable 
UI to be in any way more ‘reasonable’ than adding the right 
dependency to fix it.

Kind regards,

T G-R