> On Sept. 24, 2013, 1:27 p.m., John Layt wrote: > > Agree to merge this as is, it removes the stuff that would be duplicated in > > the Qt dialog. As for longer-term, I don't see any of those features being > > much used or of much use at all. If I'm wrong and people start complaining > > and can make a reasonable case, then I'll accept them being added into the > > Qt dialog. If any feature will be missed, it would be the Advanced option > > of directly entering CUPS options. I suspect there are some power users > > out there using that to get around some of Qt's short-comings, like > > advanced page ranges "3,7-9,15". However the usability is terrible and > > just shouldn't be done that way. If people make a case for it, then we can > > look at a better ui for it in Qt, e.g. one that has them choosing from a > > combo of valid values. That leaves the convenience api for > > server-side/client-side page selection, which for a one-line code saving is > > really not worth it. The only other reason I can think of for keeping the > > api is if we ever want to re-add a universal KDE tab to the dialog, for example for Color Management. I had a cunning plan for that about a year ago, I need to go dig it up and see what actually needs doing and if I can get away with putting it into Qt instead. If we don't need it for that, then I say get rid of it entirely: we don't know what any future needs might be, so we have no guarantee that the current api will work for that, so lets not lock outselves into something until we actually need to. > > > > Oh, and I need to look at the rationale behind KPrintPreview to see if we > > really need it still.
Ok, let me know if I can help with anything around this. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112909/#review40681 ----------------------------------------------------------- On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112909/ > ----------------------------------------------------------- > > (Updated Sept. 23, 2013, 6:47 p.m.) > > > Review request for KDE Frameworks and John Layt. > > > Description > ------- > > Most of the printing features are now part of Qt 5.2 and basically only 4 > features are left: > - Page Label > - Page Border > - Mirror Pages > - (Advanced) Job Options > - Server-side paging > > I've dropped Job Options as it was quite terrible way to edit/pass CUPS > options directly. Server-side paging is actually just a convenient feature as > with QPrintDialog, apps that can't do paging themselves need 2 lines of code > to set the printing dialog up, thanks to KDEPrintDialog only one line is > needed. The rest I've put under Page Options tab in the print dialog. To be > honest I don't think they are that useful (or used, even) but we have the > code and CUPS support already. If these options were to be dropped however, > I'd drop the whole KDE Print support then as it would become just a > convenient wrapper around QPrintDialog. > > > Diffs > ----- > > staging/kde4attic/src/CMakeLists.txt 4acf1b6 > staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e > staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d > staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d > staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 > staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 > staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 > staging/kde4attic/src/kdeprintdialog.cpp 4722f4c > > Diff: http://git.reviewboard.kde.org/r/112909/diff/ > > > Testing > ------- > > Tested with Konsole5. > > > Thanks, > > Martin Klapetek > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
