Just like the top bar, the window list should scale according to
the font scaling factor, so convert the existing pixel sizes into
font-relative ones.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window list position depends on both the monitor geometry and the
list height, however changes to the latter are currently ignored. For
the time being this doesn't matter due to the list's fixed height, but
we are about to scale the list with the text, so reposition the list
on height changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window-list's fixed height currently allows us to get away without
expanding buttons, however this won't be the case anymore once we start
adapting the list with the text scaling. So fix up the code to do what
was always the intention anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The function never had a timestamp parameter, the parameter that was
added at some point is a workspace index. Ouch, this has gone unspotted
since the original AxeMenu extension was adapted for the apps-menu ...
For a while now, gnome-shell has initialized extensions before
setting up its own keybinding handling. As a result, our taking
over of the panel-main-menu shortcut will be overwritten when
the extension is enabled at startup - work around this by setting
up the keybinding again on LayoutManager::startup-complete.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
Setting up signal handlers inside a class and rely on outside code
to disconnect them via global variables is utterly weird. Just
disconnect everything inside the class when the corresponding actor
is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
By default, PanelMenu.Button creates a popup menu with arrow side TOP
which is wrong in our case and can mess up BoxPointer's positioning.
We can work around that easily by creating the menu ourselves with the
correct arrow side.
https://bugzilla.gnome.org/show_bug.cgi?id=746365
Menus in the top bar have some margin at the bottom, to prevent
menus to extend all the way to the bottom edge as the expand; we
obviously don't want the same behavior in the window-list at the
bottom, so stop pretending to be a top bar menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745952
