GNOME Bugzilla – Bug 320034
transparency gtkstatusicon
Last modified: 2011-02-04 16:10:27 UTC
Patch will add transparency to the gtkstatusicon. It will use ParentRelative Window stuff. Works out of the box with KDE. Gnome Notification area needs to be motified (set the panel background pixmap to the socket window,for color background create a colored pixmap instead of drawing a rectangle directly). similiar Bugs: http://bugzilla.gnome.org/show_bug.cgi?id=150726 http://bugzilla.gnome.org/show_bug.cgi?id=306974
Created attachment 53973 [details] [review] da patch
This is substantially the same approach as taken in bug 150726. I've discussed with the author of the patches there and done some experiment on my own. Both of us were able to independently convince ourselves that this absolutely won't work without some significant active hackery (ie: it's not something that you can just change a couple of properties for and have it automatically work from then on).
Yes, Jochen, just how is your approach different from the patch I've provided in bug 150726? I set parent-relative on the main widget: gdk_window_set_back_pixmap (widget->window, NULL, TRUE); while you set it through the style: style = gtk_style_copy (widget->style); style->bg_pixmap[GTK_STATE_NORMAL] = (GdkPixmap*) GDK_PARENT_RELATIVE; gtk_widget_set_style (widget, style); g_object_unref (style); Does this make any difference?
Ryan: it IS working here. notificiation area only need about 20-30 lines of new code. I will make a patch tonight to play with. Ilya: i dont see the problem if a change the icons. probably cause the window background is cleared on expose events.
Jochen: 1. What code should be added to the notification area? 2. Why would changing the pixmap fire an expose event at its parent? And what "clearing" can occur, if the backgrond mode is parent-relative? You explicitly tell the pixmap's parent not to draw itself in any way, so how should it "clean" itself? 3. If you thought this approach is okay, why not use my patch then? Mine is shorter and better-documented and I don't see any difference in the technical approach. I'm sorry if it comes off a bit ego-driven, but why disregard past work? Also, there's a hefty amount of discussion on bug 150726, so why didn't you respond to it?
so the patch for the gnome notifcation area:(cvs/gnome/gnome-panel/applets/notification_area) it is not a real patch only something to play with. i found one ugly problem: during docking the background of the new tray icon locks weird. Ryan: can you make a new patch against gtkstatusicon and notifyarea ? so we have something to compare. Ilya: take a look on the code
Created attachment 54025 [details] [review] da notification applet patch
i have new idea to improve the things: the client send a dock request with a invisible window as data. the invisible window have a pixmap set. the manager/trayarea can now use this pixmap and draw it onself. (this should remove the flicker/update background problems). Events will first handled by the trayarea and then send to the invsible window as clientmessages. to change the icon the trayarea must listen for pixmap changes. comments ?
is this concept (last post) so bad/boring ?
no, but it is one of 1000 open issues in bugzilla
So, I think what needs to happen here is that somebody needs to adapt Dan Winships patch from bug 150726 to GtkStatusIcon. Of course, we also need to fix the notification area.
2006-06-19 Matthias Clasen <mclasen@redhat.com> Make transparent tray icons work. (#320034, based on a patch by Dan Winship) * gtk/gtktrayicon-x11.c (gtk_tray_icon_init): Make trayicons app-paintable and non-double buffered. * gtk/gtkrc.c (_gtk_rc_init): Give tray icons a parent-relative background in the default style.