Bug 196303

I guess you realize adding a whole printing system (necessary for an own printing dialog, as the Qt API is not enough to do what we had before) requires resources KDE doesn't have at the moment?

Re: Comment #1

I don't really see how this is relevant to the bug report.

I state is the current situaion, and why this bug cannot be fixed soon.

I can understand that, Pino. However, it is something that needs to be done. If KDE doesn't have the manpower for it now then obviously the feature cannot be implemented now, but it should be given consideration in relation to where KDE distributes it's manpower.

Thanks.

KDE printing has to be improved, but this bug doesn't make a lot of sense on it's own and would be really difficult to know when it should be considered "fixed".

Layt recently came out with an interesting insight in what can be done to fix KDE printing:
http://www.layt.net/john/blog/odysseus/back_again_0

The point is, the KDE's current printing system does not live up to the high quality the other components have reached in 4.3. I need to print a lot, and this bug is almost a showstopper for me. I understand that KDE's manpower is limited, but a working print system is a necessity on a modern desktop. 

This bug is not the only one addressing problems with the printing dialog:
https://bugs.kde.org/show_bug.cgi?id=180051

Over there, it has been suggested to consider the common printing dialog:
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog

Could this be used from within KDE?

«And in-between all that, I need to get back in touch with the OpenPrinting guys to work out how KDE can help them in their quest to completely re-architect the way we do printing.»
http://www.layt.net/john/blog/odysseus/the_good_the_bad_and_the_ugly

I suggest to close this bug and then report one bug per feature wich is wanted. For example, I only needed odd/even printing and this is now implemented.

> I suggest to close this bug and then report one bug per
> feature wich is wanted.
> 

That was the original plan, Facundo, however as stated in the OP:
"However, Trolltech is either slow or not interested in added features to the dialogue that KDE users need and expect."

This bug asks that KDE take matters into it's own hands as Trolltech is not implementing the features that KDE users need.

*** Bug 288166 has been marked as a duplicate of this bug. ***

Thanks for working on this. This is the very claimed feature. Please, take a look at the digiKam printing master. It's not ideal and also have some troubles presented in the KDE dialog, but still is much more usable, it is able to print photos without white stripes, which would be very appreciated for gwenview.

Another serious issue is that selecting the media source does not work/has no
effect.

I've been following this bug and several predecessors for a long time.  I know you can't just cut and paste code across applications, but programs like libreoffice and kolourpaint have reasonable print dialogs that just need a few things moved around in the dialogs to make me happy.  Isn't there some way to leverage preexisting code?

(In reply to Facundo Aguilera from comment #8)
> I suggest to close this bug and then report one bug per feature wich is
> wanted. For example, I only needed odd/even printing and this is now
> implemented.

I agree.

There have recently been several improvements in the Qt print dialog (currently in Qt's development branch) and I think it would be helpful to know what exactly is currently still missing or bad, so that actual improvement can be made. (Depending on clear requirements, it can then be decided what the best way to implement this would be and what the right place to address those is...)

(In reply to Michael Weghorn from comment #14)
> 
> I agree.
> 
> There have recently been several improvements in the Qt print dialog
> (currently in Qt's development branch) and I think it would be helpful to
> know what exactly is currently still missing or bad, so that actual
> improvement can be made. (Depending on clear requirements, it can then be
> decided what the best way to implement this would be and what the right
> place to address those is...)

There have been no new replies on this thread for six years... Maybe this is enough evidence that the need for a proper printing dialog does not exist anymore.

I, for one, can confirm that I neither print a whole lot anymore (but "print to PDF" instead). More importantly, I switched to another operating system, so I can't even comment on the improvements in the Qt print dialogue.

Hello alltogether,

the printing dialog right now does its job. It's ok. But afair the old dialog had more features. But it's not that I'm missing much. Back in 2009 I did some manual duplex printing, which was annoying, but can be pretty easy with a good gui. Now almost every printer has a duplex unit built in, so it doesn't matter anymore. Also I don't print much anymore, too. Paper got somewhat obsolete for me.

Thanks for all who have replied.

Given that support for even/odd page selection - the one feature explicitly mentioned in the bug report - is now present in the print dialog, I suggest to close this as WORKSFORME and handle potential further things that may be missing in separate reports.

Unless anybody brings up objections, I will therefore close this bug in a few weeks.

(In reply to Michael Weghorn from comment #17)
> Thanks for all who have replied.
> 
> Given that support for even/odd page selection - the one feature explicitly
> mentioned in the bug report - is now present in the print dialog, I suggest
> to close this as WORKSFORME and handle potential further things that may be
> missing in separate reports.
> 
> Unless anybody brings up objections, I will therefore close this bug in a
> few weeks.

I'm closing this now as said earlier, since no objections were brought up and the requirement initially mentioned (even/odd page selection) is now fulfilled.