Kill one separator by merging all global actions items at the end
of the menu, which ends up divided in three sections: status,
devices and actions.
https://bugzilla.gnome.org/show_bug.cgi?id=637690
This makes it consistent with other parts of the UI and will let the
a11y code use the rule "has_style_pseudo_class('selected') =>
ATK_STATE_SELECTED"
https://bugzilla.gnome.org/show_bug.cgi?id=637830
Mutter no longer optionally builds with GTK+-2.0, so we don't
need to check for it. And the specific form of the check broke
with recent changes to the naming of libraries for GTK+.
Don't do the "slide" effect when moving from one menu to another; only
do it when opening the first menu, or closing a menu without opening
another one.
https://bugzilla.gnome.org/show_bug.cgi?id=634755
Give the clock's right-click menu its own PopupMenuManager so that if
you drop down another menu and then mouseover the clock it doesn't
pop up the right-click menu.
https://bugzilla.gnome.org/show_bug.cgi?id=634755
Fix the panel menus to avoid unnecessarily bouncing out of modal (bug
634194) and to do a better job of keeping the keyboard focus in the
right place
https://bugzilla.gnome.org/show_bug.cgi?id=618885
Until recently, the clutter keyboard focus was almost always kept on
the stage, and bits of code that wanted to do stuff with the keyboard
would just watch for key-press-events on the stage. In several places,
the code wasn't even bothering to ensure that the focus was on the
stage, which caused problems with other actors that explicitly grabbed
focus.
A previous fix for this (f21403fd) was to always reset the focus to
the stage after calling pushModal(), but a better fix is to just
actually make use of the keyboard focus everywhere rather than having
everyone try to read events off the stage.
Now pushModal(actor) also does actor.grab_key_focus(), and various
bits of code have been changed to read key events off their own
toplevels rather than off the stage, meaning there's no chance of them
accidentally getting someone else's events.
https://bugzilla.gnome.org/show_bug.cgi?id=618885
Thanks Owen and Colin for debugging this:
<davidz> does anyone have a clue about this cryptic error message: http://fpaste.org/aWgh/ ?
<owen> davidz: well, I'd guess some sort of syntax error...
<walters> hmm
possibly but unlikely fallout from my js versioning
<owen> oh, it's happening here too
walters: exactly
Adding --js-version=1.8 to the wrapper script fixes
walters: I thought you were defaulting to allowing extensions?
<walters> actually, let's do that now anyways
Signed-off-by: David Zeuthen <davidz@redhat.com>
Instead of showing submenus on the left side, make PopupSubMenuMenuItem
act like an expander. The sub menu is toggled on click, opened on
right/enter/space on the parent item, closed on left on any item
or when closing the parent menu.
https://bugzilla.gnome.org/show_bug.cgi?id=633476
As all children were considered for the grid's layout, hidden items showed up as
empty space. Instead, exclude hidden children from the layout, so that the grid is
only made up of visible items.
https://bugzilla.gnome.org/show_bug.cgi?id=631537
We weren't freeing the whole pixbuf, nor were we the GList of
subpixbufs. Plug both of these leaks in the error handling path
and in the default case.
All of the unreffing/cleanup should happen in the GDestroyNotify
for the result, not some in the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=636489
According to the designers, system notifications should be transient;
so now that transient notifications are supported properly, make use
of it instead of using a timeout to remove the associated source.
Transient notifications are removed after being shown. If the summary
is being shown while they appear, they are represented in it by a new
source icon.
We always create a new source for new transient notifications to
ensure that they don't replace the latest persistent notification
associated with the source. Because we generally don't want any
new or resident notifications to be replaced by others, associating
multiple notifications with a source is the next thing we will
implement.
https://bugzilla.gnome.org/show_bug.cgi?id=633412
Resident notifications don't get removed when they are clicked or
one of their actions is invoked, and are only removed when the app
that created them requests them to be removed or sends another
notification.
Remove the source when a notification associated with it is removed.
Except if the source is a tray icon.
Make sure that we pop down the tray when a notification is clicked
or one of the actions of a non-resident notification is selected.
Based on the initial patch by Jonathan Matthew.
https://bugzilla.gnome.org/show_bug.cgi?id=633412
Given that the grid view is gone there is no point in animating the
window previews on all workspaces anymore so just do it for the current
one avoid taking a slow down caused by animating windows on other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=637353
In both tests the scrolled actor's width was fixed to the stage
width, so that the scroll bars ended up outside the visible area.
Fix by adding an outer container with a fixed width and expanding
the scroll view to fill the available area.
Mixing submenu menuitems and toggle menuitems results in poor layout.
The fix is to right-align the submenu arrows. Since we already need to
right-align the battery percentages as well, add alignment support to
PopupBaseMenuItem.addActor(), and update stuff for that.
Also remove the "column" param from addActor() since it hadn't
actually been implemented correctly before.
https://bugzilla.gnome.org/show_bug.cgi?id=633476
While non-uniform border widths were parsed correctly, an arbitrary
side's width was picked when painting, so that each border ended up
with the same width and the widths specified in CSS were ignored.
At least for sides between non-rounded corners, using a different
border width can be reasonable, for instance at screen edges.
Different border widths around rounded corners are kind of crack,
but then it would be lame not to support it ...
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For gradient backgrounds, borders were implemented by filling the
background shape with the border color first, and then scaling down
the path to draw the background.
The result is not correct[0], which is especially visible if the border
width is greater than the border radius - so instead of scaling down
the original path, use a separate path for the background.
The result is consistent with the borders we draw for non-gradient
backgrounds, and much closer to the correct standard behavior.
[0] http://www.w3.org/TR/css3-background/#the-border-radiushttps://bugzilla.gnome.org/show_bug.cgi?id=607500
