GNOME Bugzilla – Bug 103206
note tab labels aren't transparent
Last modified: 2004-12-22 21:47:04 UTC
Gedit 2.16 note pad labels are rendered opaque and obscure GTK2 scheme. I am using the HT2-gtk2-Saphire scheme with blue shaped tabs and the Gedit document labels are rendered as black text on a grey background.
Cosmetic, but quite user-visible in a new feature and breaks theming with the associated accessibility problems -> high, would be nice in 2.2.x
This is due to gtk+ bug #93389. *** This bug has been marked as a duplicate of 93389 ***
No, this isn't the same thing at all. If you put an event box in a notebook tab, it isn't going to be transparent no matter what GTK+ does about setting the state. Event boxes have input-output windows. To do a "drag and drop label container" you can use an input-nly window similar to the way GtkButton works.
It seems to be fixed with recent gtk+ versions.
*** Bug 112526 has been marked as a duplicate of this bug. ***
Not exactly fixed; more like covered up with certain themes. This is an interesting problem that requires a likewise unique answer. Since GtkEventBox is going to play dirty by slapping gtk_paint_flat_box() on the background, we'll have to play dirty by making our own EventBox-alike. GtkButton, however, is in the same hierarchical chain and paints the parent without a flat_box() obscuring whatever's behind it. The only problem, of course, is that it's a Button, and we don't want that. So we'll have to create a subclass of GtkBin (or something) to correctly address the problem. Owen, is this what you were saying?
Created attachment 16654 [details] [review] patch to use EelInputEventBox instead (input-only widget)
Thanks for the patch. A few comments: > + /* update the label/image/tooltip */ > gtk_label_set_text (GTK_LABEL (label), name); > set_tab_icon (image, child); > + gtk_tooltips_set_tip (tooltips, event_box, uri, NULL); > > ret = old_hbox; Why do you need to call gtk_tooltips_set_tip again here? > - settings = gtk_widget_get_settings (view); > + /* fetch the size of an icon */ > + gtk_icon_size_lookup (GTK_ICON_SIZE_MENU, &w, &h); > > - gtk_icon_size_lookup_for_settings (settings, > - GTK_ICON_SIZE_MENU, > - &w, &h); Please, use gtk_icon_size_lookup_for_settings here since gtk_icon_size_lookup is not multihead safe. > + GTK_WIDGET_UNSET_FLAGS (event_box, GTK_NO_WINDOW); > gnome_popup_menu_attach (popup_menu, event_box, NULL); > + GTK_WIDGET_SET_FLAGS (event_box, GTK_NO_WINDOW); You are playing dirty here :-) Why do you need tow hbox? Plase, add a ChangeLog entry to the patch.
I have just tried your patch. I have other two comments: 1. Please, re-add the space between the icon and the label 2. The tooltip should be shown also when the mouse is over the close button. BTW, your patch seems to work well. I only have some concern about the following part: > + GTK_WIDGET_UNSET_FLAGS (event_box, GTK_NO_WINDOW); > gnome_popup_menu_attach (popup_menu, event_box, NULL); > + GTK_WIDGET_SET_FLAGS (event_box, GTK_NO_WINDOW); Are you sure it does not have weird side effects?
Okay, GtkSettings is now back in again, and I've put some x-padding between the label and the icon. We need two GtkHBoxes because the hierarchy goes something like this: -> GtkHBox hbox +-> GtkButton close_button |-> EelInputEventBox event_box |-> GtkHBox event_hbox +-> GtkImage image |-> GtkLabel label You may stop right here and ask: wait, why does he have the button outside of the event box? The answer is simple: if we use an Input/Output event box, the button is fine, but we get that redraw problem; if we use an Input Only event box, the redraw is fine, but the button is insensitive. Try it out if you have time; it's really nasty. Related to this is your request to have the tooltip "be shown also when the mouse is over the close button." Problem: the close button is outside of the event box. Assigning the tooltip to the outer hbox results in no tooltip at all (I think it needs a GtkBin derivative like the EventBoxes or a Button.) This results in a secondary call to tooltips_set_tip(), which might seem ugly (and, in fact, may BE ugly, since moving the mouse from the label to the close button results in a visual "skip" in the tooltip.) However, I realize that I don't currently have the kind of experience needed to just jump in and start hacking away at Gtk+ to suit these goals. I think we need some kind of Event-sensitive layout container for this, but I have no idea where to start. Seems like something for egg if I get around to it, though. > + /* update the label/image/tooltip */ > gtk_label_set_text (GTK_LABEL (label), name); > set_tab_icon (image, child); > + gtk_tooltips_set_tip (tooltips, event_box, uri, NULL); "Why do you need to call gtk_tooltips_set_tip again here?" We're calling gtk_tooltips_set_tip here because it isn't called beneath the conditional. This is because the context of "ret" changes depending on which context set_label is being called with. This is why I wanted to separate out build_ and update_ contexts; it just seems like a natural course of action now that the two parts of set_ are so divergent. > + GTK_WIDGET_UNSET_FLAGS (event_box, GTK_NO_WINDOW); > gnome_popup_menu_attach (popup_menu, event_box, NULL); > + GTK_WIDGET_SET_FLAGS (event_box, GTK_NO_WINDOW); Okay, yeah, this is playing dirty; I admit it. It's there because gnome_popup_menu_attach() iterates through the parents to find a place where the GTK_NO_WINDOW flag is unset (to find container windows). Unfortunately, EelEventBox sets GTK_NO_WINDOW because of another iterator which does drawing. Ideally, gnome_popup_menu_attach() should be smarter about this, but that's another patch for another module.
Created attachment 16723 [details] [review] updated patch as described
Fixed in CVS HEAD