Comment 74 for bug 905147

Thanks for pointing to the patch referenced above.

I assume that would require compiling QT from sources and configuring things to use the hacked library as explained around comment 17?

I don't, frankly, think I am up to managing that. I've tried compiling QT in the past and it has always ended in failure. I did once manage to compile something but as I remember it didn't actually work. Plus it is an awful lot of work and I don't really have time to do that for every update, something I'd assume would be needed.

In any case, if I understand the patch's function correctly, it won't really help me much. It won't pick up the CUPS paper size so without intervention, KDE will still send everything formatted for letter paper rather than A4. It also won't pick up the quality settings I need set for some of the printers I use in order to get output which is dense enough to photocopy legibly. QT's print dialog doesn't even give display most of these options because it is insensitive to the actual capabilities of the printer as provided in the ppd. Non-saving of settings is only part of the problem - there are also the settings which I cannot set through the dialog but which should be available from CUPS. (QT's dialog shows them in Properties but I'm not sure what the point of that bit of the dialog is. Doesn't seem to have a function.)

In any case, telling end-users that the fix for a problem involves patching QT source and building the whole thing from scratch is not a solution.

The available patch is also out of date. It is for 4.6.2 and the version installed from my distro is 4.8.0.

Is there any reason *not* to consider e.g. the openprinting dialog? That looks to be very thoroughly thought through and researched. I know that is in its infancy but even if it is a bit buggy, it may well be better than the current dialog. Wouldn't this offer a solution which would fit in well to the KDE interface (since there's a QT version) and avoid relying on the development by QT (which clearly won't happen any time soon), while not requiring KDE developers to build a separate dialog for printing themselves? Since that will also likely be adopted by other DEs, it would also have obvious advantages in terms of adhering to common standards etc., and early adoption would make it more likely that the specific needs of the KDE ecosystem will be fully reflected in the development.

I don't know much of anything about development but there seem to be compelling reasons to consider an alternative to the QT default dialog and a promising alternative already in the works.

But that solution seems not to have been addressed...