Since commit e04e507659, we will already get the right icon for the
submenu arrow, so we must not mirror it again. However we do need to
take the text direction into account for the rotation now (but that's
not actually too bad - the resulting code gets quite a bit easier).
https://bugzilla.gnome.org/show_bug.cgi?id=736343
When you open or close a PopupSubMenu the arrow icon rotates, but
the code previously assumed that the starting angle was a multiple
of 90. If you click the submenu fast enough the rotation could overlap
with the previous rotation and you'd get something that wasn't a multiple
of 90.
Now we ensure that the ending arrowRotation angle is always a multiple
of 90 regardless of what the starting angle is.
https://bugzilla.gnome.org/show_bug.cgi?id=728927
The code from PanelMenu.Button assumed menus would open below their
source actor, making KEY_Down a good choice; however with the new
generic code, we should base the key used on the actual menu position.
https://bugzilla.gnome.org/show_bug.cgi?id=735614
The behavior of opening/closing/navigating a menu from its source
actor is generic enough to not limit it to PanelMenu.Buttons, so
move the code into PopupMenu itself.
https://bugzilla.gnome.org/show_bug.cgi?id=735614
The optional label support introduced in commit af063dc2f2 broke
the centering of separators, as the label still adds additional
spacing even when empty.
Properly hide the label actor in that case to fix the alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=730753
Until now the arrows were the associated arrow
character of the font. This cause some problems like
different arrows for different fonts, and size can be
altered because of the font size.
To solve that, use an image for the arrows.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently the animation of the arrows doesn't take
into account previous rotation.
Since in a incoming patch we will use one arrow
and rotate it to generate the four directions, we
need that the animation use relative rotation.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently destroying a menu's actor and calling its destroy() method
are subtly different - the latter will also result in the menu being
removed from the corresponding menu manager.
There is no good justification for that behavior, so make both actions
behave the same.
https://bugzilla.gnome.org/show_bug.cgi?id=724690
Since the agregate menu does 120% of font-size, make this
for all dropdown arrows in gnome-shell and rename the css
class to make clear that it is used in overall gnome-shell
https://bugzilla.gnome.org/show_bug.cgi?id=709564
Before, separators naively checked whether their siblings were visible
using actor visibility. However, if section actors are visible but have
no visible children, this will fail. Special-case separators when doing
visiblity checks.
https://bugzilla.gnome.org/show_bug.cgi?id=707801
Triangles should be flipped in RTL. This is the easiest way to do it that
doesn't rely on modifying the rotating logic, though it is a bit hacky since
the ClutterActor "scale-x" property technically considers the lower bound
to be 0. It works, though.
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
