GNOME Bugzilla – Bug 587781
change Dash background, draw a glow around running apps
Last modified: 2009-07-24 21:29:01 UTC
Patch follows.
Created attachment 137856 [details] [review] AppWell: If an application is running, activate an existing window Instead of relaunching, pick the first window and activate
Created attachment 137859 [details] [review] Remove the Dash shadow We want to be able to use multiple colors for the AppWell, in particular a glowing oval. If we have a dark-blueish background to contend with, it doesn't work very well.
Created attachment 137860 [details] [review] Add ShellDrawingArea and ShellStack ShellDrawingArea is a size-independent wrapper for a ClutterCairoTexture. Useful when drawing non-fixed size areas. ShellStack is a simple container class which holds items in a completely overlapping Z stack. The main difference from ClutterGroup is that items will be constrained to (and allocated) the size of the stack, not getting their preferred size always.
Created attachment 137861 [details] [review] Draw a glow around running applications Corresponding with the design, if an application is in a running state (has > 0 windows open), draw a glow behind the name.
THe main controversial patch here is removing the Dash background. I'm not sure of a better solution, ideas appreciated.
Created attachment 137863 [details] [review] Switch Dash to a mostly-black background
Created attachment 137864 [details] [review] Draw a glow around running applications Corresponding with the design, if an application is in a running state (has > 0 windows open), draw a glow behind the name.
(In reply to comment #1) > Created an attachment (id=137856) [edit] > AppWell: If an application is running, activate an existing window This looks right. Do we still support any way of launching apps without leaving the overlay? If so, the well code needs to watch out for that (but this was true before this patch as well.) (In reply to comment #3) > Created an attachment (id=137860) [edit] > Add ShellDrawingArea and ShellStack > > ShellDrawingArea is a size-independent wrapper for a ClutterCairoTexture. > Useful when drawing non-fixed size areas. That description isn't really clear what it means. "ShellDrawingArea is a wrapper around ClutterCairoTexture that allocates a new cairo surface and allows you to redraw if the actor is resized" or something? The code looks fine. > ShellStack is a simple container class which holds items > in a completely overlapping Z stack. The main difference > from ClutterGroup is that items will be constrained to > (and allocated) the size of the stack, not getting their > preferred size always. Code looks fine (though I'm not sure you need the check for "first" in get_natural_width/height, since min/natural are initialized to 0, so it should just work? ShellStack seems to basically be a Clutter version of a simplified GtkNotebook, and maybe calling it ShellNotebook would make its behavior more obvious?
Thanks for reviewing, (In reply to comment #8) > (In reply to comment #1) > > Created an attachment (id=137856) [edit] > > AppWell: If an application is running, activate an existing window > > This looks right. Do we still support any way of launching apps without leaving > the overlay? If so, the well code needs to watch out for that (but this was > true before this patch as well.) Right, basically if we want to make this behavior 100%, we need to make sure apps are patched to be single instance (and have the same window-activation behavior). Or maybe we can hack this into whichever library does app launching? > (In reply to comment #3) > > That description isn't really clear what it means. "ShellDrawingArea is a > wrapper around ClutterCairoTexture that allocates a new cairo surface and > allows you to redraw if the actor is resized" or something? The code looks > fine. Point, I'll fix up the commit log message as a gtk-doc description to the class. > Code looks fine (though I'm not sure you need the check for "first" in > get_natural_width/height, since min/natural are initialized to 0, so it should > just work? > > ShellStack seems to basically be a Clutter version of a simplified GtkNotebook, > and maybe calling it ShellNotebook would make its behavior more obvious? Well, with GtkNotebook you can only have one item visible at a time. ShellStack paints all children, which is fairly different. This is probably another case of lacking gtk-doc description, I'll fix as above.
Created attachment 138639 [details] [review] Draw a glow around running applications Corresponding with the design, if an application is in a running state (has > 0 windows open), draw a glow behind the name.
Created attachment 138640 [details] [review] Switch Dash to a mostly-black background
Created attachment 138838 [details] [review] Switch Dash to a mostly-black background
Created attachment 138839 [details] [review] Switch Dash to a mostly-black background
Created attachment 138840 [details] [review] Avoid ellipsizing app names; Draw glow around running Corresponding with the design, if an application is in a running state (has > 0 windows open), draw a glow behind the name. To make the display look a bit nicer, set the width of each item to be equal to the longest word among all the items.
Created attachment 138935 [details] [review] Switch to a black background for Dash and panes Corresponding with the panel style change, switch to a black background for more of the overlay components.
Moving the ellipsization to the name bug, 588474.
Created attachment 139175 [details] [review] This patch preserves the gradient, but makes the background darker. Make dash background darker so that the blue color used for indicating running apps can be visible. Use the dark blue (almost black) color from Jeremy's mockup. Make the dash height be the full screen height minus the height of the panel. Don't use padding on top or on the bottom. Remove the border from the main dash, but leave it for the results and details panes. Make the border slightly transparent. Make sure the details pane is correctly positioned by not applying the additional padding when determining its x position.
+// DASH_BORDER_COLOR.from_pixel(0x3d5a93aa); +DASH_BORDER_COLOR.from_pixel(0x213b5dfa); The commented out one intentional? Otherwise looks good.