On May 16 09:16 Johannes Mueller-Lahn wrote:
Yes, if printing from other apps works then it confirms that it is not a CUPS problem. If you test with a pure Qt application rather than a KDE application you are likely to find the same result (e.g. Qt Assistant) and confirm it is a Qt bug. It is virtually impossible for it to be a KDE only bug. Unfortunately, Nokia consider Printing to have a status of 'Done' so bugs below level P0 and P1 do not get any attention, and they don't even have a maintainer assigned, so it is highly unlikely the bug will be fixed in Qt4 unless someone goes looking for the bug and provides them a patch. Hopefully with the sale of support services to Digia and the coming of Qt OpenGov with Qt5 we can get a team of maintainers together to work on fixing the all too many bugs. On Tuesday 17 May 2011 11:59:31 Johannes Meixner wrote:
Basically KDE 4 printing is insufficient (polite form).
They decided to trash the whole KDE 3 kdeprint subsytem and now - what a surprise - the KDE 4 printing is insufficient.
Sigh. We do do these things for a reason, not just on a whim, so let me explain this one more time. KDEPrint in KDE3 was basically unmaintained for about 1-2 years so no-one worked on porting it to KDE4. About 2 weeks out from release of 4.0 we realised this was the case and tried to fix it. We soon found that the code was broken when used with KDE4 and was virtually incomprehensible and thus unmaintainable by any new people due to a complete lack of documentation or in-line comments. Even if we had the people with the sklls to fix it and maintain it, 2 weeks was too short a time to do so. Besides which, KDEPrint did not work on OSX or Windows and writing the required backends would have taken months as well even if we could find the people with the required skills. Fortunately Qt did have cross-platform printing support that worked with a near identical api (unsurprisingly as KDEPrint was really just a wrapper around QPrinter), albeit with fewer features, and we were able to quickly switch to using it for the 4.0 release. Over the course of the next year I added many missing features to the dialog, then worked on adding the other missing features upstream in Qt but so far these contributions have not been accepted. It's not that we don't care, or that we enjoy inflicting sub-standard solutions on users, it's simply that in the 3 years since 4.0 not one single other person has stepped forward to help, leaving it to someone completely lacking in the required skills to muddle through, i.e. me when I find time and motivation. If this stuff was easy it would have been done ages ago. Qt for example had to hire in a number of consultants to write parts of their printing code as they didn't have the required skills either. It's not something people work on for the fun of it. On a brighter note, with Qt5 and OpenGov coming I'm are hopeful that our patches will finally make it into Qt.
On the other hand there is the "Common Printing Dialog"
KDE and OpenPrinting have been talking about the CPD for several years now, and only now is it getting near the point where it may be a viable option in the next 12 months. I attended the OpenPrinting summit this year to discuss how to move the CPD forward and get it into the various toolkits. Unfortunately there is a lack of skilled manpower and funding to get this done at OpenPrinting as well. Discussions are ongoing, especially around whether we can get it integrated into Qt as part of Qt5 and OpenGov which is where it would ideally belong, and trying to find more government funding to get it finished. We have our Platform 11 sprint and the Qt Contributors Summit coming up over the next couple of months where printing is going to be a topic of discussion and we can hopefully develop an action plan that resolves the issues. Just don't expect us to abandon using Qt as the core solution, we just don't have the skilled manpower to do so. John. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org