GNOME Bugzilla – Bug 368234
Incorrect tabs rendering during reorder with rounded themes
Last modified: 2018-02-10 03:33:20 UTC
I'm not really sure if this bug belongs to gtk+ or gtk-engines, but I've got the feeling that it belongs to gtk+, as the engines methods should only care to paint what they're told (in this case tabs) independently of the context. Now the bug: when tabs reordering happens, the dragged tab is painted to a rectangular GdkWindow, if the theme paints rounded tabs, black corners can be seen during the operation. I'm going to attach a workaround that previously paints the window with bg[GTK_STATE_NORMAL], ideally those would have to be transparent (or the window shaped), but I've found the following issues: 1) GdkWindow obeying alpha transparencies in a cairo_t requires an ARGB colormap and compositing enabled, otherwise it paints a black region. 2) gdk_window_shape_combine_mask() is hard to use here, the tab is painted inside the engine and (AFAICS) we can't guess reliably the GdkBitmap mask from a cairo_t for a fix that works in most of the environments, couldn't parts with alpha 0.0 in the cairo_t be treated as the shape mask? Maybe this belongs to a distinct bug to gdk, I'll attach the workaround...
Created attachment 75718 [details] [review] workaround
Hello dear gtk+ maintainers, would it be possible to review the patch previously attached ? thank you.
Patch 75718 applies cleanly. Reviewing it would take little time. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
*** Bug 488809 has been marked as a duplicate of this bug. ***
*** Bug 499187 has been marked as a duplicate of this bug. ***
I've noticed good rendering in Firefox, but Firefox is not using GTK natively, so this is funny :> .
Video: http://up.wklej.org/download.php?id=900c563bfd2c48c16701acca83ad858a
The workaround looks ok to me, as long as you add a comment explaining that this is a a workaround to make themes with rounded tabs not look bad during dnd.
Thanks! just committed it with a big fat FIXME :), but I think the underlying problem of this bug still remains, should we keep this open?
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.