GNOME Bugzilla – Bug 568712
notification area icons squeeze the clock out of the panel
Last modified: 2009-01-27 20:30:55 UTC
With 5 or 6 icons in the notification area, the clock jumps out of the panel in the second row. I guess notification icons should grow to the left instead of to the right. (I currently have 6 icons - battery indicator, wifi signal, bluetooth, xchat, skype, update-manager)
This is TidyGrid being silly. We should port to BigBox.
Created attachment 127121 [details] [review] patch to use BigBox, et al There was an unexpectedly large amount of yak shaving involved in moving to BigBox: * BigBox forces each child to use the full height(/width) of the box, which stretches out the icons, so we have to add an additional box around each item to get the layout correct. * At first I thought we could use Big.BoxPackFlags.FIXED and Big.BoxAlign.CENTER, but that doesn't work because the box only takes its non-FIXED children into account when computing its height and width, so if it contains only a FIXED child, it requests a 0x0 allocation, and the clock and all of the icons end up stacked on top of each other. So instead, I position them using padding. * The GtkWindow ClutterActor wrapper used by the tray icon hack kept the window's position in sync with the actor's position by watching the actor's notify::x and notify::y. But now that doesn't work because the actor representing the icon is now at a permanently-fixed location inside its wrapper BigBox, and its the wrapper box that moves. ClutterActor doesn't emit anything when an actor's parent moves, even though ClutterActorClass->allocate() can see when this is happening. So I hacked up a ShellGtkWindowActor class, that wraps a GtkWindow in a ClutterActor and tracks its allocation so it can move the window around accordingly. (We'll want this for the intlclock embedding too anyway, at which point I'll need to fix the FIXME added to shell-tray-manager.c) * ShellGtkWindowActor derives from ClutterGLXTexturePixmap, but Clutter-0.8.gir doesn't currently contain the GLX stuff. I started fixing that, but then ran into scanning problems or something, so for now I just hacked up Shell-0.1.gir to not include ShellGtkWindowActor
Could use a few comments; e.g. what is the +2 in "global.screen_width + 2", why are we setting x, y to -1 etc. Do we need to unref the window in _dispose for ShellGtkWindowActor? Otherwise looks good to me.
(In reply to comment #3) > Could use a few comments; e.g. what is the +2 in "global.screen_width + 2", why > are we setting x, y to -1 etc. "because that's how the old code did it" :) > Do we need to unref the window in _dispose for ShellGtkWindowActor? Yes.
Created attachment 127266 [details] [review] Turn the panel into a BigBox (and don't use TidyGrid for the notification area) Updated: don't make the panel extend 1 pixel beyond the screen edge, since it doesn't seem to have much effect. Dispose the GtkWindow when the actor is disposed.
Quick note: beyond the edge of the screen is to get a black-line under by putting a 1-pixel black border around.
In general, it looks pretty good to me and I don't have a lot of comments on the patch. It feels to me that ShellGtkWindowActor is a random chunk of functionality - the stuff that needs to be in an actor - rather than something reusable - you have to create the GtkWindow, realize it, reparent it to the stage window. So, I tend to wonder if something along the lines of: shell_widget_actor_new(ClutterStage *stage, GtkWidget *widget); Is possible that could be easily reused. The colormap/background pixmap manipulations for tray icons do make this a bit harder ... you might need to have a construct-property for the embed-window colormap and a ::window-realized signal. (This doesn't need to block this patch, but the topic of embed-gtk-in-the-stage seems to be coming up repeatedly.)
(In reply to comment #7) > (This doesn't need to block this patch, but the topic of embed-gtk-in-the-stage > seems to be coming up repeatedly.) Yeah, I figure that this actor will be revisited to make it more properly generic as we need to embed other things; for now it seemed like making it take a widget instead of a window would just complicate things because of the transparency stuff, as you mentioned.
(In reply to comment #6) > Quick note: beyond the edge of the screen is to get a black-line under by > putting a 1-pixel black border around. Ah, fixed. (BigBox lets you set separate borders, so it's easier to do here.) Committed.