[Bug 905147] Re: QPrinterDialog ignores default settings from CUPS
Bug Watch Updater
905147 at bugs.launchpad.net
Tue Aug 28 16:31:48 UTC 2012
Launchpad has imported 101 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=180051.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-01-08T19:02:22+00:00 Gtdev wrote:
Version: (using Devel)
OS: Linux
Installed from: Compiled sources
There needs to be some way to have persistent printer settings. From
looking around on the web, it seems like:
* KDE 4 wants to use whatever Qt provides
* Qt does not seem to provide any useful printer settings tools
The current situation is that KDE defaults to non-duplex color printing,
and completely ignores existing printer settings e.g. from CUPS (fun
enough, it still exposes those settings in the advanced printer setup),
making it necessary to re-select those settings. This is *not* a
wishlist issue, this is instead a regression from pretty much any KDE 3.
The most convenient solution would of course be an applet in
systemsettings.
To get with the expected behavior bulletpoint:
(1) Start System Settings tool
(2) Choose "Printers" or something similar
(3) Be able to configure standards for all settings available in the normal KDE print dialog
Alternatively:
(1) KDE uses defaults from underlying print system, e.g. CUPS
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/0
------------------------------------------------------------------------
On 2009-03-13T19:45:03+00:00 Praveen wrote:
*** This bug has been confirmed by popular vote. ***
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/1
------------------------------------------------------------------------
On 2009-06-26T19:03:17+00:00 Dsteeghs wrote:
Sorry to be a moaner, but I do feel bad about all the paper wasted since
our duplex printers only print duplex if we remember to change the print
options for ALL print jobs. This really is the second most annoying
feature of my KDE4 experience at present.
Surely setting the default to duplex if the printer supports duplex is
an achievable fix that the trees will thank us for? But really, having
settings saved is a rather basic feature.
Any update on this regression is appreciated....
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/2
------------------------------------------------------------------------
On 2009-10-16T18:47:21+00:00 Woelfel wrote:
> This really is the second most annoying feature of my KDE4
experience at present.
I second that.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/3
------------------------------------------------------------------------
On 2009-10-22T11:42:29+00:00 Schmuker wrote:
With version 4.3, KDE4 is now finally an improvement over KDE3 in _all_
areas. If it wasn't for this bug. It is definitely not 21st century
style having to re-select duplex every time I need to print something.
Neither is it good design to ignore the settings in the underlying
backend (cups).
KDE4 should use the duplex settings from CUPS, or at least provide an
option to save the settings in the printer dialog like KDE3 offered it.
Do it for the trees :)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/4
------------------------------------------------------------------------
On 2009-10-27T23:14:51+00:00 8slin wrote:
In Konqueror print dialog >> Options >> HTML Tab the check boxes are
reset each time a page is printed. This is not the behaviour experienced
in 3.5 which remembers the previous settings, which to me is far more
intuitive.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/5
------------------------------------------------------------------------
On 2009-10-28T16:05:08+00:00 Jarauh wrote:
*** Bug 195107 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/6
------------------------------------------------------------------------
On 2009-10-28T16:35:15+00:00 Shoalcreek5 wrote:
Ok, if the other bug is a duplicate of this bug, something funny is
going on. I'm using the same (manufacturer-provided) ppd for CUPS now
that I used in KDE 3.5, CUPS is set to not print duplex by default, the
printer is internally set to not print duplex by default, and yet,
whenever I print from a KDE application, it prints in duplex, long-side,
regardless of what setting I choose in the KDE print dialog. I am
printing to a Brother HL-5250DN. All non-KDE apps (evince,
openoffice.org, iceweasel, etc.) act as they should, printing duplex
only when I tell them to print in duplex. This is most definitely a
regression from KDE 3.5, as KDE 3.5 printing was nearly perfect in every
way with my printer.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/7
------------------------------------------------------------------------
On 2009-10-28T18:23:11+00:00 Guefz wrote:
I see the same behaviour than described in #7 here on my system with a
HP CLJ5550DTN. Even using a PPD without duplex definition results in
duplex printing. I'm running Debian Sid with currently KDE 4.3.2 and qt
4.5.3
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/8
------------------------------------------------------------------------
On 2009-10-29T14:52:18+00:00 Schmuker wrote:
Although this bug has first been reported 3 months ago it is not yet
assigned to anyone. Point is, there is no "About" dialog in the print
dialog, which is where normally developers, maintainers and translators
are credited. Hence, we have no idea who is actually maintaining that
part of KDE (and I have no clue how to find out).
It might very well be that this bug lives a life which is invisible to
the people who could fix it. Does anyone have an idea how to find out
who is working on this part of KDE?
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/9
------------------------------------------------------------------------
On 2009-10-29T15:13:31+00:00 Dsteeghs wrote:
As far as I know, the decision was made not to develop a full-blown KDE
print infrastructure in KDE4, but instead rely on the print infra-
structure provided by QT. I can appreciate the development effort needed
to develop a KDE4 print system, but the problem is that the QT printing
infra-structure is clearly inferior to KDE3 printing and insufficient.
There appears to little development activity on the QT end, while some
KDE4 developers are saying this is a QT problem, not a KDE4 problem. I
think this circular argument of blame is partly responsible for the lack
of progress here. By choosing Qt print infra-structure it IS a KDE4
problem to fix/deal with it, so I would think kde-print-devel to be the
right community.
I wish I had more hands-on help to offer here, but I do find it hard to
understand why printing remains crippled even at KDE4.3.2 while most
other parts of KDE4 have made huge strides. IMHO, deciding to rely on Qt
for printing has proven to be a big problem for KDE4.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/10
------------------------------------------------------------------------
On 2009-10-29T16:19:15+00:00 Gtdev wrote:
IIRC the argument was that the print handling in KDE 3 was unmaintained.
Last I checked, any printing issues were marked to be handled at some
undetermined point in time.
By now, I found it to be a neat solution to just use non-KDE
applications in any area where printing might be necessary. Gnome
somehow manages to at least have a working print settings dialog (i.e.
it works for our environment). However, that does not make this bug any
less annoying.
As for printer settings overriding QT, I can not confirm that, since
over here, QT will always override CUPS/printer settings.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/11
------------------------------------------------------------------------
On 2009-10-29T17:53:00+00:00 Schmuker wrote:
I added a bug report against QT's QPrintDialog.
http://bugreports.qt.nokia.com/browse/QTBUG-5196
Let's see what comes out of that.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/12
------------------------------------------------------------------------
On 2009-10-30T18:18:07+00:00 Hal Engel wrote:
Is anyone considering this:
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog
The OpenPrinting folks have been working on this for some time and it
includes fronts ends in both Qt and GTK+ so the Qt front end should fit
in a KDE environment nicely. The UI is designed by a usability expert
who does this type of work professionally. There have been Google
Summer of Code projects on this for the last two summers and it is close
to being ready for real world use.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/13
------------------------------------------------------------------------
On 2009-11-02T10:29:29+00:00 Schmuker wrote:
There was a reaction on the Qt side: the bug is now marked as a
duplicate of an existing bug:
http://bugreports.qt.nokia.com/browse/QTBUG-3567
This other bug has been reported in February, is unassigned and has no
schedule. So I guess there's nothing to expect from the Qt side anytime
soon.
In the meantime I keep being annoyed by paper waste in my lab, because
all KDE4 users send their print jobs non-duplex. I understand that
printing may not have top priority among KDE developers, but still it
would be nice to see at least some reaction, like acknowledging this
bug, or rejecting it.
The point is, a KDE developer might have more impact on the Qt devs than
some random internet user who reports a duplicate bug. So if some KDE
dev would accept this bug and poke the Qt devs this might save a few
thousand trees.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/14
------------------------------------------------------------------------
On 2009-11-02T10:42:22+00:00 Dsteeghs wrote:
Indeed noticed that and couldn't help but wonder how the duplication was
picked up almost instantly, yet the parent bug is still unassigned, and
surprisingly marked as 'minor' priority. This bug is the highest ranked
'kde-print-devel' bug in KDE's 'most hated bugs' list...
I cannot see a response yet from a KDE print developer, but I would be
interested to see if anyone is actually looking at this bug and to what
extent KDE print talks to QT devel. We are not after more features in
the print dialog at this point, just a way to make them persistent.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/15
------------------------------------------------------------------------
On 2009-11-03T18:21:21+00:00 Schmuker wrote:
Since neither KDE nor QT shows any reaction I submitted a bug against
OpenSUSE (which I'm using). In the past they have been a huge supporter
of KDE, and KDE 4.3.1 will be the default desktop in their upcoming 11.2
release. Perhaps they are more inclined to address printing related
issues than the KDE ot QT team because they also target enterprise users
with their distro.
See https://bugzilla.novell.com/show_bug.cgi?id=552218
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/16
------------------------------------------------------------------------
On 2009-11-20T11:44:47+00:00 C-w-j-lemmens wrote:
Dear fellow KDE4 users,
I solved most of my problems for now by using some workarounds :
1) For our non-KDE programs (firefox, openoffice and some older stuff) I
found a perfect replacement for "kprinter" : gtklp !! Take a look here :
it solved more than half of my problems : http://gtklp.sourceforge.net/
2) To force doublesided printing inside KDE4 applications I used this :
* I downloaded the source of qt-4.5.3 and configured and compiled the whole bunch.
* Then I hacked the src/gui/dialog/qprintdialog_unix.cpp and added this :
— qprintdialog_unix.cpp.org 2009-10-19 20:19:20.000000000 +0200
+++ qprintdialog_unix.cpp 2009-11-19 14:22:08.000000000 +0100
@@ -424,6 +424,15 @@
void QPrintDialogPrivate::applyPrinterProperties(QPrinter *p)
{
+ // Force some decent defaults, e.g. for Duplex printing !!!
+ p->setDoubleSidedPrinting(true);
+ p->setColorMode(QPrinter::GrayScale);
+ p->setPageSize(QPrinter::A4);
+
+ fprintf(stderr,
+ "Using QPrintDialogPrivate::applyPrinterProperties() hack by KL !\n");
+
if (p->colorMode() == QPrinter::Color)
This forces everything to be grayscale, A4 and duplex unless the user
explicitly chooses something else (this is the cheapest for our
department !) The extra fprintf statement is only for me to see that I
am indeed using the hacked library and not the original.
* Then I reran "make" in src/gui to recompile just a new libQtGui
* I copied the modified libQtGui.so.4.5.3 and its softlinks to a
directory /opt/qt-4.5.3-hack/lib/
* Now I had to make sure that each KDE session uses this new library
instead of the original one. I did that by hacking /etc/profile.d/qt4.sh
(or qt4.csh if you wish) and added this at the end :
export LD_LIBRARY_PATH=/opt/qt-4.5.3-hack/lib
* If you then login again each user will use the new libQtGui library
and thus have changed printing settings. I admit it isn't very elegant
and still doesn't remember previous settings but at least we have some
decent defaults now.
Hope this helps some of you until the Qt or KDE people come up with
something more permanent !
Regards,
KL
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/17
------------------------------------------------------------------------
On 2009-11-24T18:27:30+00:00 Paul Cullum wrote:
Is the use of QT for print support mentioned here the reason for the
infuriating bug 174354? Is that bug basically blocked because of this
issue? Every time I print our office printer blocks because it thinks
it should be printing A4.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/18
------------------------------------------------------------------------
On 2009-12-14T00:47:10+00:00 Paul Cullum wrote:
Vote for http://bugreports.qt.nokia.com/browse/QTBUG-6471
This problem has existed for well over a year and they barely notice
that it exists.
There are a lot of bugs opened there trying to explain this problem but
this one seems to be the most clear with code that demonstrates the
problem.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/19
------------------------------------------------------------------------
On 2009-12-14T11:22:32+00:00 Rmj wrote:
Paul
You have my vote on this one in the qt BZ.
I've had problems with the defaults for selecting duplex for ages (which
I think is releated) and have opened, voted for and followed various
bugs at kde and qt o nthe printing system. I really hope
http://bugreports.qt.nokia.com/browse/QTBUG-6471 starts to get some
traction. I can't believe how this doesn't have a higher profile and
some urgency to fix.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/20
------------------------------------------------------------------------
On 2010-01-31T17:46:00+00:00 Jeremy Sanders wrote:
I've got an (ugly) patch which fixes some problems. It sets the duplex,
collation and colour options, in new QPrinter objects and when switching
printers in the print dialog, from the default cups ppd settings.
It doesn't do anything with page sizes (is this a problem for some
people?), doesn't tell cups to use the new options as defaults and
doesn't propagate cups options back from the advanced tab of the
properies tab. These issues could probably be fixed.
It could be improved. Maybe the Qt people would decide whether it is a
useful way to advance. I think this code would probably be best moved
into QPrinterInfo, to make it more general, but I'm wary about messing
with the API, especially as Windows versions might need adding.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/21
------------------------------------------------------------------------
On 2010-01-31T17:46:54+00:00 Jeremy Sanders wrote:
Created attachment 40415
patch to fix some printer issues
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/22
------------------------------------------------------------------------
On 2010-02-01T15:48:02+00:00 Dsteeghs wrote:
Its been over a year since this bug was raised, and its votes now not
only make it the most-hated KDE print bug, but it is also in the top 20
of all most-hated KDE bugs. Its clear that from the user point of view,
this has some urgency to it, yet I struggle to find any activity at
either KDE or Qt that indicates that this is receiving active developer
attention.
Thanks for the suggestive patches, but does anyone have any ideas how
this awareness can be achieved at kde-print/QT since doing the proper
thing of filing a bug and voting for it does not seem to work.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/23
------------------------------------------------------------------------
On 2010-02-01T16:47:02+00:00 Rmj wrote:
I reported kde printing problems in Fedora 10 more than a year ago at
https://bugzilla.redhat.com/show_bug.cgi?id=480954
I was asked to upstream it, which i did by adding comment #12 in
https://bugs.kde.org/show_bug.cgi?id=176999.
This was upstreamed to qt as
http://bugreports.qt.nokia.com/browse/QTBUG-6468 and
http://bugreports.qt.nokia.com/browse/QTBUG-6469
and these are still open. I'm wondering if maybe the problems that we
see in the distro (printing from kde apps has a problems) is too far
removed from the source of the problem, Qt. It takes some effort to
follow these though three bugzillas.
It would be great if someone at kde could champion these issues and help get them resolved. As it is, I have no idea whether the Qt people will ever resolve them.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/24
------------------------------------------------------------------------
On 2010-02-01T16:56:16+00:00 Gtdev wrote:
Thing is, Qt provides a framework. They have a printer widget, it can
print (even if it's bad at it).
KDE wants to provide a productive desktop environment. So they either
use a framework that provides what is needed needed, or they extend an
existing one. The first part obviously doesn't work.
This is not about adding a constant-time prime factorization algorithm,
it's about remembering a bunch of settings. This also isn't about a
return of KDEPrint (oh how I miss thee), it's about remembering a bunch
of settings.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/25
------------------------------------------------------------------------
On 2010-02-01T17:22:17+00:00 Jeremy Sanders wrote:
I'm pretty sure that the right way to save the options is in cups, so
that all applications, including non-qt applications, save these
settings.
I think it's a matter of taking the patch I uploaded above, and modifying it to also save modified settings to the users' lpoptions file with Cups. Indeed Qt, already reads this file when the user clicks on printer properties - just use a command like
lpoptions -p deskjet -o media=Legal
It really needs to be done in Qt, unless KDE wants to have its own
printer dialog (which wouldn't be hard, just inconvenient).
It would be easy to make a Cups printer dialog for KDE. Perhaps it could
be nicer than the default one. However, it wouldn't work under Windows.
It would also make KDE rely on cups, unless you revert to the old one if
it wasn't there.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/26
------------------------------------------------------------------------
On 2010-02-28T03:39:51+00:00 Kevin-kofler wrote:
That patch as is causes
https://bugzilla.redhat.com/show_bug.cgi?id=566304
The offending lines:
+ // set default color
+ if( cups->currentPPD()->color_device )
+ options.color->setChecked(true);
+ else
+ options.grayscale->setChecked(true);
and later:
+ // set default color
+ if( cups.currentPPD()->color_device )
+ setColorMode(Color);
+ else
+ setColorMode(GrayScale);
They should be changed to:
if ( cups->currentPPD() )
{
// set default color
if( cups->currentPPD()->color_device )
options.color->setChecked(true);
else
options.grayscale->setChecked(true);
}
and:
if ( cups.currentPPD() )
{
// set default color
if( cups.currentPPD()->color_device )
setColorMode(Color);
else
setColorMode(GrayScale);
}
(I matched the coding style of the surrounding code.)
I'm going to try changing this in the Fedora package and will attach a
fixed patch if this works.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/27
------------------------------------------------------------------------
On 2010-02-28T04:37:00+00:00 Kevin-kofler wrote:
By the way, your patch doesn't match the coding standards used in the
surrounding code (and Qt code in general) at all. I'm also reformatting
it to match those standards (which also make much more sense to me
personally than yours ;-) ).
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/28
------------------------------------------------------------------------
On 2010-02-28T06:23:00+00:00 Kevin-kofler wrote:
Created attachment 41187
patch to fix some printer issues (fixed)
Here's a version of the patch fixed to not crash when currentPPD is NULL
and reformatted according to the Qt coding style.
Please note that I only know this builds, I haven't done any testing
yet. (But all I changed except for formatting is that I added the checks
for NULL to prevent crashes.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/29
------------------------------------------------------------------------
On 2010-02-28T19:24:58+00:00 Kevin-kofler wrote:
My fixed patch has now been confirmed to work and fix the crash.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/30
------------------------------------------------------------------------
On 2010-10-07T09:56:02+00:00 Hans Meine wrote:
I also suffer from paper wasted because of KDE's print dialogs
defaulting to single-sided printing.
(In reply to comment #26)
> I'm pretty sure that the right way to save the options is in cups, so that all
> applications, including non-qt applications, save these settings.
AFAICS, the situation actually is that the default in CUPS *is* duplex
printing. This *is* used successfully by other programs, just not by
Qt's printing dialog. Actually, there are two ways to configure duplex
mode: one is via the cups properties, available in KDE's systemsettings
and by pressing "properties" right next to the selected printer in the
print dialog. There, duplex is selected. (This is the same thing as in
comment #7 from Brice, only the other way round.)
However, the specialized GUI hidden behind the "options" button, in the
settings tab, defaults to duplex OFF.
Looking at the code, the duplex mode GUI is set up from a QPrinter:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/dialogs/qprintdialog_unix.cpp#line434
I am not sure where the QPrinter comes from in general, and how to fix
this properly. (Maybe introducing a "DefaultDuplex" QPrinter mode which
lets the GUI default to the CUPS setting?)
It actually looks more like a Qt bug to me, too.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/31
------------------------------------------------------------------------
On 2010-10-07T09:59:01+00:00 Hans Meine wrote:
(In reply to comment #30)
> My fixed patch has now been confirmed to work and fix the crash.
While your patch looks sane, I don't think it has much to do with this bug.
(Furthermore, it should be sent to Qt, not KDE.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/32
------------------------------------------------------------------------
On 2010-10-07T10:39:54+00:00 Marcel Dischinger wrote:
IMHO there is a usability problem here. The printing dialog includes two
settings, the Cups printing settings in Properties->Advanced, and the Qt
Printing options in Options. The Qt Printing Options override the Cups
options in any case, which is very confusing.
To fix this, in the GUI, both option menus should be in sync to prevent
"surprising" outcomes. That means, that on startup the Qt Printing
Options should reflect the Cups printing settings (if duplex is the
default in cups, it should be the default in Qt). If I change a setting
in the advanced cups dialog, Qt should reflect that immediately. If I
change a setting in Qt, the advanced dialog should also show that (but
not necessarily change the default setting in cups without asking the
user first).
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/33
------------------------------------------------------------------------
On 2010-10-07T11:39:52+00:00 BajK wrote:
The printing dialog is a mess anyway. Some settings you can set in the menu right away (such as color or black and white printing in kolourpaint and such) but printing mode (draft, normal, foto) is only available under printer settings. And often you cannot even set oritentation to landscape as it is just greyed out.
KDE has such a nice file-open-dialog (which I don‘t think comes from qt directly?) so why not provide a nice printing dialog as well. You have one since Windows 95 and we‘re in 2010 here. (And when configuring my printer with KDE, it always spits out an additional testpage (or an empty one if I am quickly enough at the printer to press cancel) after each printing job)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/34
------------------------------------------------------------------------
On 2010-10-07T11:51:17+00:00 8slin wrote:
I recently reported this bug on RedHat Bugzilla for 6.0 Beta but that doesn't seem to have gone anywhere either.
https://bugzilla.redhat.com/show_bug.cgi?id=587016
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/35
------------------------------------------------------------------------
On 2010-10-07T21:49:03+00:00 Woelfel wrote:
Here is a related problem. Seems to me the source of evil might be the
same, so I'm not filing a new bug report just yet: When I want to print
a landscape document, in the printer dialog under "Properties"
Orientation automatically is set to "Landscape". The image next to it
indicates a correct layout. However, the document is then printed in
"portrait mode", i.e., the landscape contents is printed on a page
that's oriented vertically. Funnily enough, one can fix that simply by
switching the check box back to "Portrait". This is really confusing.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/36
------------------------------------------------------------------------
On 2010-10-07T22:46:36+00:00 Woelfel wrote:
It seems to me that this "duplex printing" bug is not getting enough
attention. The truth is that less experienced users are simply not
printing in duplex. I know what I'm talking about - I have two high-
school kids and a wife who are using KDE. They all waste a lot of paper,
and each time I notice, I explain over and over again that they are
supposed to click on this darn check-box each time they want to print.
>From a non-developer point of view, this bug is embarrassing for KDE -
it should be easy to fix (now, admittedly I don't know what I'm talking
about), but it's not being addressed. Even if the idealistic approach is
to say this should be fixed in QT, this might not be the right way to
deal with it. In particular, when such an (alleged simple to fix) bug
makes it on the Top Ten list of the Most Hated KDE Bugs, I wish a more
pragmatic approach would be applied.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/37
------------------------------------------------------------------------
On 2010-10-07T23:28:28+00:00 Kevin-kofler wrote:
Get your distro to apply the Qt patch from comment #29. Fedora has been
using that patch for months.
Bonus points if you can get Nokia to merge it.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/38
------------------------------------------------------------------------
On 2010-10-08T02:03:54+00:00 Woelfel wrote:
(In reply to comment #38)
> Get your distro to apply the Qt patch from comment #29. Fedora has been using
> that patch for months.
>
> Bonus points if you can get Nokia to merge it.
There is little hope for success. The bug has been reported in OpenSUSE,
but it is closed as upstream (see
https://bugzilla.novell.com/show_bug.cgi?id=552218 )
In fact, fixing this bug downstream on distro level is far from ideal
(it doesn't really help me much, that it's fixed in Fedora). Ideally, it
would be fixed upstream in QT. But I am not very optimistic that this
will happen in the near future (and apparently so are you). So I wonder
whether fixing it on KDE level would be an appropriate and pragmatic
solution. If not, I'm curious why. After all, it is listed as one of
the top ten most hated bugs on the KDE(!) Bug Tracking System.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/39
------------------------------------------------------------------------
On 2010-10-08T07:33:15+00:00 Kevin-kofler wrote:
It is impossible to fix this at KDE level without rewriting the whole
print dialog.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/40
------------------------------------------------------------------------
On 2010-10-08T07:37:42+00:00 Kevin-kofler wrote:
> There is little hope for success. The bug has been reported in OpenSUSE, but it
> is closed as upstream (see https://bugzilla.novell.com/show_bug.cgi?id=552218 )
It was closed as upstream by somebody who doesn't seem to be an openSUSE
packager. Just reopen it and link to the patch here.
FWIW, what KDE can do is to add the Qt patch to the qt-kde tree in git. Several distros ship the Qt patchset from there (I know Fedora does, I'm not sure about openSUSE), so it'd get picked up automatically by those. But I also think that getting that patch (or a better one, if Nokia doesn't like the patch as is) into upstream Qt is the best solution.
By the way, whatever you do, make sure you use the version of the patch I fixed, from comment #29, not the original one which contained a crash bug. (But the credits for the patch should still go to Jeremy Sanders, I only fixed the crasher.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/41
------------------------------------------------------------------------
On 2010-10-08T09:44:14+00:00 Albert Astals Cid wrote:
It can not be fixed in the KDE level, we use Qt for printing so the code
is in Qt repository where we don't have access to commti fixes. So
instead of complaining here that has *zero* effect on getting the patch
fixed go an vote for the existing bugs in qt bug reporting webpage and
open new ones if needed.
http://bugreports.qt.nokia.com/
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/42
------------------------------------------------------------------------
On 2010-10-08T09:50:11+00:00 Albert Astals Cid wrote:
Too early in the morning, when i say "getting the patch fixed go" i
meant "getting the bugs fixed go"
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/43
------------------------------------------------------------------------
On 2010-10-08T10:28:30+00:00 Jeremy Sanders wrote:
This problem can be fixed at the KDE level.
If Nokia decide they don't want to add our patches, or work on the
dialog box themselves, we could make the decision to implement a new KDE
printing dialog box which would replace the Qt one. Applications could
then move to using the new dialog box.
I'd be interested in looking at doing this.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/44
------------------------------------------------------------------------
On 2010-10-08T10:45:14+00:00 Kevin-kofler wrote:
I'd also like to remind you of the existence of
http://qt.gitorious.org/qt/kde-qt , a Qt tree to which all KDE
developers can commit (you need to have an account on gitorious.org and
request kde-developers group membership there), which is shipped by
several distributions. (Fedora ships it as a patchset against Nokia's
Qt. I know we're not the only ones.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/45
------------------------------------------------------------------------
On 2010-10-08T15:04:00+00:00 Hans Meine wrote:
(In reply to comment #32)
> (In reply to comment #30)
> > My fixed patch has now been confirmed to work and fix the crash.
>
> While your patch looks sane, I don't think it has much to do with this bug.
I stand corrected: I had not looked at the attachment, but only at the
diff in your comment (and in comment #30 you wrote "confirmed to work
and fix the crash", but it does not only fix the crash, but actually let
the dialog default to duplex - yeah!).
Your patch is exactly what I had in mind as the necessary solution, so I
applied and compiled it and tried it out - IT WORKS! :-)
> (Furthermore, it should be sent to Qt, not KDE.)
This is still valid; while you might want to try applying to qt-kde, the
policy is that qt-kde should deviate from upstream as few as possible!
Anyhow, thanks a lot for the patch to both Jeremy and Kevin, this really
bugged me a lot!
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/46
------------------------------------------------------------------------
On 2010-10-08T21:06:40+00:00 Woelfel wrote:
Thanks for the comments and explanations (of course, Albert, my
intention was not to complain, but rather to get movement into this, as
this bug will soon celebrate its second anniversary). It's great that a
patch exists, but I still like Jeremy's idea of reimplementing the print
dialog, as the current one has several other problems besides the one
that is, as I understand, addressed by the patch. E.g., those from #33,
#34, and #36. In addition, e.g., the collate option can be set in the
"Advanced Properties" but at the same time be unset in the main print
dialog.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/47
------------------------------------------------------------------------
On 2010-10-14T20:05:24+00:00 Hal Engel wrote:
It appears that OpenPrinting.org may have arranged funding to continue
work on the Common Print Dialog. As more details become available I
will make sure this information is available here.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/48
------------------------------------------------------------------------
On 2010-11-15T13:17:20+00:00 Psychonaut wrote:
I take it kdeprint is now unmaintained. Could this bug be moved to the
new product? I take it this is the print-dialog component of kdelibs.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/49
------------------------------------------------------------------------
On 2010-11-22T17:23:42+00:00 Rauchwolke wrote:
every time i print a paper oriented in portrait - the printer paper
orientation is set to portrait and when i print a landscape pdf the
printer paper orientation is set to landscape - but my printer only has
portrait oriented paper - therefor printing in landscape creates the
wrong output for my printer - so i have to change this setting every
time i print a landscape oriented file...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/50
------------------------------------------------------------------------
On 2010-12-30T09:57:43+00:00 Pino Toscano wrote:
*** Bug 261596 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/51
------------------------------------------------------------------------
On 2011-02-05T22:29:27+00:00 Exabyte-g wrote:
How many issues are covered by this bug? I was browsing through similar
bug reports because of issues with duplex printing, and none of them are
worded well enough to figure out if it is the issue that I'm having. The
issue with the default settings
(http://bugreports.qt.nokia.com/browse/QTBUG-6471) is claimed to be
fixed in Qt 4.6.3 which was released about the time when I bought a
printer and I haven't experienced it, but the override for the duplex in
Options doesn't work for me, and I have to set the duplex setting from
Properties -> Advanced -> Double-Sided Printing (this would also be
http://bugreports.qt.nokia.com/browse/QTBUG-6468 I think).
Anyway, the new QPrintDialog is largely inferior to what KDE 3.5 had.
First, this upstream issues that the upstream seems to be largely
ignoring, then there is the lack of a nice application such as kprinter,
and lastly I can use printing filters any more.
KDE 3.5 allowed me to create booklets and all the crazy stuff with ps
filters such as psnup, etc. None of them worked correctly for me, true,
but I was planning on filing bug reports and/or trying to fix them
myself, and I even got some of them working from the command line. The
lack of ps filters is a major drawback of the new version. I have to
learn to make those from the command line, and store everything in cheat
sheets. With KDE 3.5 I could simply create a new filter that performed
exactly what I was interested in, and then share it with everyone else,
etc.
The idea of using an unified printing framework like
org.openprinting.PrintDialog sounds really nice, but what about creating
KDEPrintDialog that supports all the features kprinter did that I listed
above *and* provides the org.openprinter.PrintDialog dbus interface at
the same time? :) I'm personally voting for that path, if it is possible
at all.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/52
------------------------------------------------------------------------
On 2011-05-24T14:18:23+00:00 Ermonnezza-s wrote:
I have been experiencing this issue since I switched to KDE4. I thought I was just stupid and did not know how to save the settings once for all. I find it
extremely annoying. This definitely gets the maximum votes I can give it.
In my humble opinion:
-default should be duplex if the printer driver supports it (trees matter)
-whatever the default is, the user should be able to save her/his own preference, instead of having to set them again at every single print
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/53
------------------------------------------------------------------------
On 2011-06-10T20:08:16+00:00 E-microcorys wrote:
Is this issue about duplex printing or the more fundamental problem of
Non-Persistent Print Settings in the KDE+QT print system?
There are many bug reports on the disto, KDE and QT trackers with unique
headings that all relate to problems with non-persistent print settings
in KDE apps. For example: KDE Bug 205802 and QT BUG-15351 relate to non-
persistent margin settings.
Installing the CUPS system-config-printer 1.2.5
(http://cyberelk.net/tim/software/system-config-printer/) will allow
Printer related settings, such as Media Size, Print quality, Media Type,
Media Source, Manual Feed, Duplex, Toner Save, Screen Lock & BR-Script
Level, to be changed persistently. (thanks Red Hat!)
But other source related print settings (such as: margins, page
orientation, etc., etc.) are outside scope of this program. These remain
non-persistent and a source of frustration for KDE users. Having to
change 4 margin settings for each print job is a distraction and a big
waste of time. The many 'user' errors (!) that do slip through cause a
shameful waste of paper. The problem is reproducible in many KDE apps,
including Konqueror, Kwrite, Kate and Kmail.
Entering, eg. margin settings, with the CUPS lpoptions command is not
effective in my case (openSUSE 11.4 KDE 4.6). Such 'source related'
print settings tend to be a bit more transient than 'printer related'
settings so having to change them via CUPS may not be desirable, even if
possible.
Perhaps the many bug reports about non-persistent print settings in KDE
+ QT generally should be collated, analysed and actioned strategically?
If so, that needs high level attention from the relevant distributions,
KDE and QT, jointly.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/54
------------------------------------------------------------------------
On 2011-06-10T20:10:15+00:00 E-microcorys wrote:
Is this issue about duplex printing or the more fundamental problem of
Non-Persistent Print Settings in the KDE+QT print system?
There are many bug reports on the disto, KDE and QT trackers with unique
headings that all relate to problems with non-persistent print settings
in KDE apps. For example: KDE Bug 205802 and QT BUG-15351 relate to non-
persistent margin settings.
Installing the CUPS system-config-printer 1.2.5
(http://cyberelk.net/tim/software/system-config-printer/) will allow
Printer related settings, such as Media Size, Print quality, Media Type,
Media Source, Manual Feed, Duplex, Toner Save, Screen Lock & BR-Script
Level, to be changed persistently. (thanks Red Hat!)
But other source related print settings (such as: margins, page
orientation, etc., etc.) are outside scope of this program. These remain
non-persistent and a source of frustration for KDE users. Having to
change 4 margin settings for each print job is a distraction and a big
waste of time. The many 'user' errors (!) that do slip through cause a
shameful waste of paper. The problem is reproducible in many KDE apps,
including Konqueror, Kwrite, Kate and Kmail.
Entering, eg. margin settings, with the CUPS lpoptions command is not
effective in my case (openSUSE 11.4 KDE 4.6). Such 'source related'
print settings tend to be a bit more transient than 'printer related'
settings so having to change them via CUPS may not be desirable, even if
possible.
Perhaps the many bug reports about non-persistent print settings in KDE
+ QT generally should be collated, analysed and actioned strategically?
If so, that needs high level attention from the relevant distributions,
KDE and QT, jointly.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/55
------------------------------------------------------------------------
On 2011-07-27T12:44:01+00:00 Fabian-kislat wrote:
Created attachment 62234
Patch to make okular respect the printers default duplex setting
Apparently the duplex setting of QPrinter defaults to DuplexNone.
Changing it to QPrinter::DuplexAuto fixed the issue for me (see attached
patch).
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/56
------------------------------------------------------------------------
On 2011-07-27T12:55:04+00:00 Kevin-kofler wrote:
That's not the correct solution. QPrinter needs to respect the default set in CUPS. If we override it in Okular,
1. it will only work in Okular and
2. it will ignore the user's setting in CUPS.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/57
------------------------------------------------------------------------
On 2011-07-27T12:55:55+00:00 Kevin-kofler wrote:
The correct solution is the patch to Qt I attached (the fixed version of
Jeremy Sanders's patch).
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/58
------------------------------------------------------------------------
On 2011-08-07T12:13:08+00:00 Dhaumann wrote:
Margins are also not remembered in Kate/KWrite (nor any other KDE
application, afaik). This is a huge issue, see bug #205802. A fix would
make a lot of users happy, but it seems there is no interest, see
https://bugreports.qt.nokia.com/browse/QTBUG-15351
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/59
------------------------------------------------------------------------
On 2011-08-07T12:30:51+00:00 Dhaumann wrote:
Git commit 1aa12bace62fffbcad357623842a0fc01607b3c0 by Dominik Haumann.
Committed on 07/08/2011 at 14:26.
Pushed by dhaumann into branch 'master'.
attempt to work around Qt printing bugs
NOTE: Saving & loading the margins works around QPrinter/QPrintDialog bugs:
- https://bugreports.qt.nokia.com/browse/QTBUG-15351
- https://bugs.kde.org/show_bug.cgi?id=205802
- https://bugs.kde.org/show_bug.cgi?id=180051
Changing the margins now works. However, when you reopen the print dialog
later, the WRONG margins are displayed. The correct ones are still used.
This is a critical bug in Qt.
The real issue is Qt. And it's a critical one. But since it wasn't fixed for
years, it probably will never get fixed. That's why this workaround is better
than nothing...
CCBUG: 205802
CCBUG: 180051
M +43 -1 part/utils/kateprinter.cpp
M +2 -0 part/utils/kateprinter.h
http://commits.kde.org/kate/1aa12bace62fffbcad357623842a0fc01607b3c0
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/60
------------------------------------------------------------------------
On 2011-10-06T14:53:54+00:00 Ermonnezza-s wrote:
Please go en masse to vote for this bug as it seems to be the bottleneck
blocking everything:
https://bugreports.qt.nokia.com/browse/QTBUG-3567
Ask reopening of this bug with a comment:
https://bugreports.qt.nokia.com/browse/QTBUG-6239
Save the trees! Fix this bug! :)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/61
------------------------------------------------------------------------
On 2011-12-19T08:30:27+00:00 luxifer wrote:
I've created an Ubuntu PPA with QT4-libs patched with the patch from
comment #29... you can find it here:
https://launchpad.net/~dhertel/+archive/qtprintfix1
The builds aren't compiled yet but I've already tested them before on
another PPA and they work... just made one for their own because they
take up quite some space :) So they'll be avaliable as soon as Launchpad
has built them...
Cheers
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/65
------------------------------------------------------------------------
On 2012-02-03T01:35:34+00:00 cfr wrote:
*** Bug 293110 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/66
------------------------------------------------------------------------
On 2012-02-03T01:55:05+00:00 cfr wrote:
I don't know about anything being fixed in 4.6.3. It isn't fixed here at
4.8.
In my case, I use multiple printers in different places and need to
remember the settings for each. The vast majority can do duplex. Okular
defaults to single-sided though its properties list for the printer
claims duplex, I think, but the options say otherwise.
So there go some trees.
It defaults to colour though all the printers I use are either B&W or
being used to print B&W. The print dialog is the same for every printer
regardless of the printer's capabilities. There goes some time and
energy.
It gets worse. Some more trees are about to go.
Okular defaults for every job for every printer to US letter paper. None
of the printers I have ever used with this machine have this size of
paper. None of the printers I am at all likely to use with it in the
foreseeable future will have this size of paper. Most of the printers in
the world don't have this size of paper. In most places, including this
one, it is virtually impossible to obtain this size of paper even if,
for some reason, you wish to do so.
CUPS is the right way to do it. Why even include the print settings in
system settings? It has zero effect although it sometimes crashes.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/67
------------------------------------------------------------------------
On 2012-02-03T02:07:44+00:00 Kevin-kofler wrote:
You need the Qt patch from comment #29 or from
http://pkgs.fedoraproject.org/gitweb/?p=qt.git;a=blob;f=qt-everywhere-
opensource-
src-4.6.2-cups.patch;h=e0305e11b89aa6332573a0e9bb955f38038a8123;hb=HEAD
(it's the same patch). (Thanks to Jeremy Sanders for the original patch
which I fixed.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/68
------------------------------------------------------------------------
On 2012-02-10T01:02:28+00:00 cfr wrote:
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...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/72
------------------------------------------------------------------------
On 2012-02-10T04:11:04+00:00 Kevin-kofler wrote:
> I assume that would require compiling QT from sources and configuring things to
> use the hacked library as explained around comment 17?
That's what a distribution is supposed to be for.
> 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.
The patch applies unchanged to 4.8.0. We apply it to the Fedora builds
of 4.8.0.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/73
------------------------------------------------------------------------
On 2012-02-10T07:04:24+00:00 luxifer wrote:
> Is there any reason *not* to consider e.g. the openprinting dialog?
Yeah, I don't see any reason either. The rest of his reasoning is also sound... Now I have to find the KDE-Devel wishlist :-D If there's already a ticket voting for this, please someone point us to that so we can vote, too...
> I assume that would require compiling QT from sources and configuring things to
use the hacked library as explained around comment 17?
Depends on your distribution. On Ubuntu it's just "apt-get source qt4-x11", unpacking it, throwing the patch in the right directory, make a brief edit to 2 files, package the change via a single command and send it to your PPA on launchpad via a single command... After that it's waiting for launchpad to build the packages... When it's done, you can add your PPA as repository and upgrade the packages via apt... dunno if Fedora has such facilities...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/74
------------------------------------------------------------------------
On 2012-02-10T07:07:28+00:00 Kevin-kofler wrote:
> dunno if Fedora has such facilities...
Fedora already carries the patch in its official Qt packages.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/75
------------------------------------------------------------------------
On 2012-02-10T07:12:27+00:00 luxifer wrote:
> Fedora already carries the patch in its official Qt packages.
nevermind... I must have understood reescf at gmail.com as such that his distro was fedora somehow... it's still early in the morning and I've only had one coffee yet :-)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/76
------------------------------------------------------------------------
On 2012-02-10T14:41:07+00:00 cfr wrote:
I'm using Arch Linux and Arch is going to say (rightly, I think) that
this is an upstream bug...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/77
------------------------------------------------------------------------
On 2012-02-10T14:44:31+00:00 cfr wrote:
In any case, even if I did use e.g. Fedora, as far as I can tell the
patch wouldn't help very much. I'd still be stuck with default letter
paper and without access to quality settings needed to get output on
some of the printers I use.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/78
------------------------------------------------------------------------
On 2012-02-11T02:55:22+00:00 AT wrote:
I applied the patch from the PPA given in comment #62. A couple weeks
later I made the mistake of accepting a bunch of updates, one of which
was to the qt4 libraries. This of course brought the bug right back.
Understandably, the PPA hasn't been updated to this version yet. Is
there a way I can downgrade to the PPA version without breaking
everything in my system? I'm worried about messing with such a large
number of packages, but I really need to have default settings for my
printers, its an absolute nightmare not having it.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/79
------------------------------------------------------------------------
On 2012-02-11T05:03:51+00:00 luxifer wrote:
@reescf: we use a4 per default and the qt print dialog doesn't default
to letter... did you set a4 in /etc/papersize? Also: Sure this is an
upstream bug, but as in my filing on Launchpad, I'd say it doesn't
matter. Those distros incorporate lots of patches to their packages so
this is not excuse. What's more: The users don't care and they shouldn't
have to. The patch doesn't fix the underlying problem but it does fix
99% of the annoyance. And with distros like Ubuntu and Arch, still
behaving like douchebags in that matter, acceptance for Linux on the
desktop takes a hit for affected users...
@Alex: I'll update it as soon as I've got some time for it... I also
filed a bug on Launchpad against qt4-x11 and hopefully they incorporate
the patch in their next release... It's gonna be an LTS release after
all...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/80
------------------------------------------------------------------------
On 2012-02-12T02:19:58+00:00 cfr wrote:
(In reply to comment #74)
> @reescf: we use a4 per default and the qt print dialog doesn't default to
> letter... did you set a4 in /etc/papersize? Also: Sure this is an upstream bug,
> but as in my filing on Launchpad, I'd say it doesn't matter. Those distros
> incorporate lots of patches to their packages so this is not excuse. What's
> more: The users don't care and they shouldn't have to. The patch doesn't fix
> the underlying problem but it does fix 99% of the annoyance. And with distros
> like Ubuntu and Arch, still behaving like douchebags in that matter, acceptance
> for Linux on the desktop takes a hit for affected users...
I don't have an /etc/papersize. I have never, ever used letter size
paper from this machine. I do have a US-with-Euro keyboard but that's
it. All printers I use, even CUPS PDF, are set to default to A4 in CUPS,
texlive is set to default to A4, all my documents are produced for A4.
But I have to set A4 in the QT print dialog every time.
Arch will only patch to fix "serious breakage" and even then, they'd
rather not. My understanding is that Arch does not include an enormous
number of patches in the way that Debian, Ubuntu etc. do. Whatever you
may think of that policy, it is unfair to accuse them of being
"douchebags" on grounds of inconsistency. Ubuntu may be inconsistent on
this but I can't see Arch is.
Also, I don't think that high a proportion of Arch users use KDE.
If you think not fixing it is problematic because of the hit on users,
why doesn't KDE fix it or push for QT to fix it?
You should at least get rid of the "Advanced" tab in the print dialog.
Since the settings there have no effect on anything, it is simply
confusing. Better to just have the QT options and a note saying, "We
know that these options don't reflect the capabilities of your printer
or your CUPS defaults. We know they don't reflect the settings you
customised via KDE's own print settings control module. (We put that in
just to tease!) We should also tell you that any changes you make will
be immediately lost and will need to be reset for every document you
print. But that's somebody else's problem. We're not sure whether QT or
your distro should fix it but we know we're not going to. If you don't
like it, use GNOME."
At least that would be straightforward.
Of course it puts me off Linux. I've just switched from OS X and you're
telling me I have to compile QT from scratch to get my print settings to
stick?!
If I'm fair, though, it puts me of KDE more than it puts me off Linux.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/81
------------------------------------------------------------------------
On 2012-02-12T03:23:54+00:00 Ivo Anjo wrote:
(In reply to comment #75)
@reescf: I agree with you that it is very sad that many years after KDE 4.0.0 and printing still completely and insanely sucks.
But, if you distro doesn't do what needs to be done, have you considered
switching distros? You don't have to be put off Linux or KDE because of
this issue. You could just be put off Arch.
Finally, and again, this has been this way for
manymanymanymanymanymanymanymany years. I don't think arguing about this
further on bugzilla is going to help a lot. We just have to either do
it, or wait for those who can to do it (or offer incentives to help
motivate those who can).
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/82
------------------------------------------------------------------------
On 2012-02-12T08:14:25+00:00 Kevin-kofler wrote:
> Arch will only patch to fix "serious breakage" and even then, they'd rather
> not. My understanding is that Arch does not include an enormous number of
> patches in the way that Debian, Ubuntu etc. do. Whatever you may think of that
> policy, it is unfair to accuse them of being "douchebags" on grounds of
> inconsistency. Ubuntu may be inconsistent on this but I can't see Arch is.
As much as sticking close to upstream makes sense in principle (it is
also a Fedora policy), it doesn't make sense to make a religion out of
it, the highest priority should be on making things work for the user!
Otherwise, what do we even have a distribution for? A distribution which
just redistributes unmodified upstream code is useless.
With that said, the paper size should already be read off CUPS settings by the existing Qt code. See QTBUG-6471, which got resolved in Qt 4.7.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/83
------------------------------------------------------------------------
On 2012-02-12T10:08:02+00:00 luxifer wrote:
@reescf: try installing libpaper and running "paperconfig -p a4" as
root... and I didn't mean to accuse only arch... the same goes to KDE
itself... if KDE just use this patch in their QT version or if they
switched to and supported openprinting alltogether the problem would be
fixed for all... but apparently KDE doesn't consider this a serious
issue... Now with Gnome2 dead, XFCE too rudimentary for many and KDE
with broken printing, what's left for Linux on the desktop?
So I guess this still makes sense to discuss here. It's still a valid
bug in KDE. The bug in the code may be in upstream but the bug in
usability is in KDE and that's the point.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/84
------------------------------------------------------------------------
On 2012-02-16T00:53:41+00:00 cfr wrote:
Thanks. I did that. I also deleted printers I'm not using and set a non
CUPS_PDF printer as default. I think the papersize is now right. I now
only see this option in the "properties" dialog and not the "options"
dialog. But it still, naturally, ignores duplex/greyscale etc.
Somebody else using KDE on Arch claims that his settings (as made via
KDE's printer kcm setup) do persist and do determine default printing in
Okular etc. However, I checked the build file for QT on Arch and it
definitely doesn't use the patch, so I'm not sure how this is even
possible.
Personally, I think KDE should move to the openprinting dialog. Even
patched, the QT dialog is going to be unsatisfactory because it is
insensitive to the actual capabilities of the printers installed and
divorces printing from KDE apps from the KDE CUPS interface (which is
billed as a way to configure printing and not merely as a way to
configure CUPS). I don't really understand why the QT print dialog isn't
regarded as *obviously* unsatisfactory and, for a sophisticated DE like
KDE, *embarrassingly* stone-age.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/85
------------------------------------------------------------------------
On 2012-02-16T23:22:32+00:00 Adam Porter wrote:
What all this confirms for me is that KDE is basically a developer
playground. I feel like none of the devs in the KDE project care
whether KDE is actually a good DE, whether it's suitable for general,
widespread use, or whether anyone but themselves use it. (This may
not be the case, but I feel like it generally is.)
KDE needs some by-example leadership. Some devs need to step up and
fix the important bugs that are not fun to fix. Doing so would make
KDE viable as an alternative to Windows and OSX for average users and
enterprises. Unless this happens, KDE will languish in obscurity.
And maybe that's ok with the devs. Maybe they're fine with a
take-it-or-leave-it approach. Hey, they're just volunteers who
scratch their own itches, and that's their prerogative. But it's a
shame, because KDE could be so much better. It has the potential to
be a Free Desktop that actually competes with Microsoft and Apple.
And it's not about "sticking it to the man" or anything like
that--it's simply about doing it better, in an open and Free way, for
the good of others.
At least, that's how I think it ought to be.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/86
------------------------------------------------------------------------
On 2012-02-17T07:11:26+00:00 luxifer wrote:
@Adam: This is not true. IMHO the KDE devs care MOST whether KDE is
actually a good DE... KDE4 has become quite brilliant if you leave this
unspeakable bug out of consideration. Now look at the other major DEs as
of lately. At least KDE provides massive extensibility and customization
features while still providing sane and sensible defaults AND providing
a nicely working integrated experience if you use the KDE apps. No other
DE does that... not even remotely! Think about it for a moment...
It would be nice though if an actual KDE dev would post something
ontopic here...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/87
------------------------------------------------------------------------
On 2012-02-17T07:21:19+00:00 luxifer wrote:
Also maybe someone should edit this bug... Severity should be Major
instead of Normal.. From the guidelines:
Normal: regular issue, some loss of functionality under specific circumstances
Major: major loss of function
For this bug makes not only "some" loss of functionality and not only
under "specific" but rather generic curcumstances, "Normal" doesn't cut
it...
ALSO: DEAR KDE DEVS: Why not at least assign this to someone? Status
"NEW", really? For THREE YEARS?
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/88
------------------------------------------------------------------------
On 2012-02-17T10:37:41+00:00 Marcoep wrote:
Hi all,
Just my two cents, with disclaimer of heavy off-topic derailments.
I've been loving KDE since its inception, when hovering the mouse
pointer over the 'K' start button used to pop up a tooltip saying "Where
do you want to go tomorrow?"... 'tomorrow', I guess it meant 'progress'
wrt to M$ Windoze.
Now, sadly, I don't see any more that desire to really improve things, at least not for my not-so-powerful laptop: it's mostly about eye candy, rather than functionality. I know there's plenty of good stuff under the hood, but, jeez, where is it? In order to have a functional DE capable of booting in less than an... age, I had to:
- disable all desktop effects -- and that's annoying 'cause I need the zooming feature as my sight, like my laptop, is a bit defective;
- split all the KDE virtual gentoo ebuild, to get rid of that plethora of useless/misbehaving apps and bits -- above all, akonadi and nepomuk... actually, those are not useless, though so buggy that the frontier is fuzzy.
- spend hours at no avail trying to synchronize all my mail/contacts/calendar with gmail + my nokia smartphone. Then, defeated, I decided to remove akonadi & Co...
And still every now and then I must tidy up my ~/.kde folder where config junks accumulates like dust over scaffolds.
Where are we heading to? I don't believe in stupid OS/DE wars. I do believe in progress, cooperation and good management, even geeky and nerdy if you want, but *real*, i.e. one that makes things move forward.
I think that if we can just make it functional, without comparing it to anything else (who really cares when it's free?), that will be progress. What others do should be source of inspiration rather than term of comparison. F***ing hell, libre/open-source SW is not about *competition*, it's about FREEDOM and COOPERATION. Personally, I wouldn't want a MacOS clone; I couldn't care the less because I already decided that my life must be, as much as possible, proprietary-SW-free, so I don't need the illusion of owning what I cannot afford to buy (my salary, fortunately, would allow much more than that). The problem is convincing those who consider eye-candy stuff a paragon that they don't need it: priority is having good tools.
But this policy of just "good looking stuff" is making much of these
efforts vane. Even though the recent Qt/Nokia debacle had a part in all
this, I say, hey, now that's back and free to the community, let's take
a chance to start think differently.
IMHO, KDE folks should look a bit closer at the development process of,
as for my viewpoint, more stable projects, like Mozilla products. We
users, keep on posting, prodding and proposing! As for this bug, I think
that the priority is OK: as far as I can understand, there's a
workaround... annoying, yes, but that's it.
Sorry for venting my frustration... I hope nobody got offended.
Cheers,
^s
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/89
------------------------------------------------------------------------
On 2012-02-17T12:43:37+00:00 luxifer wrote:
@sphakka: what the hell? that wasn't even remotely on-topic but one
sentence... and that one showed how little you cared to learn about the
topic. I wouldn't call a hackish patch for recompiling the whole goddamn
Qt framework a "workaround"...
The rest was just off-topic. Why you bitch about how current software
doesn't run smoothly on ancient hardware it beyond me, especially since
your salary, fortunately, would even allow for much more than a new
Macbook. Also beyond me is what you need the magnifier from the effects
for when there are tools that work without those or you could just
increase the DPI setting.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/90
------------------------------------------------------------------------
On 2012-02-17T13:01:44+00:00 vidak wrote:
It seems you didn't really get the point. KDE puts more effort to eye
candy than to functionality. That might be the reason, why this bug is
here, after three years, being the second on the 'most hated bugs' list.
Relatively small thing, but really annoying, convincing the users to
leave KDE sooner or later.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/91
------------------------------------------------------------------------
On 2012-02-17T13:22:14+00:00 luxifer wrote:
I think the more probable reason is that no relevant KDE dev knows about
or feels responsible for this bug. Because Printing is handled by Qt.
And the responsibility for Qt lies at Nokia. Problem solved. Also this
bug is not a "relatively" small thing... don't let the patch misguide
you to that conclusion. the patch is a hackish fix which works for 99%
of the people but doesn't fix the underlying problem properly...
Sure this bug will drive lots of people away as soon as Gnome3 has
become mature and customizable enough and provides good working
extensions to get back to a desktop metaphor...
How you percieve KDE to put more effort into eye candy than into
functionality is beyond me however. After all the looks didn't change
much since KDE 4.0 - they just stabilized the effects over time. However
in the same time they fixed and improved a lot of the inner workings of
KDE and the applications it comes with. While all doing this they still
managed to come up with sane defaults end excelent integration...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/92
------------------------------------------------------------------------
On 2012-02-17T13:47:24+00:00 Mskala+kdebugs wrote:
The wrong paper size on every single job, requiring a manual override
individually on every single job, is not a "sane default." Providing
two configuration dialogues for the same feature, one of which has no
effect, and ignoring the configuration set elsewhere by the operating
system component responsible for such things, is not "excellent
integration."
The big picture of KDE's general development philosophy is interesting,
but let's not lose sight of the simple bug that is the reason we're
gathered here: CUPS provides default printer settings, which KDE
ignores. KDE should read and use CUPS's default printer settings. That
shouldn't be complicated or controversial.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/93
------------------------------------------------------------------------
On 2012-02-17T14:00:22+00:00 luxifer wrote:
@Matthew: right, it's not a "default" at all... a default is a
configuration setting... what you describe is a bug that's causing
unexpected behaviour... you confuse that... also: for the paper size
problem using and setting up libpaper seemingly worked for reescf...
what's more: this is a Qt bug, not a KDE bug... while KDEs ignorance on
this one hurts everyone you should really blame Nokia for not fixing the
bug...
And again:
1. The bug is in no way "simple".
2. The bug is not within KDE but in Qt.
3. Qt is owned and maintained by Nokia.
4. Nokia has known this for 3+ years and ignores it as well.
What you could blame KDE for though is to be so stubborn about not
diverging from upstream Qt in this case. They have good reasons not to
do this easily but in this case the patch and therefor the risk isn't
very big but well understood and should be outweighted by the advantages
that it brings. So this is not a technical issue but a policy/political
issue and THAT's what makes it so frustrating...
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/94
------------------------------------------------------------------------
On 2012-02-17T23:03:01+00:00 Francesco+kde wrote:
Q:
>Hi list,
> there is a rather heated discussion in a 3 years old kde bug [1]
>regarding printing, more specifically the print dialog and how it should
>keep/save settings between different call of it.
>
>Could you (as somebody involved in qt5 planning or development) clarify
>what the plan are for printing functionality, managment or whatever?
>
>Expecially a statment like "printing will no be managed by qt" could be
>helpful, pushing somebody to take responsibility for it and solve the
>problem.
>
>best regards,
>Francesco Riosa
>
>[1] Bug 180051 <https://bugs.kde.org/show_bug.cgi?id=180051> - [KDE4]
>Need a way to have default printer settings
A:
Currently we continue to have the Qt 4 printing subsystem in Qt5 (as
libQtPrintSupport), but the longer term plan is to replace this with a new
module, as some of the basic architecture of the old printing module is
not fixable.
For 5.0 however we continue with what we have.
Cheers,
Lars
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/95
------------------------------------------------------------------------
On 2012-02-18T09:12:27+00:00 luxifer wrote:
So there you have it... we'll have a working print dialog by the time we
have flying cars... guess printing dialogs are np-hard... so, kde...
finally ready to give up qt for printing?
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/96
------------------------------------------------------------------------
On 2012-02-18T16:52:08+00:00 Francesco+kde wrote:
I had the following today:
>
> I'm the new community maintainer for printing support in Qt, so I can fill you
> in on some of my plans. You can find a more detailed description on my blog
> at http://www.layt.net/john/blog/odysseus/kf5_localization_and_printing_plans
>
> As Lars has explained, the Qt4 print module has been cleaned up a little in
> Qt5 but we do not plan to add any new features to this code in the future.
> Instead we are planning a new module for 5.1 or 5.2 that conforms to modern
> printing standards and features. However that is a long time for KDE4 apps to
> wait for the missing features and bug fixes.
>
> My current work plan is to complete the last few localisation features needed
> for Qt 5.0, then to move on to a bug triage on the QPrintSupport module to get
> it ready for 5.0. The bug fixes here will where possible be back-ported to Qt
> 4.8. For example, I really want to get the CUPS settings bug fixes in to 4.8.
>
> Once that work is done, I plan to fork off a Qt4 version of QPrintSupport and
> apply on top of it my old patches for adding many of the currently missing
> features. Once that is stabilised I'll release it as an interim experimental
> print library that KDE4 apps can use if they want.
>
> From there I plan to start working on the new print module, which we will hold
> design session for at the next Qt Contributors Summit. Hopefully it will be
> ready for Qt 5.1 and so the first full release of KDE Frameworks 5.
>
> I hope that answers a few of your questions.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/97
------------------------------------------------------------------------
On 2012-02-20T00:33:44+00:00 Ncoghlan-5 wrote:
Thanks for the additional information Francesco. Unfortunately,
searching for "QPrinterNG" suggests that the plan of improving the
situation for KDE 4.8 never came to fruition (and the Feature Plan for
4.9 doesn't appear to include anything along those lines, either:
http://techbase.kde.org/Schedules/KDE4/4.9_Feature_Plan).
I don't print very often, so the status quo is a minor irritation rather
than a huge problem for me, but it would still be very nice to see this
fixed. (I suspect many developers are in the same situation of only
rarely printing things out, hence the historical lack of attention to
critical printing problems like this one)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/98
------------------------------------------------------------------------
On 2012-02-23T00:03:35+00:00 cfr wrote:
It is certainly good to know that some attention is planned to be given
to this issue at some point. However, I cannot help but feel the the
severity of this bug is not appreciated by the developers.
Everyone here admits that the patches available are horrible hacks and
do not address the underlying issues. But as I understand it, they would
dramatically improve the experience for many users. What is the reason
*not* to use the patch as a temporary fix until you have time to address
the issue more thoroughly? I realise that there is a lot to be said for
doing a job right but there is also a great deal to be said for solving
a problem sooner rather than later.
I just don't understand the reasons not to use the patch. It is there.
Somebody has written it. People have tested it. Why *not* use it? Maybe
it is a sticking plaster but if it can cover up some of the mess which
is the current printing dialog, why not use it? I could understand it if
the patch had to be developed from scratch but that's not the case. Is
it a reluctance to use a less elegant, uglier patch (as everyone admits
this one is)? But the current dialog is, frankly, hideous. So something
hideous is better than something ugly if the former can be blamed on
somebody else while you would feel responsible for the latter? Is that
it? If so, I recommend a more utilitarian perspective...
I'm also intrigued that the plans appear to include sitting down to
design a new printing interface when openprinting appears to be a good
way along the path to developing an excellent one. As far as I can tell
- and I am certainly no expert - a great deal of effort is going into
ensuring that that design actually works for users rather than merely
seeming to the developers as though it should. I am not suggesting that
KDE does not have people who know what they are doing in GUI design -
clearly this would be grossly unfair. But can you really hope to put the
same level of effort into designing one element of the overall system?
And, even if you can, why should you duplicate that effort rather than
putting those efforts into other areas?
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/99
------------------------------------------------------------------------
On 2012-02-23T00:17:02+00:00 cfr wrote:
I see that there may be some integration with openprinting. This is
presented as a cups/linux vs. windows/osx issue. But presumably it is a
cups/linux/osx vs. windows issue since osx uses cups as far as I know.
(In fact, cups started there as far as I know.)
My concern about this is that what will end up mattering is that it
works on windows. Whether it works with cups or not will, once again, be
considered a minor issue of little importance.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/100
------------------------------------------------------------------------
On 2012-02-23T05:17:32+00:00 luxifer wrote:
I fully agree with reescf... I also want to add some perspective to the
windows issue:
IMHO KDEs Windows/OSX ports are a "nice to have" but I can't imagine
that these have significant user counts. It's the Linux desktop that
draws in the most users, I guess. This is especially true since Gnome2
is dead now.
On the other hand I can't imagine an OSX user who'd mainly use KDE - I
wouldn't know what for... The same is true for Windows. I use KDE for
Windows only for Kile and I don't care for printing. Under Linux this is
a completely different story though.
So I share reescfs concern and I'd really like to know - if it's true -
what justifies this stance. Why do the developers think Windows and OSX
are so important? Windows and OSX users WILL NOT use KDE as default
desktop environment. Don't know about OSX but in Windows one reason for
this is that the current implementation suffers from more fundamental
flaws like the mediocre installer and unstable runtime.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/101
------------------------------------------------------------------------
On 2012-03-11T17:10:03+00:00 cfr wrote:
I've never used KDE on OS X. (kile was probably *the* reason I chose KDE
on Linux - on OS X, I use TeXShop.) I've never known anybody use KDE on
OS X.
But as far as this bug is concerned, OS X integration should follow
automatically from Linux integration. Both use CUPS for printing.
(Unless Apple have stopped using CUPS in later versions of the OS. I
haven't checked, but I would be extremely surprised if they have.)
To reiterate, I still haven't heard any reason not to use the available
patch as a temporary, albeit hackish, work around. "Get somebody else to
apply it" or "somebody else could apply it" is not a reason. I'm not
saying it is a poor reason. I'm saying it is not a reason at all. It is
simply irrelevant.
Given that the promised fixes have not made it into 4.8 and that QT 5 is
likely to have just the same setup, complete with bugs, as QT 4, I
suspect that a "proper" fix is years, probably decades and possibly
centuries, off. That makes the case for the temporary fix all the more
compelling.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/102
------------------------------------------------------------------------
On 2012-03-11T18:37:40+00:00 Kevin-kofler wrote:
KDE cannot apply this patch because they discontinued the repository
whose purpose was to carry exactly this kind of patches, the kde-qt
repository. (git.kde.org now carries a 1:1 mirror of the
qt.gitorious.org repository instead.)
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/103
------------------------------------------------------------------------
On 2012-03-12T06:31:19+00:00 luxifer wrote:
@reescf: Exactly!
@Kevin Kofler: So? What's the sense of having a 1:1 clone of another
repository? Why have an own repository at all then? Why use git then
after all? That's not a reason but an excuse and a poor one on top of
that.
Plus: This fix is likely to work as long as the bug stays this way so
there'd much likely be no trouble applying it to future versions of QT
that carry this bug. It's a no-brainer, really. Is the KDE board even
aware of this issue and how serious it and its implications are?
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/104
------------------------------------------------------------------------
On 2012-03-12T07:09:32+00:00 Kevin-kofler wrote:
> @Kevin Kofler: So? What's the sense of having a 1:1 clone of another
repository? Why have an own > repository at all then?
Don't ask me! I've always said that dropping kde-qt was a mistake and
this is an example of why.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/105
------------------------------------------------------------------------
On 2012-03-12T12:51:35+00:00 Schmuker wrote:
Just want to point out that OpenSUSE has fixed the issue in their distro
already more than a year ago (see also comment #16).
https://bugzilla.novell.com/show_bug.cgi?id=552218
Maybe those of you using distros without the patch should consider
bugging your distributors to include it. Point them to OpenSUSE and that
they _have_ the patch.
Chances are that at some point the insight will percolate that it would
be much more efficient to include the patch upstream instead of having a
copy of it in every distribution. AFAICT rants in this bug report have
gotten us nowhere and are not very likely to get us anywhere in the
future.
Reply at: https://bugs.launchpad.net/qt/+bug/905147/comments/106
** Changed in: qt
Status: Unknown => Confirmed
** Changed in: qt
Importance: Unknown => Medium
** Bug watch added: Novell/SUSE Bugzilla #552218
https://bugzilla.novell.com/show_bug.cgi?id=552218
** Bug watch added: Red Hat Bugzilla #480954
https://bugzilla.redhat.com/show_bug.cgi?id=480954
** Bug watch added: KDE Bug Tracking System #176999
https://bugs.kde.org/show_bug.cgi?id=176999
** Bug watch added: Red Hat Bugzilla #566304
https://bugzilla.redhat.com/show_bug.cgi?id=566304
** Bug watch added: Red Hat Bugzilla #587016
https://bugzilla.redhat.com/show_bug.cgi?id=587016
** Bug watch added: KDE Bug Tracking System #205802
https://bugs.kde.org/show_bug.cgi?id=205802
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to qt4-x11 in Ubuntu.
https://bugs.launchpad.net/bugs/905147
Title:
QPrinterDialog ignores default settings from CUPS
To manage notifications about this bug go to:
https://bugs.launchpad.net/qt/+bug/905147/+subscriptions
More information about the kubuntu-bugs
mailing list