Diego wrote: > John merged a hack for KDE 4.4, so we won't have to wait for Qt 4.7... > http://www.layt.net/john/blog/odysseus/the_good_the_bad_and_the_ugly > There are some shortcomings but at least the main feature is in place! Yuck! To be honest, I'd have preferred to backport the Qt patch than to ship that. :-/ But API/ABI compatibility is a concern and nobody is prepared to commit to setting the API in stone before the 4.7 timeframe. :-( (The Qt folks would have to do that and they don't give a darn about users' needs, they only care about their policies.) We could backport it anyway, we've backported other unstable APIs in the past (Plasma tooltips in 4.1, for example), but this will hit the whole QPrinter class, so we may end up with stuff using QPrinter not being backwards-compatible when 4.7 hits. Suckage all around, just because of stupid bureaucracy around a freeze and 1 week. :-/ Yet another example of why we need more flexible freezes! What sucks about the hack: * doesn't work when printing to a file (the most serious issue) * supposedly doesn't work with n-up (but isn't odd/even sheets as opposed to pages actually what we want there? Odd/Even is normally used for manual duplex) * mixing ranges and odd/even is also going to be fun: if you print pages 2-5, is "odd" 3 and 5 or is it 2 and 4? (That said, this definition is always unclear. But with the hack, the answer might be different depending on whether the app selects the page range or CUPS does!) * apps have to waste time generating pages which will be thrown away by CUPS anyway That said, I guess we'll pick the hack up anyway when we start shipping KDE 4.4, it's probably not worth deviating from upstream to pick up a better solution, but with an API subject to change. We won't see app support for e.g. printing only odd pages before KDE 4.6 anyway. :-( (Qt is on approximate 9-month cycles, so Qt 4.7 will likely hit in the middle of the KDE 4.5 bugfix cycle, too late to use Qt 4.7 features in KDE 4.5.) Kevin Kofler
