GNOME Bugzilla – Bug 519317
Unix print dialog should not use GtkDrawingArea
Last modified: 2012-05-26 03:20:49 UTC
GtkDrawingArea has it's own GDK output window and its background is not nicely drawn by many themes. It is currently used in two places in GtkPrintUnixDialog. You can see the problem in the screenshots attached to bug #519059: http://bugzilla.gnome.org/attachment.cgi?id=106070&action=view Look how the image in the Collate box is drawn on a different background than the rest of the window. A similar problem exists on the "Page Setup" tab.
Created attachment 106167 [details] [review] simple patch to fix this issue
The attached patch changes the code to use a GtkEventBox instead of GtkDrawable and to draw on the parent window. Actually, GtkEventBox is still overkill for this as we are not interested in receiving any input events. Perhaps GTK+ should provide a dedicated widget for this. But that's another issue... Please give your OK to commit this change and decide if it should also go into the stable branch.
I don't see how this is not a theme problem ? Of all the themes I have installed here locally, only one exhibits this problem. And there is nothing to stop another theme from causing the same problem with an event box, afaics.
An event box doesn't draw it's own background while a GtkDrawingArea does this. You can only see this with themes that draw a non-uniform background. But there is nothing the theme could do about this. The bug is clearly that GtkUnixPrintDialog is abusing a GtkDrawingArea here when it should render on the background window.
Created attachment 106554 [details] [review] different approach, changes GtkDrawingArea to have a GTK_NO_WINDOW mode Havoc suggested a different approach on the mailing-list and I like his idea. The attached patch changes GtkDrawingArea to respect the GTK_NO_WINDOW flag. It also changes GtkPrintUnixDialog to set this flag.
(In reply to comment #5) > Created an attachment (id=106554) [edit] > different approach, changes GtkDrawingArea to have a GTK_NO_WINDOW mode Shouldn't you add API to get and set the NO_WINDOW mode like in GtkFixed?
I don't see anything wrong about using the existing API for this. But if there's need for such an API, it can of course be added.
(In reply to comment #7) > I don't see anything wrong about using the existing API for this. But if > there's need for such an API, it can of course be added. > Right, GtkFixed actually says its API is there for compatibility reasons. I just thought it would be good for consistency and discoverability. You could also allow the set function to be used after realize, like in GtkEventBox, but I guess the usefulness of that is a bit questionable.
2008-05-25 Sven Neumann <sven@gimp.org> * gtk/gtkdrawingarea.c (gtk_drawing_area_realize) (gtk_drawing_area_size_allocate): respect the GTK_NO_WINDOW flag and don't create an output window if it is set. * gtk/gtkprintunixdialog.c: set the GTK_NO_WINDOW flag for the drawing areas. Fixes bug #519317. We should probably add API to GtkDrawingArea as suggested in comment #6. I am keeping this report open. Will attach a patch soon...
The API from GtkFixed is definitely not needed here. But something like the "visible-window" property might be useful here. Please ask me to provide a patch if you think that such an API is needed.
(In reply to comment #9) > 2008-05-25 Sven Neumann <sven@gimp.org> > > * gtk/gtkdrawingarea.c (gtk_drawing_area_realize) > (gtk_drawing_area_size_allocate): respect the GTK_NO_WINDOW flag > and don't create an output window if it is set. The documentation for GtkDrawingArea should mention this change. It is a very common complaint that the GtkDrawingArea background has the "wrong color."
Can you provide a doc patch ?