When the triangle rotates (when sub-menu is expanded), it seems as if
the triangle pivots from one corner even though rotation center is set
to Clutter.Gravity.CENTER. Hence the rotation center is set nearer to
the edge than to the corner ([0.3, 0.5] instead of [0.5, 0.5]) so that
it doesn't appear odd.
Also pivot_point is used instead of rotation_center_z_gravity as it is
deprecated.
http://bugzilla.gnome.org/show_bug.cgi?id=703109
This code is too complicated to keep, and the last straw came after the
fixed width menu in the aggregate menu design.
This will break some existing popup menus that rely on the fixed width,
but this will soon be replaced with the aggregate menu. We'll also soon
clean this up further by replacing PopupBaseMenuItem's custom layout code
with an StBoxLayout.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We need to make sure that we reset the opened submenu when we close the
submenu, not trick the toplevel into thinking a closed submenu is the
currently opened menu.
https://bugzilla.gnome.org/show_bug.cgi?id=704336
This way, if a parent is insensitive, all children will be, too.
Though PopupSubMenus will be forced closed, PopupMenuSection needs
the propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Doing it at the end has confusing semantics, especially as there is
this point where isOpen is true, but the corresponding open-state-changed
has not been emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
It seems this behavior at one time was intentional, but I (along with
the designers) think it looks ugly having the menu having its insides
shrinking and shifting around while fading out of existence.
There's two cases where we currently explicitly try to animate the
submenu closed -- when an item is clicked inside the submenu, and
when the toplevel closes. This removes both of those.
The user expectation is that submenus will be closed the next time the
toplevel is open even if they were open before, so force submenus closed
when the toplevel finishes fading out, without any animation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
As the aggregate menu will be built out of sections from each
of the menus, we need to ensure that activating an item in one
of these sections can close the main menu, even when it is not
a menu item. The new API also needs to be flexible enough to
ensure that animations can be controlled, like the buttons that
lock the screen or launch a new session.
Port the user menu to use this new API as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
While the default style works well will a solid handle, using both
border and fill color would be desirable in classic mode. Add the
necessary (optional) style properties to allow this.
https://bugzilla.gnome.org/show_bug.cgi?id=697917
Since commit c84dc6254d, popup menus are closed automatically
when another menu opens (to catch the case where a menu is opened
by keyboard shortcut, which wasn't handled before). However in the
case of child menus, both child and parent are expected to be visible,
so handle this case explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=699678
We already do this when navigating between menus via mouse or
keynav, but miss cases where a menu is opened by other means,
for instance via a keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=686756
Currently all keybindings are disabled while some popup menu is open.
However some keybindings may still be useful in some cases, so expose
GrabHelper's modal params parameter to allow specifying a keybinding
mode for particular menus.
https://bugzilla.gnome.org/show_bug.cgi?id=698938
This simplifies the code required to build remote menus and
put all the items in the right place, and makes us share our
implementation with GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=698427
This makes it easy to replace the dot with another label in the future.
Change the allocation logic, as text layout is more complicated than
simple icon logic.
https://bugzilla.gnome.org/show_bug.cgi?id=698427
