The existing app menu was a kludge of legacy code that tried to manage
a bunch of state, and had a number of issues:
* It didn't properly manage visibility when combined with multiple
apps and the overview.
* It didn't properly manage reactivity when tabbing away from a busy
app to another app.
* It didn't properly disconnect signals when going from one app
to nothing.
and countless others. Rewrite it to use the new "sync" code pattern,
where we centralize all state management and do transitions from that,
rather than strange and quirky control flow.
https://bugzilla.gnome.org/show_bug.cgi?id=705898
Make the lock dialog group reactive, to intercept any events
before they go to the actors below.
In the future, we may restructure our chrome to have a clear
layer system, but for now it fixes a security issue in the lock
screen (you can see the contents of the windows by dragging
if the screen was locked with the overview active)
https://bugzilla.gnome.org/show_bug.cgi?id=705840
There's only two uses of the parameter left, which can easily be added as a
separate line below. Since it's really a private interface meant for the
indicators, make it private as well so external users are less likely to
use it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
To align the arrows, we need to allocate panel buttons the full
height of the tray. Fix up all of the panel buttons to support this,
and align the arrows in the middle.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Swap out the implementation of SystemIndicator with a dummy,
and build the aggregate menu. At the same time, remove the
poweroff and login screen menus, as those were fake aggregate
menus beforehand.
We lose some flexibility as we lose session-mode-based menu
layout, but as each component of the aggregate menu is supposed
to be "smart" in response to updating itself when session
state changes, I believe it's better than a declarative model.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We can't silently replace the old behavior of separate status
icons into a new system. Replace SystemStatusButton with a new
SystemIndicator class which will allow for the flexibility we
need. For now, make it a subclass of Button so that it mostly
feels the same, but we'll soon be swapping it out with a dummy
implementation that the aggregate menu will use.
I think the code cleanup here is worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
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
Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
onAskQuestion has this code:
if (this.verifyingUser)
this.cancelButton.show();
else
this.cancelButton.hide();
but onAskQuestion can only be called when this.verifyingUser is true.
Also, cancelButton is public, and it only ever otherwise gets hidden
from callers.
This commit drops mucking with cancelButton visibility, leaving it
entirely up to the callers to deal with.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Chromium (but not google-chrome) has a StartupWMClass in the desktop
file, so we must match the instance part first to have chrome
web apps working.
Also, we must take care of apps without a wm_class or instance at
all.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
Some applications (such as most Java apps, as well as Chrome Web apps) ship
with desktop files that have the wrong name, but whose StartupWMClass
field contains the right value. Therefore first check that key, against
both the class and instance part of WM_CLASS, and only use the filename
if nothing else works.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
